Note: send any spelling/grammer errors to /dev/null.
I've compiled a little list of things that are still lacking on the port of wine to mingw/msys/cygwin. Unless I mention cygwin as the target it can be assumed for the purpose of this doc I am speaking about a mingw target.
About 5 or 6 months ago James Tablor and Casper Hornstroup ported wine to Mingw for ReactOS. ReactOS is very close to having basic Windowing support so I have set out to compleate the work they have started by bringing the wine/Rewind trees up to speed with our changes. The current wine build system still has a few things Missing before we can build without needing the reactos source tree/makefiles.
Note: I have ordered the list by importance and the steps needed to build.
1. Make configure changes to build wine support under mingw/cygwin. Currently configure Has issues detecting how it should build the wine files as either dlls,so or .a I have submitted a patch for this but it was rejected because it was just a work-around And did not fix the problem. You will need to still run ./configure under cygwin as dlltool/wrap do not detect properly under msys with configure. With the current port in the ReactOS source tree we use our own Makefiles/resources and I would like to get away from this.
2. run ./configure --host=mingw32 --target=mingw32 --build=mingw32 CFLAGS="-D_MINGW_ -D_WINDOWS -DWINE_NOWINSOCK"
3. Remove winedump from the tools/Makefile as Mingw/Cygwin and others have support for dumping PE executable information and it is loaded with Unixisms.
4. add -liberty to the makefile for wrc and wmc. This is needed because of getopt and optarg
5. add a configure check to #define snprintf _snprintf for wrc when building with mingw.
6. Remove server, library and tsx11 for mingw. If you want to build wineserver under cygwin we will need to adapt get/set thread context from GDB's win32 support.
7. 90% of the source from the dlls compiles with no problems. The issue is when you want to link the objects as a dll and compile in the resources. winebuild now has support to build the *.def files needed for dlltool so there will need to be changes on the way that the spec/def files are used when building on a Win32 host. If one tries to build wine currently under Mingw/Cygwin it will puke when linking to the needed imports because winebuild will try to import from lib*.so rather then from dllname.a I've also been having troble linking with resources compiled with wrc under Mingw/Cygwin.
7. We do not want to build advapi32, Kernel32, ntdll, user32, gdi, msvcrt or crt.dll
8. These are the dlls we know that we can build and need: avicap32, avifile32, comctl32, commdlg, crypt32, ddraw, dinput, dplay, dplayx dsound(needs imports from winmm), imagehlp, lzexpand, mapi32, ole32, oleaut32 olecli, oledlg, olepro32, olesvr, richedit, rpcrt4, serialui, setupapi, shdocvw shell32, shfolder, shlwapi, tapi32, twain, url, urlmon, version, winmm, winspool wintrust.
9. Debugging will be differnt under Windows/ReactOS due to the wine debugger not working. Under ReactOS currently we have all of the FIXMEs and TRACES mapped to our NTDLL as DbgPrnt and others. I'm not 100% sure as to how we are doing this yet.
10. DLL seperation and Wineserver dependace. I wont even really be able to start looking at this untill the 10 issues above are worked out. I know that when I tested programs/dlls from our first wine port under ReactOS there were issues due to a lack of internal wineserver functions.
11. The chain of dependance for the Sound/Graphics for Winmm/DirectX and others will need interfaces developed for the HAL (Codeweavers/Transgamming?)
Thanks Steven
"Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson