glib/README.win32

56 lines
2.5 KiB
Plaintext
Raw Normal View History

Merge in current Win32 version. Almost no Unix code touched. * README.win32: More text. * config.h.win32 glibconfig.h.win32: Update to match the corresponding generated files on Unix. * makefile.msc: Update with new source files, and gthread library. Use the compiler flag -MD instead of using -D_DLL and "/nodefaultlib:libc msvcrt.lib" in the link phase. * glib.def: Include new functions, drop removed ones. * glib.h: Add comments about main loop and polling on Win32. (In general, it's only for the GIMP's use.) Add Win32 IO Channel functions. Remove the obsoleted old IO Channel stuff (which was in #if 0 already). * giowin32.c: New file. * gmain.c: Include config.h, conditionalize <sys/time.h> inclusion. Add g_poll implementation for Win32 (only for the GIMP's needs for now, it's hard or even impossible to be as clean and generic as on Unix). Implement g_get_current_time on Win32. If threads aren't supported, don't try to wake up main thread's loop. On Win32, use a semaphore and not a pipe to wake up the main loop. * gmessages.c: On Win32, allocate a console window if the standard output handle is invalid before writing to stdout, and reopen stdout to that console window. * giochannel.c: Conditionalize unistd.h inclusion. Some indentation cleanup. * gstrfuncs.c: Include <signal.h>. * gutils.c: On Win32, also check the HOMEDRIVE and HOMEPATH environment variables. * gmodule-dl.c gmodule-dld.c: In _g_module_build_path, don't add the "lib" prefix and ".so" or ".sl" suffix if already there. * gmodule-win32.c: Likewise for the ".dll" suffix. * gthread-posix.c: Conditionalize <sys/time.h> inclusion.
1999-01-17 00:46:42 +01:00
For more information about the port or GLib, GTk+ and the GIMP to
native Windows, and pre-built binary packages, 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. Additionally the pthreads
emulation library is used.
As for now, to build GLib on Win32, you need the Microsoft compiler
and tools. Both the compiler from MSVC 5.0 and from MSVC 6.0 have been
used successfully.
Before building you must get the pthreads library for Windows from
http://sourceware.cygnus.com/pthreads-win32/. The pthreads-win32
snapshot from 1999-03-16 is mostly OK. Edit the location of the
pthreads library and include files in makefile.msc. Also edit the BIN
definition in makefile.msc.
Build with `nmake -f makefile.msc`. Install with `nmake -f
makefile.msc install`.
Support for building using the cygwin tools (without depending on the
cygwin runtime, i.e. "mingw32"), and maybe LCC-Win32 might be added
later. When using the cygwin 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 runtime), 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 windowing API (in the case of GLib, this
dimension isn't significant), regardless whether using a more or
less complete POSIX emulation runtime layer (like Cygwin) or not.
- NATIVE_WIN32 is defined when compiling for Win32, *and* without
any POSIX 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 "gcc -mno-cygwin" 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 pthreads for Win32 package that the thread support uses isn't
quite ready yet, and thus threads really should not be relied upon.