On Jul 7 22:04, JonY wrote: > On 7/7/2010 21:59, Corinna Vinschen wrote: > >On Jul 7 21:19, JonY wrote: > >>On 7/7/2010 20:58, Christopher Faylor wrote: > >>>On Wed, Jul 07, 2010 at 02:39:19PM +0200, Corinna Vinschen wrote: > >>>>Oh, and, talking about /opt or /usr, I'd prefer the above /usr/mingw* > >>>>sysroot idea. However, I don't like the idea in the least to keep > >>>>two different versions of w32api around. It's one target, so we should > >>>>have one set of headers only. Right? Wrong? None of that? > >>> > >>>Unfortunately, it sounds like we've stepped into the middle of a dispute > >>>between the mingw folks and the mingw64 folks. Maybe the best thing for > >>>us to do would be to decide to use only one or the other but not both. > >>> > >>>cgf > >>> > >> > >>Here are some of the technical issues. > >>[...] > >>As for mingw-w64 headers API, it does not support anything lower > >>than XP, Win2K is not supported, different from mingw.org's Win9X > >>compatibility. > > > >How do you do that? The XP functionality is a superset of the W2K > >functionality, which in turn is a superset of the NT4 functionality. > >So, in theory, headers supporting XP should support any earlier > >system(*). > > > > > >Corinna > > > >(*) Note that I ignore 95/98/Me deliberately since they deserve to be > > forgotten. > > > > > Hi, > > _WIN32_WINNT by default is set to 0x501, there are no ifdef guards > for anything lower. So if you wanted to limit yourself to win2k > functionality, there isn't a practical way to do it other than > looking up MSDN.
Ok, that's something I can live with. I don't understand the notion to keep _WIN32_WINNT at 0x0400 anyway. The idea of this value is to be set manually if I *don't* want modern functions, but the default should be to allow *all* function so it should be at least set to 0x0601 at present. I don't see why using w32api should be different from using recent MS headers. But, never mind, that's not the point of this thread. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat