2012/11/13 Corinna Vinschen <[email protected]>: > On Nov 13 13:09, Ozkan Sezer wrote: >> On Tue, Nov 13, 2012 at 1:03 PM, Corinna Vinschen <[email protected]> >> wrote: >> > On Nov 13 12:17, Ozkan Sezer wrote: >> >> On Tue, Nov 13, 2012 at 12:01 PM, Corinna Vinschen <[email protected]> >> >> wrote: >> >> > On Nov 13 09:21, Kai Tietz wrote: >> >> >> Hi,2222222278 >> >> >> >> >> >> 2012/11/12 Corinna Vinschen <[email protected]>: >> >> >> > 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. Regards, Kai ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
