Re: [Mingw-w64-public] [patch] winternl.h: Fix SYSTEM_BASIC_INFORMATION, add SYSTEM_PAGEFILE_INFORMATION
Hi,78 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. Btw., I could provide more detailed definitions of TEB, PEB, and types used within TEB or PEB. Is there any interest? Sure there is. Only issue I see about it is that WINVER needs to be interpreted here. AFAIK does these structure change meaning of some fields for different OSes (XP, Vista, Win7, ...). 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] winternl.h: Fix SYSTEM_BASIC_INFORMATION, add SYSTEM_PAGEFILE_INFORMATION
On Nov 13 09:21, Kai Tietz wrote: Hi,78 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. Btw., I could provide more detailed definitions of TEB, PEB, and types used within TEB or PEB. Is there any interest? Sure there is. Only issue I see about it is that WINVER needs to be interpreted here. AFAIK does these structure change meaning of some fields for different OSes (XP, Vista, Win7, ...). Yes, that's right. Hmm, might be a bit more tricky than I thought. I have a certain set of stuff as used in Cygwin and especially the stuff I tested on 32 and 64 bit to get it really right for 64 bit. Probably it makes sense to apply only stuff which is not OS-dependent for now. 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
Re: [Mingw-w64-public] [patch] winternl.h: Fix SYSTEM_BASIC_INFORMATION, add SYSTEM_PAGEFILE_INFORMATION
On Tue, Nov 13, 2012 at 12:01 PM, Corinna Vinschen vinsc...@redhat.com wrote: On Nov 13 09:21, Kai Tietz wrote: Hi,78 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? Btw., I could provide more detailed definitions of TEB, PEB, and types used within TEB or PEB. Is there any interest? Sure there is. Only issue I see about it is that WINVER needs to be interpreted here. AFAIK does these structure change meaning of some fields for different OSes (XP, Vista, Win7, ...). Yes, that's right. Hmm, might be a bit more tricky than I thought. I have a certain set of stuff as used in Cygwin and especially the stuff I tested on 32 and 64 bit to get it really right for 64 bit. Probably it makes sense to apply only stuff which is not OS-dependent for now. Corinna -- 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
Re: [Mingw-w64-public] [patch] winternl.h: Fix SYSTEM_BASIC_INFORMATION, add SYSTEM_PAGEFILE_INFORMATION
On 11/13/2012 18:01, Corinna Vinschen wrote: On Nov 13 09:21, Kai Tietz wrote: Hi,78 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. Btw., I could provide more detailed definitions of TEB, PEB, and types used within TEB or PEB. Is there any interest? Sure there is. Only issue I see about it is that WINVER needs to be interpreted here. AFAIK does these structure change meaning of some fields for different OSes (XP, Vista, Win7, ...). Yes, that's right. Hmm, might be a bit more tricky than I thought. I have a certain set of stuff as used in Cygwin and especially the stuff I tested on 32 and 64 bit to get it really right for 64 bit. Probably it makes sense to apply only stuff which is not OS-dependent for now. Yaakov asked me to update the mingw-w64 parts in Cygwin, please ping when things have settled down so I can push an update. Thanks. signature.asc Description: OpenPGP digital signature -- 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
Re: [Mingw-w64-public] [patch] winternl.h: Fix SYSTEM_BASIC_INFORMATION, add SYSTEM_PAGEFILE_INFORMATION
On Nov 13 18:30, JonY wrote: On 11/13/2012 18:01, Corinna Vinschen wrote: On Nov 13 09:21, Kai Tietz wrote: Hi,78 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. Btw., I could provide more detailed definitions of TEB, PEB, and types used within TEB or PEB. Is there any interest? Sure there is. Only issue I see about it is that WINVER needs to be interpreted here. AFAIK does these structure change meaning of some fields for different OSes (XP, Vista, Win7, ...). Yes, that's right. Hmm, might be a bit more tricky than I thought. I have a certain set of stuff as used in Cygwin and especially the stuff I tested on 32 and 64 bit to get it really right for 64 bit. Probably it makes sense to apply only stuff which is not OS-dependent for now. Yaakov asked me to update the mingw-w64 parts in Cygwin, please ping when things have settled down so I can push an update. You can push any time. These changes will be extras, not required for anything yet. So far Cygwin has its own file with internal definitions, called ntdll.h. Right now I'm busily writing testcases to make sure the definitions match 32 bit as well as 64 bit systems. The idea is to push the stuff in this file to winternl.h so we can ideally get rid of our own Windows type definitions. This might or might not be welcomed, though. 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
Re: [Mingw-w64-public] [patch] winternl.h: Fix SYSTEM_BASIC_INFORMATION, add SYSTEM_PAGEFILE_INFORMATION
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,78 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. Corinna -- 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
Re: [Mingw-w64-public] [patch] winternl.h: Fix SYSTEM_BASIC_INFORMATION, add SYSTEM_PAGEFILE_INFORMATION
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,78 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
Re: [Mingw-w64-public] [patch] winternl.h: Fix SYSTEM_BASIC_INFORMATION, add SYSTEM_PAGEFILE_INFORMATION
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,78 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. 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch] winternl.h: Fix SYSTEM_BASIC_INFORMATION, add SYSTEM_PAGEFILE_INFORMATION
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,78 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
Re: [Mingw-w64-public] [patch] winternl.h: Fix SYSTEM_BASIC_INFORMATION, add SYSTEM_PAGEFILE_INFORMATION
On Nov 13 13:13, Kai Tietz wrote: 2012/11/13 Corinna Vinschen vinsc...@redhat.com: On Nov 13 13:09, Ozkan Sezer wrote: ... 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? That makes sense. Unfortunately Cygwin tests the value of a PEB member with an OS-dependent name at one point, but otherwise we only use OS-independent stuff, afaik. 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 I have to admit that I have no idea what constitutes the difference between an NDK-definition and, well, any other kind of definition... 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. To me the advantage is that we have a chance to unify the definitions used from user-space and put them into a single file. If it turns out that a definition hasn't been tested enough and must be changed, there's a single point to change it and every user of Mingw64 can profit right away. 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
Re: [Mingw-w64-public] [patch] winternl.h: Fix SYSTEM_BASIC_INFORMATION, add SYSTEM_PAGEFILE_INFORMATION
On Nov 13 16:32, Ozkan Sezer wrote:
On Mon, Nov 12, 2012 at 7:37 PM, Corinna Vinschen vinsc...@redhat.com wrote:
About the correction made in SYSTEM_BASIC_INFORMATION:
[...]
Index: winternl.h
===
--- winternl.h (revision 5451)
+++ winternl.h (working copy)
@@ -688,9 +688,9 @@
ULONG LowestPhysicalPage;
ULONG HighestPhysicalPage;
ULONG AllocationGranularity;
-ULONG LowestUserAddress;
-ULONG HighestUserAddress;
-ULONG ActiveProcessors;
+ULONG_PTR LowestUserAddress;
+ULONG_PTR HighestUserAddress;
+ULONG_PTR ActiveProcessors;
CCHAR NumberOfProcessors;
} SYSTEM_BASIC_INFORMATION,*PSYSTEM_BASIC_INFORMATION;
If we compare original structure, we have:
BYTE Reserved1[24];
PVOID Reserved2[4];
CCHAR NumberOfProcessors;
So, PVOID Reserved2[4] should correspond to 4 ULONG_PTR members
in the detailed version: do we not need the following, too?
- ULONG AllocationGranularity;
+ ULONG_PTR AllocationGranularity;
No, the AllocationGranularity is a ULONG value. The size of the
structure is a result of the automatic 8 byte alignment of 8 byte types.
Try this:
=== SNIP ===
#include stdio.h
#include string.h
#include windows.h
#ifndef NT_SUCCESS
#define NT_SUCCESS(status) ((NTSTATUS) (status) = 0)
#endif
typedef int NTSTATUS;
typedef struct _SYSTEM_BASIC_INFORMATION
{
ULONG Unknown;
ULONG MaximumIncrement;
ULONG PhysicalPageSize;
ULONG NumberOfPhysicalPages;
ULONG LowestPhysicalPage;
ULONG HighestPhysicalPage;
ULONG AllocationGranularity;
#ifdef _WIN64
ULONG dummy1;
#endif
ULONG_PTR LowestUserAddress;
ULONG_PTR HighestUserAddress;
ULONG_PTR ActiveProcessors;
UCHAR NumberProcessors;
} SYSTEM_BASIC_INFORMATION, *PSYSTEM_BASIC_INFORMATION;
NTSTATUS NTAPI NtQuerySystemInformation (ULONG, PVOID, ULONG, PULONG);
int
main ()
{
NTSTATUS status;
ULONG i, size;
SYSTEM_BASIC_INFORMATION sbi;
memset (sbi, 0xbf, sizeof sbi);
status = NtQuerySystemInformation (0, sbi, sizeof sbi, size);
if (!NT_SUCCESS (status))
{
fprintf (stderr, NtQuerySystemInformation: 0x%lx\n, status);
return 1;
}
printf (Size: %lu\n, size);
printf (AllocationGranularity: %lu\n, sbi.AllocationGranularity);
#ifdef _WIN64
printf (dummy1: 0x%lx\n, sbi.dummy1);
#endif
return 0;
}
=== SNAP ===
$ x86_64-w64-mingw32-gcc -g -o sbi sbi.c -lntdll
$ ./sbi
Size: 64
AllocationGranularity: 65536
dummy1: 0xbfbfbfbf
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
Re: [Mingw-w64-public] [patch] winternl.h: Fix SYSTEM_BASIC_INFORMATION, add SYSTEM_PAGEFILE_INFORMATION
On 11/13/12, Corinna Vinschen vinsc...@redhat.com wrote:
On Nov 13 16:32, Ozkan Sezer wrote:
On Mon, Nov 12, 2012 at 7:37 PM, Corinna Vinschen vinsc...@redhat.com
wrote:
About the correction made in SYSTEM_BASIC_INFORMATION:
[...]
Index: winternl.h
===
--- winternl.h (revision 5451)
+++ winternl.h (working copy)
@@ -688,9 +688,9 @@
ULONG LowestPhysicalPage;
ULONG HighestPhysicalPage;
ULONG AllocationGranularity;
-ULONG LowestUserAddress;
-ULONG HighestUserAddress;
-ULONG ActiveProcessors;
+ULONG_PTR LowestUserAddress;
+ULONG_PTR HighestUserAddress;
+ULONG_PTR ActiveProcessors;
CCHAR NumberOfProcessors;
} SYSTEM_BASIC_INFORMATION,*PSYSTEM_BASIC_INFORMATION;
If we compare original structure, we have:
BYTE Reserved1[24];
PVOID Reserved2[4];
CCHAR NumberOfProcessors;
So, PVOID Reserved2[4] should correspond to 4 ULONG_PTR members
in the detailed version: do we not need the following, too?
- ULONG AllocationGranularity;
+ ULONG_PTR AllocationGranularity;
No, the AllocationGranularity is a ULONG value. The size of the
structure is a result of the automatic 8 byte alignment of 8 byte types.
Try this:
=== SNIP ===
#include stdio.h
#include string.h
#include windows.h
#ifndef NT_SUCCESS
#define NT_SUCCESS(status) ((NTSTATUS) (status) = 0)
#endif
typedef int NTSTATUS;
typedef struct _SYSTEM_BASIC_INFORMATION
{
ULONG Unknown;
ULONG MaximumIncrement;
ULONG PhysicalPageSize;
ULONG NumberOfPhysicalPages;
ULONG LowestPhysicalPage;
ULONG HighestPhysicalPage;
ULONG AllocationGranularity;
#ifdef _WIN64
ULONG dummy1;
#endif
ULONG_PTR LowestUserAddress;
ULONG_PTR HighestUserAddress;
ULONG_PTR ActiveProcessors;
UCHAR NumberProcessors;
} SYSTEM_BASIC_INFORMATION, *PSYSTEM_BASIC_INFORMATION;
NTSTATUS NTAPI NtQuerySystemInformation (ULONG, PVOID, ULONG, PULONG);
int
main ()
{
NTSTATUS status;
ULONG i, size;
SYSTEM_BASIC_INFORMATION sbi;
memset (sbi, 0xbf, sizeof sbi);
status = NtQuerySystemInformation (0, sbi, sizeof sbi, size);
if (!NT_SUCCESS (status))
{
fprintf (stderr, NtQuerySystemInformation: 0x%lx\n, status);
return 1;
}
printf (Size: %lu\n, size);
printf (AllocationGranularity: %lu\n, sbi.AllocationGranularity);
#ifdef _WIN64
printf (dummy1: 0x%lx\n, sbi.dummy1);
#endif
return 0;
}
=== SNAP ===
$ x86_64-w64-mingw32-gcc -g -o sbi sbi.c -lntdll
$ ./sbi
Size: 64
AllocationGranularity: 65536
dummy1: 0xbfbfbfbf
I see. Thanks.
Corinna
--
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
