blob: f0434631c8770482cc365faaea397db60b9efee5 [file] [log] [blame]
For more information about the port or GLib, GTk+ and the GIMP to
native Windows, see http://www.iki.fi/tml/gimp/win32/ . ("Native"
means that we use the Win32 API only, and not any POSIX emulation
layer except that provided by the Microsoft runtime C library, and the
pthreads emulation library.)
As for now, only the Microsoft compiler and tools are really
supported. Before compiling, check the BIN definition in
makefile.msc. Compile with `nmake -f makefile.msc`. Install with
`nmake -f makefile.msc install`. Cygwin (without cygwin runtime,
i.e. "mingw32"), and maybe LCC-Win32 support will be added later.
When using the cygwin compiler and tools *with* the cygwin runtime the
normal Unix configuration method should work as if on Unix (knock on
wood).
With a little work, it might be possible to use the ./configure
mechanism also with a "mingw32" configuration. I.e. building GLib for
Win32 would use the cygwin tools (and dll), but the produced libraries
would not depend on the cygwin runtime being present.
The following preprocessor macros are used for conditional compilation
related to Win32:
- WIN32 is defined when compiling for the Win32 platform, regardless
if using the X11 or Win32 GUI API (of course, in the case of GLib, this
dimension isn't significant), regardless whether using a more
or less complete Unix emulation runtime layer (like Cygwin) or not.
- NATIVE_WIN32 is defined when compiling for Win32, *and* without
any Unix emulation, other that to the extent provided by the
(Microsoft) C library, or the pthreads-win32 library. For instance,
pathnames use the native Windows syntax.
- _MSC_VER is defined when using the Microsoft compiler.
Currently the Win32 port uses the combination with all three of those
on, but eventually the cygwin compiler and tools will be supported
also, and in that case _MSC_VER wouldn't be defined.
Some of the usage of these macros is probably a bit mixed up, and will
have to be straightened out when actually trying other combinations.
The thread support uses the pthreads for Win32 package available from
http://sourceware.cygnus.com/pthreads-win32/, which isn't ready yet,
and thus really should not be relied upon.