On Tue, Nov 13, 2012 at 2:13 PM, Kai Tietz <ktiet...@googlemail.com> wrote: > 2012/11/13 Corinna Vinschen <vinsc...@redhat.com>: >> On Nov 13 13:09, Ozkan Sezer wrote: >>> On Tue, Nov 13, 2012 at 1:03 PM, Corinna Vinschen <vinsc...@redhat.com> >>> wrote: >>> > On Nov 13 12:17, Ozkan Sezer wrote: >>> >> On Tue, Nov 13, 2012 at 12:01 PM, Corinna Vinschen <vinsc...@redhat.com> >>> >> wrote: >>> >> > On Nov 13 09:21, Kai Tietz wrote: >>> >> >> Hi,2222222278 >>> >> >> >>> >> >> 2012/11/12 Corinna Vinschen <vinsc...@redhat.com>: >>> >> >> > Hi, >>> >> >> > >>> >> >> > the below patch fixes the definitions of SYSTEM_BASIC_INFORMATION >>> >> >> > and >>> >> >> > adds a definition of SYSTEM_PAGEFILE_INFORMATION and >>> >> >> > SystemPagefileInformation. It also changes the formatting of >>> >> >> > SYSTEM_INFORMATION_CLASS to make it a bit more readable. Tested on >>> >> >> > 32 >>> >> >> > and 64 bit. >>> >> >> > >>> >> >> > Ok to apply? >>> >> >> >>> >> >> Ok, thanks. Please apply. >>> >> > >>> >> > Thanks, done. >>> >> > >>> >> >>> >> AFAIK, winternl.h doesn't expose SYSTEM_BASIC_INFORMATION details >>> >> for the reserved fields. Also see: >>> >> http://msdn.microsoft.com/en-us/library/windows/desktop/ms724509%28v=vs.85%29.aspx >>> >> Where did we retrieve those detail in the first place before even >>> >> correcting them? Of course there are user contributed stuff on >>> >> social.msdn.com, like: >>> >> http://social.msdn.microsoft.com/Forums/en-US/windowssdk/thread/2c1f05d0-b764-475d-8e84-83c2d8a81795/ >>> >> ... but how wise is it to include such things in our headers? >>> > >>> > As I wrote in my OP, I tested the stuff on 32 and 64 bit systems using >>> > my very own, self-written testcase. Given that SYSTEM_BASIC_INFORMATION >>> > was already fully available in winternl.h, >>> >>> This ... >>> >>> > and given that the only >>> > change I made was to change the data types to match 64 bit, and given >>> > that I tested the result for consistency, I don't quite see your point... >>> > >>> >>> ... is my point: I don't have an objection againt your correction, I have >>> an objection against its full form being present in the first place. >> >> So you want to keep winternl.h as close to upstream as possible, thus >> removing already available (and tested) definitions? Personally I don't >> think it makes a lot of sense to keep a "Reserved1" field intact, just >> because it's not documented. Nobody *has* to use the undocumented >> fields, after all. >> >> Anyway, that means the idea to move the (used and tested) definitions >> from Cygwin to Mingw64 is moot. > > Well, I would welcome it as long as fields are proven OS-idependent or > showing real use-cases in applications using our winternl header. And > I think that cygwin as user is a vaild case, isn't it? > > But I strongly agree to Ozkan that we don't want to have > NDK-definitions here. At least for now I see the burden to test all > cases as not sensible ... but well, I might be wrong > >> Alternatively, what about having two definitions for each datatype? One >> of them the default, close to the MS definition, the other one if you >> define __WINTERNL_ENABLE_UNDOCUMENTED. This would also guard the >> officially entirely undocumented datastructures. > > Hmm, this sounds like a nice idea. But I would think that it might be > better to have a switch which forces MS' PSDK mode and having > extensions enables by default - at least as long as normal use-case is > unaffected by it and our users might have an advantage by it.
Sounds like an OK idea tome, too. > > Regards, > Kai -- O.S. ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
