[0xDEAD10CC]

Yea, english is not my native and was too early in the morning to give enough attention on your comments, I find strange how ULONG_PTR tilts you, and using char or short is very bad design for a for loop and that thing will bite you in the a**, so you don't mind to be used char, but you find confusing ULONG_PTR ? "You could have also used a regular pointer" ULONG_PTR has the same size as a pointer (does that count ?) but its increase by 1 not by its type (int* will increase by 4 bytes, this is what i mean), if i know this thing will start a war between int and ULONG_PTR will start, i would have mixed tabs with spaces to pour salt in everyones wound, a little bit of VIM vs EMACS, and say that GCC sucks. Are you the type of guy that uses signed int ?

4 spaces > 1 tab
VIM > EMACS
Watcom > GCC
Windows > Linux
Edge > Chrome
Starwars suck

Why would char would be bad design here and not ULONG_PTR? Both are going to do equally the same thing but char will use less stack space (even though that's not my argument here). I don't understand how it would do any harm in this particular case either since all your values for the physical disk string numeric component can fit into 8 bits... You don't need this kind of precompiler logic for what you're doing however:

Code:

#if defined(_WIN64)
typedef unsigned __int64 ULONG_PTR;
#else
typedef unsigned long ULONG_PTR;
#endif

The reason this type exists is to store a pointer address, and the size of a pointer changes depending on architecture, which implies this is a mis-use of the type semantically.

As for the pointer arithmetic problem; unsigned char* would do similar.

-- My point: wrong with the standard primitive int types here? It's what everyone else does, optimized for x86 arch, plain and easy to read, basically de facto standard, and you don't need unsigned __int64, or unsigned long for a 0-15 range.

I'm not saying it doesn't work, but it would be like using a 64-bit integer to store a boolean state. Why not just match with the types you're already using? Yes obfuscated code works too as another example, but there's a reason why people don't normally write code like that.

[IsBadWritePtr]

Might be too late to write but windows stores process ids and thread ids as HANDLE even tho WINAPI uses ULONG ? So here is misuse of HANDLE and there is size difference ?

Code:

typedef struct _CLIENT_ID {
  HANDLE UniqueProcess;
  HANDLE UniqueThread;
} CLIENT_ID;

There is a lot of misuse i have seen, I just remembered this, and also HMODULE is ignored and threated as PVOID in most internal structures, and PE executables are threated as DLL's. LDR_DATA_TABLE_ENTRY is perfect example, LDR_DATA_TABLE_ENTRY is a list that stores information of all libraries and the current executable, The base address and name is stored as

Code:

PVOID DllBase;
PVOID EntryPoint;
ULONG SizeOfImage;
UNICODE_STRING FullDllName;
UNICODE_STRING BaseDllName;

EDIT: I might delete this whole post, this is never ending spam mess

[0xDEAD10CC]

Might be too late to write but windows stores process ids and thread ids as HANDLE even tho WINAPI uses ULONG ? So here is misuse of HANDLE and there is size difference ?

Code:

typedef struct _CLIENT_ID {
  HANDLE UniqueProcess;
  HANDLE UniqueThread;
} CLIENT_ID;

There is a lot of misuse i have seen, I just remembered this, and also HMODULE is ignored and threated as PVOID in most internal structures, and PE executables are threated as DLL's. LDR_DATA_TABLE_ENTRY is perfect example, LDR_DATA_TABLE_ENTRY is a list that stores information of all libraries and the current executable, The base address and name is stored as

Code:

PVOID DllBase;
PVOID EntryPoint;
ULONG SizeOfImage;
UNICODE_STRING FullDllName;
UNICODE_STRING BaseDllName;

EDIT: I might delete this whole post, this is never ending spam mess

You're forgetting that with the pointers and handles, and other integer types, that is the object oriented implementation of the Win32 API. These translations are not a misuse of types, they are very intentional, and it is common when you're actually dealing with pointer addresses. However, in your case you aren't dealing with any kind of pointer address, just a numeric value. There is that difference between what you're comparing this to. C does not have classes, but this is why Win32 does this. All you have to do is look at the LIST_ENTRY structure and usage as a small example of many things internal to the Win32 API for why this is the way it is. Another thing is that a lot of the windows headers contain a lot of preprocessor logic. If you're not familiar by now with Win32, you would've already known that handles are basically just pointers, and that all of those typedefs and define's just resolve to similar types. PVOID would be universal, so I'm not sure why you think that is a misuse of the types. C isn't as strict on types as C++ and that is perfectly safe for storing an address.

The difference as I've tried to explain is that the Win32 internals are actually dealing with addresses here, and you're not. You can find odd stuff in Win32 because there is backwards compatibility in there from the old 16-bit days. You're also not aiming for backwards compatibility here.

If you haven't read "The Old New Thing" blog, I'd suggest doing that as a starting point to understand Win32 quirks and such as well.

[IsBadWritePtr]

Its not mess and I have never seen someone complain, but by your logic it has to be mess, And how is WIN32 object oriented ? WIN32 was written for C, And why should i aim for backwards compatibility ? This code is for my machine and i guarantee that it should work perfectly on 7 and compatibility for what ? CreateFile, CreateThread, CloseHandle, IOCTL_STORAGE_QUERY_PROPERTY, IOCTL_DISK_GET_DRIVE_GEOMETRY might not get deprecated even after 10 years, but never will be removed, and the DOS paths are fixed, nobody is going to change them, this will be suicidal. I know enough WIN32 to see how they try to make it more easy to use and have removed really important functionality of the Nt family, WIN32 not supported root files is one of the problems. Imagine CreateFile supporting root files, FindFirstFile and FindNextFile can be just on functions and more stuff like this that will speed up WIN32 and make it smaller... I know that Microsoft is so strict of that compatibility but still who cares about WIN16 ? 16 bit is just like that strange kid that you try not to talk but you are in the same class and implements macros that just bloat with __far and __near, Windows headers are such a big mess, from far I know there are different departments that use different types. one will use ULONG while another might use DWORD, One used ULONG64 while another uses ULONGLONG or other stuff like that, And for the compatibility someone told me that Windows has too many old functions and algorithms that slow down the whole system and you can't remove or edit them because some random program used it before 15 years, might get lucky eventually if someone  upper lets you optimize the old stuff. This might sound very arrogant but I don't need to read blogs about WIN32 and C++, I find out only "How arbitrary is the ArbitraryUserPointer in the TEB?" interesting.

Its again early in the morning and you hit me like a coffè, have a good read of my spelling errors lol

E: Next post will use ULONG just for you, I capitulate