Re: [ntdev] convert LARGE_INTEGER to DWORD

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

The point is that the MACRO or typedef need only change depending on the environment and not the whole code base. This is actually quite common practice where there is a significant cost to lexical changes to source code (embedded systems in controlled environments).

And even for normal programmers, as Peter pointed out, it is vastly simpler to look at a single def’n that to troll millions of lines of code for a data type change.

Sent from Surface Pro

From: xxxxx@hotmail.com
Sent: ‎Wednesday‎, ‎May‎ ‎06‎, ‎2015 ‎10‎:‎52‎ ‎AM
To: Windows System Software Devs Interest List

Actually, Anton that was the recommended standard approach to making C portable

???

What is the point of redefining a type if its size is compiler-dependent anyway???

Although " typedef unsigned __int32 UINT32" definition makes a perfect sense, the ones like “typedef unsigned int UINT;” does not seem to(at least to me)…

It is amazing how many OS guys in the past had actually worked in the
languages world

It must have been a truly exciting time when designing your own OS or a compiled language
was a kind of a standard assignment, so that one could reasonably expect to work on multiple OSes and compilers throughout a career…

Anton Bassov


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

IMHO the SQL guys (and other archivists) got this right a long time ago - a type is a type and never shall it vary in nature (within a language). The compiler guys never seem to get the message however and we have all sorts of hacks, including the ones derided by Anton, to work around the fact that a particular algorithm makes assumptions that might not be true in another compilation environment.

I will admit that the G3 OO languages are much better in this respect, but as usual C++ has the worst of all worlds as a combination. As usual, it is not so much how C++ is practically used, but just the mere potential for abuse that exists. Forget overloaded operators, can you imagine the evils of a macro like this

#define int (unsigned char)

There really is nothing that can be done to defend against this kind of idiocy except cripple the pre-processor - as they have done in C#

Sent from Surface Pro

From: Don Burn
Sent: ‎Wednesday‎, ‎May‎ ‎06‎, ‎2015 ‎1‎:‎12‎ ‎PM
To: Windows System Software Devs Interest List

The problem was everyone had an opinion. I remember Thomas Plum proposed “tiny” for numerical char values. He also proposed that there be macros such as SHORT(x) as a way to specify a “((short) x)”. Now Plum was consider a pioneer in a lot of things, but I sure would not have wanted to see this.

The C language that most of us know went through a lot of mistakes like many languages in their early years. It isn’t easy to design a language or even an extension for a language that gets popular approval. It was hard enough to get acceptance when it was a compiler extension for a specific firms hardware, once you moved into the standard realm things get crazy.

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, May 06, 2015 12:48 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] convert LARGE_INTEGER to DWORD

Don Burn wrote:

40+ years ago when Unix was first escaping Bell Labs, it did not
have concrete datatypes for C specific (or at least in all cases), but
that was one of the first things people were fixing due to all the
problems of porting this supposedly “portable OS”. I like a lot of
others got drafted to fix pieces for given ports.

<stdint.h> is one of the greatest advances in this regard, and should have been done long ago. I now using uint8_t and uint32_t in virtually all of my projects. They are clear and unambiguous.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.


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


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</stdint.h>

Only for the benefit of archives

The logic behind this has nothing to do with what the type definitions are currently set to. The logic is that by providing a layer of abstraction between your code and the compiler you can change compilers & platforms with a minimum of difficulty. Instead of having to find replace on into etc. through the whole code base, and then reviewing those changes, you can simply change a header file and be done.

The alternative method of achieving the same is the very non-obvious use of the pre-processor to alter the code before compilation. IMHO anyone coming into a project that did that would be ripe for some rude awaking when the compiled code used data types of different sizes than expected for a given compiler & platform.

Also, don’t under estimate the cost of code changes. Even a simple find replace change can generate hundreds of man hours of review and testing depending on the target environment.

As for the beauty of the code, surely we can all agree that that is in the eye of the beholder. I need not cite any further evidence than the plethora of options in VS and other tools for the auto correction of the placement of various kinds of brackets, tab and spaces to convince any sane reader that there exist many different definitions of beautiful code

