convert LARGE_INTEGER to DWORD

NTDEV
21

xxxxx@gmail.com wrote:

Once upon a time a WORD was a machine word and a DWORD was a machine double word, hence the names. These types came from circa Windows 3 nomenclature in the x86 16-bit days. Today these types are frowned on and it’s better not to dig these up and instead opt for modern types when possible. The c++ auto specifier could also be ideal here.

Unfortunately, <stdint.h> and the “auto” keyword have not been a part of
the WDK until very recently.

“auto” is a fabulous tool when working with STL and template types,
which can get unwieldy. I’m not as convinced of its benefits with the
built-in types, because it’s awfully easy to lose track of what you
have. In the STL case, you want to compiler to choose a type that
works. In a driver case, we’re writing plumbing between hardware with
hard field sizes and APIs with specific type requirements. Can I be
sure the compiler is going to make the most useful choice?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.</stdint.h>

22

xxxxx@osr.com wrote:

There you’re exactly correct. There’s a reason “they” defined a unique abstract set of kernel-mode data types when Windows NT was being developed.

It’s really, really hard to defend the argument that “ULONG” is somehow
an abstraction of “unsigned long”. DWORD is an abstraction, and that’s
what should have been used for ALL 32-bit types in the kernel. The
CHAR, UCHAR, SHORT, USHORT, INT, UINT, LONG and ULONG types are idiotic
and have been all along. No one in their right might would ever have
defined ULONG be anything other than “unsigned long”. Therefore, it’s
not an abstraction. It’s a typing shortcut.

Had DWORD been used throughout, Microsoft could have changed “long” to
64-bits without any impact. In my view, that would have been a much
more sensible approach. There was ample existing prior art for other
64-bit platforms that demonstrated the viability of that choice.

It was to purposefully separate them from the native system/compiler data types, and provide portability for kernel-mode code.

Do you really believe that “LONG” is separate from “long”? Really?

If you want to air personal datatype annoyances, MY biggest one is the C# datatypes. char in C# is 2 bytes, and long is 64-bits. Very, very, very annoying. I had my lead check-in a whole series of changes to a rather high visibility project once with the explanation “Changed ‘char’ by ‘byte’ everywhere, because Peter apparently didn’t realize ‘char’ was 2 bytes” Very embarrassing.

To be fair, that problem occurred was not because the choices in C# are
bad. It’s because you were approaching C# with C firmly lodged in your
brain. The decision to have char be 2 bytes is quite defensible. Easy
internationalization is more important than programmer familiarity.

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

23

LONG is a Window data-type that’s defined as using the complier’s 32-bit integer type.

long is a C/C++ intrinsic datatype of indeterminate size

With the MS compiler LONG happens to be defined as long. With another compiler it might be defined as int.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, May 5, 2015 9:30 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] convert LARGE_INTEGER to DWORD

xxxxx@osr.com wrote:

There you’re exactly correct. There’s a reason “they” defined a unique abstract set of kernel-mode data types when Windows NT was being developed.

It’s really, really hard to defend the argument that “ULONG” is somehow an abstraction of “unsigned long”. DWORD is an abstraction, and that’s what should have been used for ALL 32-bit types in the kernel. The CHAR, UCHAR, SHORT, USHORT, INT, UINT, LONG and ULONG types are idiotic and have been all along. No one in their right might would ever have defined ULONG be anything other than “unsigned long”. Therefore, it’s not an abstraction. It’s a typing shortcut.

Had DWORD been used throughout, Microsoft could have changed “long” to 64-bits without any impact. In my view, that would have been a much more sensible approach. There was ample existing prior art for other 64-bit platforms that demonstrated the viability of that choice.

It was to purposefully separate them from the native system/compiler data types, and provide portability for kernel-mode code.

Do you really believe that “LONG” is separate from “long”? Really?

If you want to air personal datatype annoyances, MY biggest one is the C# datatypes. char in C# is 2 bytes, and long is 64-bits. Very, very, very annoying. I had my lead check-in a whole series of changes to a rather high visibility project once with the explanation “Changed ‘char’ by ‘byte’ everywhere, because Peter apparently didn’t realize ‘char’ was 2 bytes” Very embarrassing.

To be fair, that problem occurred was not because the choices in C# are bad. It’s because you were approaching C# with C firmly lodged in your brain. The decision to have char be 2 bytes is quite defensible. Easy internationalization is more important than programmer familiarity.

