Mail Archives: cygwin/1997/04/03/15:12:40
I have been trying to get DirectX to work. So far I have been working only
with direct draw, but what I have done should work with all of DirectX,
since I have not had to make a single change to any of the DirectX header
files. Here is a short overview of my progress so far:
1. I am using GNU-Win32 b17.1 combined with the DirectX 3 SDK, and also the
Microsoft Platform SDK. The Platform SDK, like the DirectX SDK, is free
from Microsoft. They distributed it at the last developers conference. If
you don't have it, get it now, because it is only going to be available for
a limited time according to Microsoft.
Why the Platform SDK? Because it contains all of the Microsoft Native Win32
Headers. And as far as I understand the agreement, it is legal to use them
with GNU-Win32 or any other compiler (following some Microsoft guidelines,
of cousrse.......). If anyone understands the agreement differently,
please let me know!!
I had to do a little porting of the header. But it was not very much at
all. I'm not sure exactly, but I don't think I modified more than 10 lines
of code all together. Currently, I get lots of warnings when I compile,
but this is because gcc reports a warning when a structure or union is not
given a name. And this happens alot throughout the headers. But they are
just warnings, so everything still compiles.
I still have to review the changes I have made to make sure that they are
all needed, but once I do, I will post the necessary changes.
The next thing to do was to build the import libraries. Both the SDK's
came with .lib import libraries that we all know aren't going to work with
GNU-Win32. So, dlltool to the rescue.......
First create the .def file. I get the exports from the .lib files that
came with the Platform SDK. Here is the make rule I use:
%.def: %.a
echo EXPORTS >$@
nm $< | egrep '^........ [T]' \
| sed 's/[^_]*_//' >> $@
Now, with the .def file, we can build the .a import library. This is were
I ran into a few problems that took me a short while to figure out. Here
is the situation, if I created the import lib with the following command:
dlltool --def foo.def --dllname foo.dll --output-lib libfoo.a
then compiled my program using functions in the DLL, everything would
compile with no problems. But, when I ran the executable, it would report
an INVALID ENTRY POINT error for the functions in the DLL.
At first I came up with the following solution. Edit the .def file and
remove all ordinal values (the '@xx' stuff). Then recreate the import lib
with the above dlltool command.
Then I had to make sure that the declarations for the functions in my
program did not include the '__stdcall' delimiter. This worked (why?), now
everything compiled and I could call all the functions, get valid return
values (as far as I could tell), and my programs would run.
The part I didn't like was not being able to use '__stdcall'. So I tried
other things, and I came up with this: leave the ordinals in the .def file
and create the import library with this:
dlltool -k --def foo.def --dll foo.dll --ouput-lib libfoo.a
^^
The -k tells dlltool to exclude the ordinals from the import library. Now
I don't have to exclude '__stdcall' from the function declarations. So
everything is working..........
My Question is this, what is the difference between my two solutions? Can
anyone explain?
BTW: As I said, the Platform SDK header files are Microsoft Native. So
they include all stuff for COM, OLE, and everything else you would
expect.........
Hopefully this can help other people working with DirectX.....
If anyone wants to talk to me about DirectX and GNU-Win32, email me......
-Jeff Tresselt
tresselt AT flash DOT net
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -