I've decided to have a go at fixing module support on Windows platforms. I've reluctanly set up my home machine to dual-boot Windows and Linux, and have installed cygwin on the Windows side. I came up with a test to see if I correctly understand the linking problems involved. It didn't work out quite as I expected, though, and I wonder if anybody can give me a boost in the right direction. The test.c file is supposed to be an analog of XEmacs: it is self-contained, has a function that can be used by modules, and opens and attempts to use some user-specified DLL. On the other hand, dll.c is the source for a simple dll.c that provides a function needed by test.c, and uses a support function provided by test.c. The Makefile attempts to compile these to an executable, test.exe, and a DLL, my.dll. With the Makefile as given, the result is: $ ./test.exe my.dll "This is a test" Unable to open library my.dll If the use of dlltool is removed in favor of the two commented lines below it, namely: gcc -o junk -shared -Wl,--out-implib -Wl,libtest.a test.o rm junk.exe then the result is: $ ./test my.dll "This is a test" The string is This is a test Its reverse is tset a si sihT Also, I note that when gcc is used to create junk.exe as above, it says "Creating library file: libtest.a", but dlltool does not. When the "-shared" is omitted from the gcc line above, to create the actual test.exe executable, then libtest.a is NOT created. And finally, the junk.exe created above really is junk: it is actually a DLL, not an executable. I'd rather not create a junk XEmacs DLL just to get the import library. Can anybody show me how to use dlltool appropriately to make this work? -- Jerry James http://www.ittc.ku.edu/~james/