–
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

24

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

25



> It has an intrinsic width. This is the very POINT of Windows NT having abstract data types.

I dunno, but I would rather say that the sole point of all these “NT abstract data types”
is just to create a confusion and to complicate the things that are normally supposed to be pretty simple by the very definition. In other words, MSFT did jut something that it is really good at - no matter where you look in the Windows world, you will see this picture again and again and again…

Anton Bassov

26

DWORD dw;
dw = (DWORD)Li.QuadPart;

And, since you’ve lost the upper 32 bits here, be prepared for a bug which once ruined the Ariane rocket :slight_smile:

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
> Hello all
>
> Is there any way to convert LARGE_INTEGER to DWORD?
>
> Thanks
>
>
>

27

Yes. Absolutely. They did it just to annoy you, Anton. I remember Cutler saying at one point “We’re going to use abstract data types, just so we can piss off this one guy, Anton Bassov. He’s still in University, but still, it’ll be worth it.”

Peter
OSR
@OSRDrivers

28

IOW, a long con. Man, Dave is freakin’ brilliant!

d

Bent from my phone

From: xxxxx@osr.commailto:xxxxx
Sent: ?5/?5/?2015 12:56 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] convert LARGE_INTEGER to DWORD



Yes. Absolutely. They did it just to annoy you, Anton. I remember Cutler saying at one point “We’re going to use abstract data types, just so we can piss off this one guy, Anton Bassov. He’s still in University, but still, it’ll be worth it.”

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</mailto:xxxxx></mailto:xxxxx>

29

+1

mm

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, May 05, 2015 1:05 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] convert LARGE_INTEGER to DWORD

IOW, a long con. Man, Dave is freakin’ brilliant!

d

Bent from my phone

From: xxxxx@osr.com
Sent: ?5/?5/?2015 12:56 PM
To: Windows System Software Devs Interest List mailto:xxxxx
Subject: RE:[ntdev] convert LARGE_INTEGER to DWORD



Yes. Absolutely. They did it just to annoy you, Anton. I remember Cutler
saying at one point “We’re going to use abstract data types, just so we can
piss off this one guy, Anton Bassov. He’s still in University, but still,
it’ll be worth it.”

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

—
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</mailto:xxxxx>

30

It goes back farther than that. Point me to serious C-coded OS or systems project which doesn?t have concrete datatypes for specific sizes of the loosely defined C types. This is a freemasons scale conspiracy.

-p

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Tuesday, May 5, 2015 1:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] convert LARGE_INTEGER to DWORD

+1

mm

From: xxxxx@lists.osr.commailto:xxxxx [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, May 05, 2015 1:05 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] convert LARGE_INTEGER to DWORD

IOW, a long con. Man, Dave is freakin’ brilliant!

d

Bent from my phone
________________________________
From: xxxxx@osr.commailto:xxxxx
Sent: ?5/?5/?2015 12:56 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] convert LARGE_INTEGER to DWORD



Yes. Absolutely. They did it just to annoy you, Anton. I remember Cutler saying at one point “We’re going to use abstract data types, just so we can piss off this one guy, Anton Bassov. He’s still in University, but still, it’ll be worth it.”

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

—
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</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

31

Peter,

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.

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 Peter Wieland
Sent: Tuesday, May 05, 2015 4:45 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] convert LARGE_INTEGER to DWORD

It goes back farther than that. Point me to serious C-coded OS or systems
project which doesn?t have concrete datatypes for specific sizes of the
loosely defined C types. This is a freemasons scale conspiracy.

-p

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Tuesday, May 5, 2015 1:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] convert LARGE_INTEGER to DWORD

+1

mm

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, May 05, 2015 1:05 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] convert LARGE_INTEGER to DWORD

IOW, a long con. Man, Dave is freakin’ brilliant!

d

Bent from my phone

From: xxxxx@osr.com
Sent: ?5/?5/?2015 12:56 PM
To: Windows System Software Devs Interest List mailto:xxxxx
Subject: RE:[ntdev] convert LARGE_INTEGER to DWORD



Yes. Absolutely. They did it just to annoy you, Anton. I remember Cutler
saying at one point “We’re going to use abstract data types, just so we can
piss off this one guy, Anton Bassov. He’s still in University, but still,
it’ll be worth it.”

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
http:

—
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
http:

