IMHO in UM in a G3 OO language mostly the type limits are irrelevant. Of course they matter, just like in any other context, but the consequence is so much less on account of what has been managed for you.
In C we have a whole series of types that attempt to be abstract but fail miserably on account of the nature of the language - you better know exactly what bytes you are working with as no one will check up on you except a BSOD!
Whereas in a UM G3 OO language, it is in fact discouraged that any specific algorithm understand the limits of the data types or machine but rather to work with the logical units as declared - p invoke notwithstanding
Sent from Surface Pro
From: xxxxx@osr.com
Sent: Tuesday, May 05, 2015 2:31 PM
To: Windows System Software Devs Interest List
If you say so. I think you’ve spent too much time in user-mode, where data types are nothing but a swamp with tons of “choose whichever one you like and if you don’t link any of these make up your own and put them in the header” alternatives.
Data types in Windows kernel mode are very simple. DWORD is not a Windows NT kernel data type. UCHAR, USHORT, and ULONG (and their associated signed and pointer types) are. INT and UINT are not Windows NT kernel data type.
Like everything else in Windows kernel-mode, these data types were designed to be “isolated” and “portable” – a decision which turned out to be most wise (see below).
As I said previously, I strenuously disagree that choosing LLP64 was not more desirable than choosing LP64. I think LP64 creates a TERRIBLE mess. In LLP64 a LONG and an ULONG are 32-bits period. No guesswork, no shape shifting. How wide is a “long”? Who cares? It’s not a kernel datatype, so not my concern. But LONG? I know it’s 32-bits now and forever and ever unto ages of ages amem.
When I lay out structures, I decide the width I want for my data fields. I use a set of specific declarations for those data fields that have implied width. There is no sense to changing those widths because I compile for a different system, unless the fields are pointers… which change of necessity.
Anything is defensible by somebody. They could have made “char” 3 bytes to make it future proof, I suppose, and we could defend that. But that doesn’t make it (a) not annoying, (b) a good idea, (c) optimal.
“Easy internationalization is more important than programmer familiarity”? LOL… seriously? Oh, come. You don’t truly mean that, do you?
But, in any case, let’s leave “char” alone. Let’s JUST look at Windows kernel-mode ULONG vs C# ulong, shall we.
Every poor bastard who is condemned to move back and forth from C/C++ to C#has the honor and privilege of writing a post-it note for their monitor that says “Don’t forget: C# long == 64 bits”… and when you write your C++ COM DLL, don’t forget: It might be an ULONG argument in your COM event, but it’s NOT “ulong” or “unsigned long” when it shows up in your C# event handler! It’s a uint. Or a System.UInt32.
I guess that’s to make internationalization easier.
Nah, it’s just bad.
Peter
OSR
@OSRDrivers
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer