Tim Prince wrote: > This sub-topic is about 64-bit mingw. Apparently, it is the only gcc > for 64-bit Windows with any near-term prospects. As mingw requires Aside from host-specific bits (e.g. path parsing) the Cygwin and MinGW ports share almost all the same actual code in gcc. The significant differences are in the runtime libraries and headers. For instance the -mno-cygwin switch is implemented entirely in the specs file via options that switch out various search paths, libraries, headers, startup objects, etc. but none of this really affects any fundamental codegen changes. So, even though no effort has been made yet to start to support a 64 bit version of the Cygwin runtime, it's still fairly clear that a great deal of the work already done for the MinGW port will be shared. > Microsoft libraries, the point about requiring data type consistency > with those libraries has to be accepted. For things like stdio.h structures like FILE* that is one thing, as those are all the domain of the C runtime support library, and their implementation details are supposed to be opaque to the user anyway, so you can take some latitude with how they're implemented internally. But 'long' is a more fundamental data type that is used by practically every w32api function signiture. It would be a real mess too if MinGW and Cygwin differed here, because they share the same platform headers. Even on Cygwin, you're still dealing extensively with the underlying Win32 API under the hood, since Cygwin is just a userspace library anyway, and the need to interoperate with the native toolchain still exists. IMHO it would introduce a giant support nightmare if the two ports differed. But that's just MHO; it might be that the ease of porting 64 bit linux apps outweighs the pain of this juggling act. Brian