—
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
http:

—
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</http:></http:></http:></mailto:xxxxx>

32

Further evidence of said conspiracy ? the types are so abstract now that the
academics have no choice by to annotate their code with insightful comments
like:

INT x = 69; // This is an integer

mm

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Tuesday, May 05, 2015 1:45 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] convert LARGE_INTEGER to DWORD

It goes back farther than that. Point me to serious C-coded OS or systems
project which doesn?t have concrete datatypes for specific sizes of the
loosely defined C types. This is a freemasons scale conspiracy.

-p

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Tuesday, May 5, 2015 1:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] convert LARGE_INTEGER to DWORD

+1

mm

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, May 05, 2015 1:05 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] convert LARGE_INTEGER to DWORD

IOW, a long con. Man, Dave is freakin’ brilliant!

d

Bent from my phone

From: xxxxx@osr.com
Sent: ?5/?5/?2015 12:56 PM
To: Windows System Software Devs Interest List mailto:xxxxx
Subject: RE:[ntdev] convert LARGE_INTEGER to DWORD



Yes. Absolutely. They did it just to annoy you, Anton. I remember Cutler
saying at one point “We’re going to use abstract data types, just so we can
piss off this one guy, Anton Bassov. He’s still in University, but still,
it’ll be worth it.”

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

—
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

—
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</mailto:xxxxx>

33

> -----Original Message-----

From: xxxxx@lists.osr.com [mailto:bounce-582127-
xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Tuesday, May 05, 2015 9:02 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] convert LARGE_INTEGER to DWORD

[snip]

If you want to air personal datatype annoyances, MY biggest one is the C#
datatypes. char in C# is 2 bytes, and long is 64-bits. Very, very, very
annoying. I had my lead check-in a whole series of changes to a rather
high visibility project once with the explanation “Changed ‘char’ by
‘byte’ everywhere, because Peter apparently didn’t realize ‘char’ was 2
bytes” Very embarrassing.

[snip]

You’re not the only one. I had to fix a bug in someone else’s C# P/Invoke code. Turned out they didn’t know the size of int/long either. I didn’t know about that until I hunted that bug, as I was new to coding in C# and the CLR at the time.

From that time on, I’ve used System.(U)Int64/32 exclusively, so I don’t never wonder what size things are. Some people hate that.

I also use var everywhere I can. Some people hate that, too.

:slight_smile:

Phil

Not speaking for LogRhythm
Phil Barila | Senior Software Engineer
720.881.5364 (w)
LogRhythm, Inc.
The Security Intelligence Company
A LEADER in Gartner’s SIEM Magic Quadrant (2012-2014)
Reader’s Trust Award in SC Magazine (2015) | Perfect 5-Star Rating in SC Magazine (2009-2014)
Selected by SANS community as “BEST SIEM” (2014 survey)

34

> If you want to air personal datatype annoyances, MY biggest one is the C#

datatypes. char in C# is 2 bytes, and long is 64-bits. Very, very, very
annoying. I had my lead check-in a whole series of changes to a rather high
visibility project once with the explanation “Changed ‘char’ by ‘byte’
everywhere, because Peter apparently didn’t realize ‘char’ was 2 bytes” Very
embarrassing.

Doesn’t c# define a bunch of [u]intX types, where X is 8, 16, 32, or 64? If you care about the width this is what should be used. No mystery about the width of the types there :slight_smile:

James

35

> Yes. Absolutely. They did it just to annoy you, Anton. I remember Cutler

saying at one point “We’re going to use abstract data types, just so we can piss
off this one guy, Anton Bassov. He’s still in University, but still, it’ll be worth it.”

I DO appreciate your sarcasm, but a minor correction to your statement has to be made …

In fact, I had NO IDEA of what the PC actually looked like at the time Windows NT got designed. If I did I would have chosen another field of studies,and, probably (in fact, quite likely), would have studied like a nerd, rather than doing it the way I did (i.e. without having a SINGLE notebook throughout 5 years that wasted in the university ). Therefore, “He’s still in University” part should be replaced with “he is yet to learn what the PC is like” one…

Anyway, lets get back to Cutler and NT.His distaste for the family of OSes designed around “By programmers, for programmers” principle is too well-known, right.I guess doing things in some programmer-friendly way must be, in his opinion, a way too UNIX-like. Therefore, in order to be 100% sure that his “masterpiece” is most definitely as UNIX -unlike as only possible he decided to do everything he possibly could to make it as cumbersome and annoying for programmers as one can possibly imagine…

