Re: GLib and 64-bit Windows

[Tor Lillqvist <tml iki fi>]

Morten Welinder writes:
 > ">=", I think, but yes.  You need to make sure configure defines gsize
 > as unsigned long long, and gssize as long long.

Jake is using the MSVC makefiles which doesn't run any configure
script (because there is no Bourne shell to run it in, etc...).

He uses the more or less manually written config.h.win32(.in) as
config.h and glibconfig.h.win32.in as glibconfig.h. If he is using the
stock config.h.win32 and glibconfig.h.win32 they will be very wrong
for Win64.

The intention is that config.h.win32 and glibconfig.h.win32 match what
running the configure script would produce, with just
compiler-specific ifdefs added (like using the "i64" suffix instead of
"ll" for 64-bit ints and unsigneds with MSVC).

It is/was expected that config.h.win32(.in) and
glibconfig.h.win32(.in) need to be updated as necessary for win64. I'm
sorry if I didn't remember to point this out early on. For instance,
the macros GLIB_SIZEOF_VOID_P, GLIB_SIZEOF_SIZE_T and the typedefs for
gsize and gssize in glibconfig.h.win32.in need to be made conditional
on _WIN64 or whatever the proper feature test macro is.

As soon as there then is a chance to run the real configure script for
the win64 target (either once gcc etc have been ported, or by using
some of the wrappers that make cl.exe look like gcc
command-line-parameter-wise), the config.h and glibconfig.h files it
outputs should be compared to config.h.win32 and glibconfig.h.win32
files that have been manually edited for Win64, and any discrepancies
fixed.

(I definitely think it would be a very bad idea to typedef glong as an
64-bit integer on win64, with plain "long" still being 32 bit. Surely
the expected convention is that "glong" is *exactly* the same as
"long"?)

(Whether having "long" being 32-bit in Win64 is a silly design
decision or not is pointless to discuss here. I am sure MS did a
thorough analysis and came to the conclusion that this causes less
problems than going to 64-bit longs.)

--tml