convert LARGE_INTEGER to DWORD

Hello all

Is there any way to convert LARGE_INTEGER to DWORD?

Thanks

Have you ever learned programming in C?

First learn how to put 10 pounds of sh*t into a 5 pound bag.

Thomas F. Divine

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Monday, May 4, 2015 10:33 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] convert LARGE_INTEGER to DWORD

Hello all

Is there any way to convert LARGE_INTEGER to DWORD?

Thanks


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

I meant to say: First learn how to save 64 bits of information in a 32 bit
container.

Thomas F. Divine

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Monday, May 4, 2015 10:33 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] convert LARGE_INTEGER to DWORD

Hello all

Is there any way to convert LARGE_INTEGER to DWORD?

Thanks


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

xxxxx@gmail.com wrote:

Hello all

Is there any way to convert LARGE_INTEGER to DWORD?

I usually tend to apologize when our group of piranhas unleashes its
carnivorous fury on an unsuspecting naive question like this, but in
this case I’m afraid it was deserved.

Did you go into the header files to see what a LARGE_INTEGER is? Did
you look in any of the samples to see how they are handled? Do you
understand what such a conversion will do? In what context do you need
to do this?


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

To take Tim’s response a little further, if you look at LARGE_INTEGER you
will find it is a structure with a 64bit field QuadPart. You could assign
this field directly to DWORD of course you can truncate things, and cause
all kinds of problems too. You might consider looking at RtlULongLongToUInt
in ntintsafe.h which will assign the value and return an error on
truncation.

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

Sure, but do you know the equivalent of kcalloc in Windows? THAT’s the question that really separates the men from the boys.

Peter
OSR
@OSRDrivers

The OP - the only thing that I can tell you for sure is that you have to be INCREDIBLY dumb in order to make Thomas speak to you this way. Thomas happens to be, probably, the most patient and helpful poster that you can possibly come across on this list. Therefore, if you see such a reaction to your question from him you can take it as an indicator of your idiocy being so profound that it cannot be described by any words…

Anton Bassov

Thomas,

First learn how to put 10 pounds of sh*t into a 5 pound bag.

Actually, it reminds me of asking a kid “What is heavier -1 pound of iron or 1 pound of feather”.
I just wonder what the OP’s answer would be like…

Anton Bassov

Minus one pound of iron is sure lighter.

> Minus one pound of iron is sure lighter.

Good one, Alex…

Anton Bassov

Thanks Don,

And Yes i am not worried about loss of data in my case.

so conversion from LARGE_INTEGER to DWORD will be fine for me as per my design.

Thanks for Lovely comments. :slight_smile:

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.

DWORD is another form of LONG or any data type of size 4 bytes/32-bits
QWORD is another form of LONG or any data type of size 8 bytes/64-bits

Answer to your question, if you want to cast or convert LARGE_INTEGER data type to DWORD, then you better understand how LARGE_INTEGER works.

LARGE_INTEGER is a union made up of two structs, was defined back in the days when the vast majority of machines architectures were 32-bit, yet there was some 64-bit, so LARGE_INTEGER was defined to be like " cross-architecture " way to define integer of 64-bit long on even 32-bit machines .

So basically, if you machine supports 64-bit then you will be using one structure from LARGE.INTEGER union, which is LARGE_INTEGER.Quadpart . and if your system doesn’t support 64-bit and you want to store 64-bit integer, then you use two fields of 32-bit size in the second structure, which is LARGE_INTEGER.LowPart & LARGE_INTEGER.HighPart .

Back to your main question, so if you want to convert LARGE_INTEGER TO DWORD, then you need first to find which is structure is defined, either .Quadpart OR .LowPart & HighPart,

then you probably need to copy the content from LARGE_INTEGER structures to your DWORD variable through casting or memcpy .

Guys please correct my explanation if there is anything wasn’t right .

I could be wrong, but I assumed LARGE_INTEGER is an unfortunate side effect invented because the compiler had no 64-bit integers back then. It meant lots of other dumb APIs like GetFileSize returning half the size through the return value and the other half through a parameter.

To me, special case using LARGE_INTEGER.LowPart on 32-bit compiles would seem error prone and not real readable. If you want to use a data type that floats to 32/64-bits based on the target architecture then select an appropriate type. As an aside, I think it was a major design mistake Microsoft compilers fixed both ‘int’ and ‘long’ to 32-bits when compiling for 64-bits and instead invented proprietary curiosities like __int3264. Good thing the jokers that made those decisions apparently weren’t around when the 32-bit compiler was made otherwise int would still be 16-bits and we’d have to deal with proprietary __int1632 and __int32 thingies.

You can pretty much count on that :wink:

[quote]
DWORD is another form of LONG or any data type of size 4 bytes/32-bits
QWORD is another form of LONG or any data type of size 8 bytes/64-bits

[quote]