BTW, would not it be a good idea to move proceed with discussion to kcalloc thread - it seems to have finally died at 174 posts, and I have been always dreaming about participating in a thread that crosses 200-posts threshold (I think we did not have such threads on NTDEV in so far, did we)…

Anton Bassov

36

> This is a freemasons scale conspiracy.

Be careful with the statements like that - as I can see, our “Windows fanboy” woke up recently and has already posted to another thread. If he notices this statement it is more than likely to trigger yet another “transition” to the topic of his fixation…

Anton Bassov

37

I just wonder why nobody has already menioned bit operations ( shift , bit count , bit search ) where you MUST know the size of the
variable. As a programmer that started writing code in assembly like myself , I have a burned-in “trigger” that always thinks about
the size of a variable when acessing it. It runs as a sort of background process. I understand James Harper very well when writing
about a “bunch of [u]intX types”. In fact , this bunch is a very , very small amount of what is definded in headers all around. I
just wonder who is using for example “DWORDLONG” or “ULONG32” and who can explain me the logic and sense that used the “inventer”
of these ones ( wtypes.h ) :

typedef unsigned long DWORD;
typedef DWORD ULONG;
typedef unsigned __int64 DWORDLONG;
typedef unsigned __int64 ULONGLONG;

Christiaan

38

Windows as a platform has an integer type system (including logical and sized).
C/C++ has an integer type system.
Compilers ship with headers that define sized integers in a type system (stdint.h)

There are safe (and not so safe) ways of moving values between systems and representations.

What is the big deal?

If you want to write highly portable code then pick a highly portable integer type system (like native types or stdint.h abstractions).

If you want to write Windows code that that does not constantly require scratching your head to wonder if that cast warning can be ignored then use the Windows platform integer type system.

Copper or Aluminum. Both carry electricity. Just pay careful attention to where you join them. Or at least pick a good electrician.

-dave cattley

39

Well, I am afraid the only people in the world who can explain it to you are the ones
who had actually invented the above “masterpieces”.The only thing left to us is to speculate about it.

If you asked me about it, my suggestion would be pretty much the same as the one that I had made earlier on this thread.

Don’t forget that C and UNIX are closely related. Apparently, the inventors of the above “masterpieces” would have preferred to write their kernel in some language other than C, but writing a compiler and a new language was, apparently, considered to be a bit to the extreme. After all, it would require quite a bit of extra resources, so that NT architects would have to justify it somehow. Lets face it - if you are asked why C is unfit for the purpose of designing a kernel, saying " just because C is closely related to UNIX, and I hate UNIX" would hardly provide a viable justification for hiring a compiler team. Therefore, they had to do it in C.

In order to alleviate the pain that they had to endure, they decided to make it look as C-unlike as possible. To be honest, I just don’t see any other explanation as to why someone may want to rename all internal C datatypes.

Concerning the choice of names, I guess they chose these names simply to make the whole thing as programmer-unfriendly as possible, effectively ensuring that “By programmers, for programmers”
principle definitely does not apply to their “creation”. To be honest, I just don’t see any other explanation as to why someone may want to chose something as ridiculous as
“typedef unsigned __int64 DWORDLONG;”

Concerning the actual style, I guess they chose it because they wanted to make Windows programming particularly enjoyable to those folks who prefer to have CapsLock key on 90% of the time. If you read NTDEV on regular basis you must that these folks tend to be “MSFT aficinados”…

Anton Bassov

40

Hahaha @Peter always make my day, not that he is impressive knowledgeable individual, yet humor sense ads that perfection. I_LOVE_OSR (y)

Best ever mailing list I have signed up for .

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: 05 May 2015 20:56
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] convert LARGE_INTEGER to DWORD

[quote]
I would rather say that the sole point of all these “NT abstract data types” is just to create a confusion [/quote]

Yes. Absolutely. They did it just to annoy you, Anton. I remember Cutler saying at one point “We’re going to use abstract data types, just so we can piss off this one guy, Anton Bassov. He’s still in University, but still, it’ll be worth it.”

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

Micron Europe Limited
Registered in England, Company No. 02341071
Registered Office: L’Avenir, Opladen Way
Bracknell, Berkshire RG12 0PH, UK