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. 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. Corinna ------------------------------------------------------------------------------ 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
