Status of building Wine under Cygwin/Mingw

[Steven Edwards]

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