Now that we’re in this brave new world of 64-bit architectures and
compilers, are there any plans to provide kernel APIs that take native
64-bit values instead of LARGE_INTEGERs? The latter are awkward to
manipulate vs. ULONGLONG, for example.
-sd
I could be mistaken, but I believe that LARGE_INTEGER is defined to be a
union of a LONGLONG and a struct containing its parts. Therefore it has
exactly the same layout as a LONGLONG, and you should be able to pass a
LONGLONG (or pointer thereto) to anything that takes a LARGE_INTEGER.
You might have to add a cast.
Steve Dispensa wrote:
Now that we’re in this brave new world of 64-bit architectures and
compilers, are there any plans to provide kernel APIs that take native
64-bit values instead of LARGE_INTEGERs? The latter are awkward to
manipulate vs. ULONGLONG, for example.-sd
–
…/ray..
Please remove “.spamblock” from my email address if you need to contact
me outside the newsgroup.
> I could be mistaken, but I believe that LARGE_INTEGER is defined to be a
union of a LONGLONG and a struct containing its parts. Therefore it has
exactly the same layout as a LONGLONG, and you should be able to pass a
LONGLONG (or pointer thereto) to anything that takes a LARGE_INTEGER.
You might have to add a cast.
Not quit exact :
On Intel32 you need to do something like : LARGER_INTEGER MyLARGE_INTEGER.QuadPart = (LONGLONG)My64bitValue ;
See NTDEF.h
Steve Dispensa wrote:
> Now that we’re in this brave new world of 64-bit architectures and
> compilers, are there any plans to provide kernel APIs that take native
> 64-bit values instead of LARGE_INTEGERs? The latter are awkward to
> manipulate vs. ULONGLONG, for example.
>
> -sd
>
>
>–
…/ray..Please remove “.spamblock” from my email address if you need to contact
me outside the newsgroup.
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@compaqnet.be
To unsubscribe send a blank email to xxxxx@lists.osr.com
On Thu, 2004-08-12 at 11:44, Christiaan Ghijselinck wrote:
> I could be mistaken, but I believe that LARGE_INTEGER is defined to be a
> union of a LONGLONG and a struct containing its parts. Therefore it has
> exactly the same layout as a LONGLONG, and you should be able to pass a
> LONGLONG (or pointer thereto) to anything that takes a LARGE_INTEGER.
> You might have to add a cast.Not quit exact :
On Intel32 you need to do something like : LARGER_INTEGER MyLARGE_INTEGER.QuadPart = (LONGLONG)My64bitValue ;
Furthermore, this wouldn’t work on a big-endian box, as LARGE_INTEGER
has the parts ordered statically. At least, I didn’t see an
#if<big_endian> cpp directive in ntdef.
-sd</big_endian>
> Furthermore, this wouldn’t work on a big-endian box, as LARGE_INTEGER
has the parts ordered statically. At least, I didn’t see an
#if<big_endian> cpp directive in ntdef.
From what I know, Windows NT was never ever ported to a big-endian CPU.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com</big_endian>
Because little endian was a requirment for NT. So you would never see a
big_endian directive.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
“Steve Dispensa” wrote in message
news:xxxxx@ntdev…
> On Thu, 2004-08-12 at 11:44, Christiaan Ghijselinck wrote:
> > > I could be mistaken, but I believe that LARGE_INTEGER is defined to be
a
> > > union of a LONGLONG and a struct containing its parts. Therefore it
has
> > > exactly the same layout as a LONGLONG, and you should be able to pass
a
> > > LONGLONG (or pointer thereto) to anything that takes a LARGE_INTEGER.
> > > You might have to add a cast.
> >
> > Not quit exact :
> >
> > On Intel32 you need to do something like : LARGER_INTEGER
MyLARGE_INTEGER.QuadPart = (LONGLONG)My64bitValue ;
>
> Furthermore, this wouldn’t work on a big-endian box, as LARGE_INTEGER
> has the parts ordered statically. At least, I didn’t see an
> #if<big_endian> cpp directive in ntdef.
>
> -sd
>
>
></big_endian>
Good point… But then, how would this work appropriately on both platforms
(big-endian, little-endian); since it is a union of a ULONGLONG and two
*statically ordered* ULONGs?
LARGE_INTEGER li;
li.QuadPart=0x0123456789ABCDEF;
Mat
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Steve Dispensa
Sent: Thursday, August 12, 2004 1:39 PM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] LARGE_INTEGER
On Thu, 2004-08-12 at 11:44, Christiaan Ghijselinck wrote:
> I could be mistaken, but I believe that LARGE_INTEGER is defined to be a
> union of a LONGLONG and a struct containing its parts. Therefore it has
> exactly the same layout as a LONGLONG, and you should be able to pass a
> LONGLONG (or pointer thereto) to anything that takes a LARGE_INTEGER.
> You might have to add a cast.Not quit exact :
On Intel32 you need to do something like : LARGER_INTEGER
MyLARGE_INTEGER.QuadPart = (LONGLONG)My64bitValue ;
Furthermore, this wouldn’t work on a big-endian box, as LARGE_INTEGER
has the parts ordered statically. At least, I didn’t see an
#if<big_endian> cpp directive in ntdef.
-sd
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@encentrus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com</big_endian>
Not to mention how would the statically ordered ULONGs get converted to
big-endian.
Of course, big-endian architecture isn’t supported, so this is all moot.
Seeing as how the *entire* LARGE_INTEGER typedef is a union consisting
entirely of nothing but a QuadPart that is a LONGLONG and a struct of 2
ULONGs, I still think you could probably get away with something like:
LONGLONG llMine = 0x1234123412341234;
KeSetTimer(myTimer, *(LARGE_INTEGER*)&llMine, NULL);
(You might not even need the pointer casts in C… I only tried
compiling it in C++, which is unhappy about casting directly because of
a lack of a constructor).
Mathieu Routhier wrote:
Good point… But then, how would this work appropriately on both platforms
(big-endian, little-endian); since it is a union of a ULONGLONG and two
*statically ordered* ULONGs?LARGE_INTEGER li;
li.QuadPart=0x0123456789ABCDEF;Mat
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Steve Dispensa
Sent: Thursday, August 12, 2004 1:39 PM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] LARGE_INTEGEROn Thu, 2004-08-12 at 11:44, Christiaan Ghijselinck wrote:
>>I could be mistaken, but I believe that LARGE_INTEGER is defined to be a
>>union of a LONGLONG and a struct containing its parts. Therefore it has
>>exactly the same layout as a LONGLONG, and you should be able to pass a
>>LONGLONG (or pointer thereto) to anything that takes a LARGE_INTEGER.
>>You might have to add a cast.
>
>Not quit exact :
>
>On Intel32 you need to do something like : LARGER_INTEGERMyLARGE_INTEGER.QuadPart = (LONGLONG)My64bitValue ;
Furthermore, this wouldn’t work on a big-endian box, as LARGE_INTEGER
has the parts ordered statically. At least, I didn’t see an
#if<big_endian> cpp directive in ntdef.
>
> -sd
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@encentrus.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
–
…/ray..
Please remove “.spamblock” from my email address if you need to contact
me outside the newsgroup.</big_endian>
On Thu, 2004-08-12 at 12:50, Maxim S. Shatskih wrote:
> Furthermore, this wouldn’t work on a big-endian box, as LARGE_INTEGER
> has the parts ordered statically. At least, I didn’t see an
> #if<big_endian> cpp directive in ntdef.
>
> >From what I know, Windows NT was never ever ported to a big-endian CPU.
Perhaps, but for an OS with a major goal of portability, it would seem
to be foolish to limit yourself to little-endian architectures. There
are plenty of big-endian chips in the world, and who’s to say there
won’t be more.
I’d think Microsoft would rather maintain endian-agnosticismby
supplying APIs with proper 64-bit prototypes, rather than making people
figure out the LARGE_INTEGER hack described above.
OK, on further review, it would be impossible to build Windows on a
big-endian cpu, because the LARGE_INTEGER QuadPart item will be out of
order; i.e. you couldn’t test (a.QuadPart > b.QuadPart) because the
bytes would lay out wrong (byte 0 == LSB):
QuadPart should be: 7 6 5 4 3 2 1 0
but instead it would be: 3 2 1 0 7 6 5 4
Lots of Windows code would need to be re-written (or at least any part
that referenced QuadPart). Furthermore, every driver in the world that
uses LARGE_INTEGER.QuadPart would need a bit of a re-write.
Neato.
-sd</big_endian>
LARGE_INTEGER is only one of many. NT did not set out to be endian-agnostic
and it has met that goal completely
=====================
Mark Roddy
-----Original Message-----
From: Steve Dispensa [mailto:xxxxx@positivenetworks.net]
Sent: Thursday, August 12, 2004 2:25 PM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] LARGE_INTEGER
On Thu, 2004-08-12 at 12:50, Maxim S. Shatskih wrote:
> Furthermore, this wouldn’t work on a big-endian box, as
> LARGE_INTEGER has the parts ordered statically. At least, I didn’t
> see an #if<big_endian> cpp directive in ntdef.
>
> >From what I know, Windows NT was never ever ported to a big-endian CPU.
Perhaps, but for an OS with a major goal of portability, it would seem to be
foolish to limit yourself to little-endian architectures. There are plenty
of big-endian chips in the world, and who’s to say there won’t be more.
I’d think Microsoft would rather maintain endian-agnosticism
supplying APIs with proper 64-bit prototypes, rather than making people
figure out the LARGE_INTEGER hack described above.
OK, on further review, it would be impossible to build Windows on a
big-endian cpu, because the LARGE_INTEGER QuadPart item will be out of
order; i.e. you couldn’t test (a.QuadPart > b.QuadPart) because the bytes
would lay out wrong (byte 0 == LSB):
QuadPart should be: 7 6 5 4 3 2 1 0
but instead it would be: 3 2 1 0 7 6 5 4
Lots of Windows code would need to be re-written (or at least any part that
referenced QuadPart). Furthermore, every driver in the world that uses
LARGE_INTEGER.QuadPart would need a bit of a re-write.
Neato.
-sd
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com</big_endian>
Steve Dispensa wrote:
> I'd think Microsoft would rather maintain endian-agnosticism 
by
> supplying APIs with proper 64-bit prototypes, rather than making
> people figure out the LARGE_INTEGER hack described above.
The QuadPart element is fine, because it's defined as a LONGLONG anyway
(which presumably would be compiled properly on various architectures).
It's the LowPart and HighPart that would have problems. Even there, a
quick #ifdef could fix that if they really wanted to.
I think we can safely say that there's no need for *binary*
compatibility with big-endian machines, even if one were to admit that
it might be nice to support such chips in the future.
A "proper" 64 bit API isn't noticably different. I doubt that the code
internally uses the low and high parts.
OK, on further review, it would be impossible to build Windows on a
big-endian cpu, because the LARGE_INTEGER QuadPart item will be out of
order; i.e. you couldn't test (a.QuadPart > b.QuadPart) because the
bytes would lay out wrong (byte 0 == LSB):
Only if you assigned into or read out of the low and high parts. So don't?
QuadPart should be: 7 6 5 4 3 2 1 0
but instead it would be: 3 2 1 0 7 6 5 4
../ray..
Please remove ".spamblock" from my email address if you need to contact
me outside the newsgroup.
On Thu, 2004-08-12 at 15:38, Ray Trent wrote:
I think we can safely say
compatibility with big-endian machines, even if one were to admit that
it might be nice to support such chips in the future.
I’m actually talking about source compatibility (binary compatibility
between little-endian and big-endian boxes would be a neat trick). In a
big-endian box, code that assumes:
a.HighPart == (a.QuadPart && 0xffffffff00000000)
would break due to the very definition of LARGE_INTEGER.
> QuadPart should be: 7 6 5 4 3 2 1 0
> but instead it would be: 3 2 1 0 7 6 5 4It’s more complicated than that since the LONG/ULONG parts are byte
reversed too, but sure…
HighPart should have the high bytes (4, 5, 6, and 7), but because it’s a
big-endian box, it’d be 7 6 5 4 in memory. Same for LowPart (3 2 1 0).
Then, in the struct, LowPart comes before HighPart, so you reverse the
halves, making QuadPart 3 2 1 0 7 6 5 4. Or have I screwed it up?
Anyway, this is totally academic at this point…
-sd
Go to the white board and write 1000000 times,
“Windows was never intended to support big endian, this was a design
decision”
Actually, I have seen systems that were that messed up badly in performance
handling or readability/maintainability when trying to endian independent.
Since now every major server CPU is capable of running little endian there
is little need.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
“Ray Trent” wrote in message
news:xxxxx@ntdev…
> Steve Dispensa wrote:
> > I’d think Microsoft would rather maintain endian-agnosticism by
> > supplying APIs with proper 64-bit prototypes, rather than making
> > people figure out the LARGE_INTEGER hack described above.
>
> The QuadPart element is fine, because it’s defined as a LONGLONG anyway
> (which presumably would be compiled properly on various architectures).
> It’s the LowPart and HighPart that would have problems. Even there, a
> quick #ifdef could fix that if they really wanted to.
>
> I think we can safely say that there’s no need for binary
> compatibility with big-endian machines, even if one were to admit that
> it might be nice to support such chips in the future.
>
> A “proper” 64 bit API isn’t noticably different. I doubt that the code
> internally uses the low and high parts.
>
> > OK, on further review, it would be impossible to build Windows on a
> > big-endian cpu, because the LARGE_INTEGER QuadPart item will be out of
> > order; i.e. you couldn’t test (a.QuadPart > b.QuadPart) because the
> > bytes would lay out wrong (byte 0 == LSB):
>
> Only if you assigned into or read out of the low and high parts. So don’t?
>
> > QuadPart should be: 7 6 5 4 3 2 1 0
> > but instead it would be: 3 2 1 0 7 6 5 4
>
> It’s more complicated than that since the LONG/ULONG parts are byte
> reversed too, but sure…
> –
> …/ray..
>
> Please remove “.spamblock” from my email address if you need to contact
> me outside the newsgroup.
>
On Thu, 2004-08-12 at 16:14, Don Burn wrote:
Go to the white board and write 1000000 times,
999997…
999998…
999999…
10000000!
I started running out of whiteboard space at about 57, but then I
optimized my algorithm for space instead of time and implemented erase()
after every 50 sentences.