Sent from Surface Pro

From: xxxxx@hotmail.com
Sent: ‎Thursday‎, ‎May‎ ‎07‎, ‎2015 ‎3‎:‎23‎ ‎PM
To: Windows System Software Devs Interest List

And is it going to change??? Is it going to fix the INT to a certain size???

Oh, I see - “If you have ‘int’ scattered throughout your code, you’re completely screwed”, and if it is INT, rather than ‘int’ , you are not, despite the fact that INT is nothing more than “typedef int INT;”.
Amazing logic…

Anton Bassov


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

One of my pet peeves is the lack of proper cons decorations on API & DDI signatures.

SAL mostly makes up for this, but not quite as they are only code analysis warning and not compiler warnings and have no impact on the resulting machine code

Sent from Surface Pro

From: xxxxx@broadcom.com
Sent: ‎Friday‎, ‎May‎ ‎08‎, ‎2015 ‎1‎:‎14‎ ‎PM
To: Windows System Software Devs Interest List

Oh yes, that’s why I always use PCULONG for inputs and ULONG* for outputs, and
use the prefix “o” for output parameters.

Everybody also need to keep in mind that:

PCULONG != const PULONG
const void * != const PVOID


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

Although Microsoft has failed utterly at documenting the use of specific SAL annotations (at least a whitepaper) consider the theory:

To perform static analysis there are two possible approaches:

Analyze the code as written

Analyze the intent of the programmer versus the code as written

SAL is a means to do the second which is far more likely to catch errors, in exactly the same way that two factor authentication is far harder to break than a password alone. In addition, the performance of option 1 suffers because the analyzer must evaluate every possible code path through all functions whereas in the second each function can be checked independently for its compliance with the contracts of each interface used - thus allowing much more detailed checking in a similar time.

SAL is a tremendous benefit, but it is very hard to learn how to apply them correctly in the absence of reasonable documentation not about the exceptions, but the annotations themselves

Sent from Surface Pro

From: Gregory G Dyess
Sent: ‎Tuesday‎, ‎May‎ ‎12‎, ‎2015 ‎12‎:‎48‎ ‎PM
To: Windows System Software Devs Interest List
Cc: Windows System Software Devs Interest List

I wish I did have a good idea for how to do this. If I did, I would be making a fortune writing compilers rather than toiling away in the innards of Windows CE BSP internals.

Greg

xxxxx@probo.com wrote:

From: Tim Roberts
To: “Windows System Software Devs Interest List”
Subject: Re: [ntdev] convert LARGE_INTEGER to DWORD
Date: Tue, 12 May 2015 09:29:16 -0700

Gregory G Dyess wrote:
> I’m going to have to go with Maxim on this one. SAL, just like Hungarian notation, causes far more visual noise than any possible benefit it gives. There needs to be a better mechanism than polluting the function signature.

If you have an idea, I’m sure the compiler team would be keenly
interested in hearing about it. SAL is a lot of work.

Scott is right in that they are awesomely powerful. However, like
Maxim, I have not yet leapt over that cliff myself.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.


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


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

You can make your one version of no_sal.h to use with other tools. This is what I do and it defines all of those annotations as empty macros so they have no effect.

I disagree about the ability for humans to read the code. IMHO it improves the ability to read a function declaration as you immediately not only know the type of the parameters but their usage as well

Sent from Surface Pro

From: xxxxx@hotmail.com
Sent: ‎Tuesday‎, ‎May‎ ‎12‎, ‎2015 ‎7‎:‎07‎ ‎PM
To: Windows System Software Devs Interest List

I really want to love the SAL and use it when I can, but I find myself stripping it out at release time. My product team maintains Windows and Linux variants of device functionality simultaneously. We make a strong effort to decouple the core functionality from the associated operating system. So what happens is the places where SAL is most useful breaks compatibility.

It would be an improvement for me if I could annotate my function declarations outside of the file containing the function definitions. I could then manage the complexity of the SAL stuff using the IDE to connect the annotated declarations to the definitions. I could then decouple the SAL annotations from the executing code and maintain cross-platform development code bases.


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