OK, so there’s a typo there. Aside from that, both DWORD and QWORD are UNSIGNED and LONG is SIGNED. Also, none of these is another “form” of anything. They’re just synonyms. So on Windows:

DWORD is a synonym for ULONG, and is always 32 bits.
QWORD is a synonym for unsigned _int64, and is always 64 bits.

Here’s a really important lesson in practical engineering: When you don’t know, don’t guess. And if you’re going to guess, make sure you say “I’m guessing” or “I would suppose” and say that REALLY CLEARLY. I actually know of a very good engineer who had a bad habit of stating his suppositions as fact, who got an exceptionally bad reputation because of it. His career never recovered.

OK, Mr. Abushima, you have had your obligatory student engineer lecture for the day.

Now, in your guess, you were ALMOST correct.

LARGE_INTEGER was defined back in the days when Windows had no native 64-bit data type (because all the machines on which Windows NT ran were 32-bit) and there was a need to express things such as physical memory addresses and offsets into files, which have *always* been 64-bit values in Windows NT.

The MSVC compiler supports _int64 on Windows systems with both 32-bit and 64-bit memory addressing. Therefore, LARGE_INTEGER is purely a legacy with which we are stuck. In all cases, these days you can simply use the .QuadPart (which is a QWORD) and you’re good to go.

Peter
OSR
@OSRDrivers

I couldn’t disagree more.

I led a large number of driver porting sessions, and gave a significant number of lectures on porting 32-bit to 64-bit drivers, back in the day for Microsoft, AMD, and Intel. I can tell you that THE most confusing thing for people was the length of an ULONG. Once you told them “On Windows, an ULONG is always 32-bit. An ULONG is an ULONG. Always.” They visibly relaxed. This meant that the VAST majority of their code was “the same” on 64-bit Windows as it was on 32-bit Windows. Yay!

After all, if you intended a POINTER, you deserve what you get if you type that pointer as an ULONG and not a PVOID (or P).

If you want an unsigned value that is pointer width that you can do arithmetic with, the data type is ULONG_PTR. I agree this is a confusing name, but there really is no name for this that wouldn’t be confusing. So, if you had pointers in your code that were type ULONG (so you could do simple math with them, and not pointer arithmetic) it is quite a straight-forward job to ferret those out and make them ULONG_PTR.

Having ULONG change from system to system, depending on the pointer width, is a horrible idea. It’s a data type. It has an intrinsic width. This is the very POINT of Windows NT having abstract data types.

Peter
OSR
@OSRDrivers

Peter you’re amazing, I really appreciate your correction and What you said is deeply making sense, Although I couldn’t find a Like Button to click on, yet Big Thumbs Up (y) .

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

[quote]
Guys please correct my explanation if there is anything wasn’t right [/quote]

You can pretty much count on that :wink:

[quote]
DWORD is another form of LONG or any data type of size 4 bytes/32-bits QWORD is another form of LONG or any data type of size 8 bytes/64-bits [quote]

OK, so there’s a typo there. Aside from that, both DWORD and QWORD are UNSIGNED and LONG is SIGNED. Also, none of these is another “form” of anything. They’re just synonyms. So on Windows:

DWORD is a synonym for ULONG, and is always 32 bits.
QWORD is a synonym for unsigned _int64, and is always 64 bits.

Here’s a really important lesson in practical engineering: When you don’t know, don’t guess. And if you’re going to guess, make sure you say “I’m guessing” or “I would suppose” and say that REALLY CLEARLY. I actually know of a very good engineer who had a bad habit of stating his suppositions as fact, who got an exceptionally bad reputation because of it. His career never recovered.

OK, Mr. Abushima, you have had your obligatory student engineer lecture for the day.

Now, in your guess, you were ALMOST correct.

LARGE_INTEGER was defined back in the days when Windows had no native 64-bit data type (because all the machines on which Windows NT ran were 32-bit) and there was a need to express things such as physical memory addresses and offsets into files, which have *always* been 64-bit values in Windows NT.

The MSVC compiler supports _int64 on Windows systems with both 32-bit and 64-bit memory addressing. Therefore, LARGE_INTEGER is purely a legacy with which we are stuck. In all cases, these days you can simply use the .QuadPart (which is a QWORD) and you’re good to go.

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

> I can tell you that THE most confusing thing for people was the length of an ULONG

I have no problem with ULONG and even INT insulating us and being whatever MS wishes to define them as. That’s totally ok to lock them at 32-bits. But the compiler ‘long’ data type being 32-bits on 64-bit architectures has created lots of trouble. Just think if int was still 16-bits like the old days for code portability–it would be crippling. Drivers shouldn’t use bare int and long often anyway, if ever.

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 was to purposefully separate them from the native system/compiler data types, and provide portability for kernel-mode code.

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.

Peter
OSR
@OSRDrivers