Hi,
Iam working on network driver, and can someone please point me to
a macro or function which can check endianness and convert the given
info into littleendian.
Thanks & Regards
ajay kumar v
The endianess of the data is dependant on the protocol so you have to know
it. There are functions RtlUshortByteSwap,
RtlUlongByteSwap, RtlUlonglongByteSwap for conversion.
–
Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“ajay kumar” wrote in message
news:xxxxx@ntdev…
> Hi,
> Iam working on network driver, and can someone please point me to a
> macro or function which can check endianness and convert the given info
> into littleendian.
>
> Thanks & Regards
> ajay kumar v
>
>
Hi Don Burn,
Thank You for the reply, the below specified
functions convert little endian to big endian and viceversa, but what
iam looking for is somewhat similar to function or macro(cpu_to_le32) in
linux …i.e,
if the architecture is little endian the input should be the output and
if the architecture is big endian the input should be converted into
little endian…
Thanks & Regards
ajay kumar v
Don Burn wrote:
The endianess of the data is dependant on the protocol so you have to know
it. There are functions RtlUshortByteSwap,
RtlUlongByteSwap, RtlUlonglongByteSwap for conversion.
Fascinating. Why would you need this on a platform that is always
little-endian?
:bangs head against desk:
Mark Roddy
On Fri, Jan 9, 2009 at 7:32 AM, ajay kumar
wrote:
> Hi Don Burn,
> Thank You for the reply, the below specified functions
> convert little endian to big endian and viceversa, but what iam looking for
> is somewhat similar to function or macro(cpu_to_le32) in linux …i.e,
>
> if the architecture is little endian the input should be the output and
> if the architecture is big endian the input should be converted into little
> endian…
>
> Thanks & Regards
> ajay kumar v
>
> Don Burn wrote:
>
>> The endianess of the data is dependant on the protocol so you have to know
>> it. There are functions RtlUshortByteSwap,
>> RtlUlongByteSwap, RtlUlonglongByteSwap for conversion.
>>
>>
>>
>>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> 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
>
#define cpu_to_le32(_i) (_i)
Windows is a little endian system.
I suspect, however, that in ripping off whatever linux code you are using,
you might be missing some point. Almost all network protocols (ok,
reader-makes-right excepted) define the wire protocol scalar multi-octet
fields as big endian. Are you sure you are not looking for ntohl() and
htonl() equivalents? As Mark notes parenthetically, your original quest
had both a trivial answer and indicates that you might have missed something
about the task at hand.
-dave
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of ajay kumar
Sent: Friday, January 09, 2009 7:32 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] conveting into little endian
Hi Don Burn,
Thank You for the reply, the below specified
functions convert little endian to big endian and viceversa, but what
iam looking for is somewhat similar to function or macro(cpu_to_le32) in
linux …i.e,
if the architecture is little endian the input should be the output and
if the architecture is big endian the input should be converted into
little endian…
Thanks & Regards
ajay kumar v
Don Burn wrote:
The endianess of the data is dependant on the protocol so you have to know
it. There are functions RtlUshortByteSwap,
RtlUlongByteSwap, RtlUlonglongByteSwap for conversion.
NTDEV is sponsored by OSR
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
Because Network Byte Order (required for IP addresses, port #s, counts,
checksums, etc.) is always big-endian.
joe
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Friday, January 09, 2009 7:59 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] conveting into little endian
Fascinating. Why would you need this on a platform that is always
little-endian?
:bangs head against desk:
Mark Roddy
On Fri, Jan 9, 2009 at 7:32 AM, ajay kumar
wrote:
Hi Don Burn,
Thank You for the reply, the below specified functions
convert little endian to big endian and viceversa, but what iam looking for
is somewhat similar to function or macro(cpu_to_le32) in linux …i.e,
if the architecture is little endian the input should be the output and
if the architecture is big endian the input should be converted into little
endian…
Thanks & Regards
ajay kumar v
Don Burn wrote:
The endianess of the data is dependant on the protocol so you have to know
it. There are functions RtlUshortByteSwap,
RtlUlongByteSwap, RtlUlonglongByteSwap for conversion.
—
NTDEV is sponsored by OSR
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 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
–
This message has been scanned for viruses and
dangerous content by http:</http:> MailScanner, and is
believed to be clean.
All Windows platforms are always little endian.
? S
-----Original Message-----
From: ajay kumar
Sent: Friday, January 09, 2009 04:40
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] conveting into little endian
Hi Don Burn,
Thank You for the reply, the below specified
functions convert little endian to big endian and viceversa, but what
iam looking for is somewhat similar to function or macro(cpu_to_le32) in
linux …i.e,
if the architecture is little endian the input should be the output and
if the architecture is big endian the input should be converted into
little endian…
Thanks & Regards
ajay kumar v
Don Burn wrote:
> The endianess of the data is dependant on the protocol so you have to know
> it. There are functions RtlUshortByteSwap,
> RtlUlongByteSwap, RtlUlonglongByteSwap for conversion.
>
>
>
—
NTDEV is sponsored by OSR
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 OP wanted to differentiate whether their Windows driver was hosted on big or little endian. It’s a good question to ask in a general platform note, though of course, Windows is always little-endian.
? S
From: Joseph M. Newcomer
Sent: Friday, January 09, 2009 06:09
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] conveting into little endian
Because Network Byte Order (required for IP addresses, port #s, counts, checksums, etc.) is always big-endian.
joe
________________________________
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Friday, January 09, 2009 7:59 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] conveting into little endian
Fascinating. Why would you need this on a platform that is always little-endian?
:bangs head against desk:
Mark Roddy
On Fri, Jan 9, 2009 at 7:32 AM, ajay kumar > wrote:
Hi Don Burn,
Thank You for the reply, the below specified functions convert little endian to big endian and viceversa, but what iam looking for is somewhat similar to function or macro(cpu_to_le32) in linux …i.e,
if the architecture is little endian the input should be the output and
if the architecture is big endian the input should be converted into little endian…
Thanks & Regards
ajay kumar v
Don Burn wrote:
The endianess of the data is dependant on the protocol so you have to know it. There are functions RtlUshortByteSwap,
RtlUlongByteSwap, RtlUlonglongByteSwap for conversion.
—
NTDEV is sponsored by OSR
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 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
–
This message has been scanned for viruses and
dangerous content by MailScannerhttp:</http:>, and is
believed to be clean.
—
NTDEV is sponsored by OSR
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
> if the architecture is little endian the input should be the output and if the architecture is big
endian the input should be converted into little endian…
Bizarre…
Look - all network protocols make an assumption that the machine is big-endian. Therefore, if you write
a protocol driver you should do exactly the opposite, i.e. leave data intact if the machine is big-endian and change byte order if the machine is little-endian. This is not needed under Windows, because Windows supports only little-endian architectures, but even if it did support big-endian machines you would have to do exactly the opposite to what you are trying to do (and it would not require any explicit checks anyway, because you would just use macros that are interpreted by the compiler in a way that is specific to your target architecture)…
In general, judging from you posts here, what you are trying to do is just to port Linux driver to Windows.
It does not work this way - you have to rewrite your driver completely, and change absolutely everything, apart from underlying logic (i.e dealing with device hardware specifics, with protocol specifics, etc)…
Anton Bassov
If you look at any specification (e.g scsi) etc, you will notice that
protocol defines the information according to byte positions.
I have always relied on shift macros to extract that information. This
way endian-ness becomes a non-issue.
harish
-----Original Message-----
From: xxxxx@hotmail.com [mailto:xxxxx@hotmail.com]
Sent: Friday, January 09, 2009 9:27 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] conveting into little endian
if the architecture is little endian the input should be the output
and if the architecture is big endian the input should be converted
into little endian…
Bizarre…
Look - all network protocols make an assumption that the machine is
big-endian. Therefore, if you write a protocol driver you should do
exactly the opposite, i.e. leave data intact if the machine is
big-endian and change byte order if the machine is little-endian. This
is not needed under Windows, because Windows supports only little-endian
architectures, but even if it did support big-endian machines you would
have to do exactly the opposite to what you are trying to do (and it
would not require any explicit checks anyway, because you would just
use macros that are interpreted by the compiler in a way that is
specific to your target architecture)…
In general, judging from you posts here, what you are trying to do is
just to port Linux driver to Windows.
It does not work this way - you have to rewrite your driver completely,
and change absolutely everything, apart from underlying logic (i.e
dealing with device hardware specifics, with protocol specifics,
etc)…
Anton Bassov
NTDEV is sponsored by OSR
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
> If you look at any specification (e.g scsi) etc, you will notice that protocol defines the information
according to byte positions.
Sure. As long as we speak about network-related protocols, they always make an assumption of big-endian order. Therefore, if machine is big-endian you don’t need any conversion when specifying, say, packet size - you can put it directly as unsigned short . However, on little-endian one you need a conversion macro that converts unsigned short from the host byte order into the network one when specifying packet information
( or vice versa when extracting information from a packet ). In any case, you don’t need any run-time checks here - this is simply a question of #ifdef in a header where macro is specified, and, taking into account that Windows does not support big-endian architectures anyway you don’t need any #ifdefs here either…
Anton Bassov
> Windows does not support big-endian architectures anyway you don’t
need
any #ifdefs here either…
I thought PPC and Alpha were big-endian only but I just consulted
Wikipedia and it says they are bi-endian and Windows ran in
little-endian mode on them. Curiously, of the PPC the Wikipedia article
says:
“In little-endian mode, the three lowest-order bits of the effective
address are exclusive-ORed with a three bit value selected by the length
of the operand. This is enough to appear fully little-endian to normal
software. An operating system will see a warped view of the world when
it accesses external chips such as video and network hardware. Fixing
this warped view of the world requires that the motherboard perform an
unconditional 64-bit byte swap on all data entering or leaving the
processor. Endianness thus becomes a property of the motherboard. An OS
that operates in little-endian mode on a big-endian motherboard must
both swap bytes and undo the exclusive-OR when accessing little-endian
chips.”
Sounds like those were fun times 
Do you think it will be a safe assumption that windows will never run
on a big-endian architecture?
James
> Do you think it will be a safe assumption that windows will never run on a big-endian architecture?
Well, in order to make it run on big-endian machine compiler support is needed, don’t you think???
Therefore, if they decide to re-introduce support for non-Intel architectures, they will have to provide a new
development environment - after all, contemporary WDK does not support anything, apart from x86,x86_64 and IA64.
It has not always worked this way - if you look at old UM header files you will notice quite interesting declarations (for example, of CONTEXT structure) that indicate support of a wide range of platforms…
Anton Bassov
In the very early stages, NT could be compiled big- or little-endian for
some target processors. I remember code in the early '90s that had comments
like “this will need to be cleaned up if we ever actually build it
big-endian.”
But the decision was taken long ago that there would be no attempt to make a
big-endian NT. Doing so would have implied some fundamental on-disk
incompatibilities in file formats for applications which were unaware of
endian issues. Can you imagine trying to keep the whole Windows ecosystem
clean such that all apps always wrote their data files perfectly
interoperably?
Furthermore, that PowerPC description from Wikipedia doesn’t really describe
the truth of the situation. (I have the marks on my back from that effort,
as I was at IBM working on the PowerPC port of NT.) PowerPC was natively
big-endian. It had a mode which was, from the point of view of application
software, indistinguishable from little-endian, and it was called
“Power-Endian.” It was possible to observe the differences between
little-endian and Power-Endian if you were interacting with weird corners of
the I/O busses, but only with some memory controllers. My memory was that
it had to do with how the caches were tagged. In any case, most
motherboards were built in such a way that even operating system software
could run without needing to worry about it, and this was certainly the case
with the Macs. Up until the G5, which only ran in big-endian mode,
VirtualPC from Connectix (and later Microsoft) actually flipped the
processor and the memory controller over to little-endian mode so that the
x86 emulator could run more efficiently. This was not theoretically easy
(without a full cache flush) in every implementation of “Power-Endian”
though I never personally saw an implementation that was a problem.
–
Jake Oshins
Hyper-V I/O Architect
Windows Kernel Team
This post implies no warranties and confers no rights.
“James Harper” wrote in message
news:xxxxx@ntdev…
>> Windows does not support big-endian architectures anyway you don’t
> need
>> any #ifdefs here either…
>
> I thought PPC and Alpha were big-endian only but I just consulted
> Wikipedia and it says they are bi-endian and Windows ran in
> little-endian mode on them. Curiously, of the PPC the Wikipedia article
> says:
>
> “In little-endian mode, the three lowest-order bits of the effective
> address are exclusive-ORed with a three bit value selected by the length
> of the operand. This is enough to appear fully little-endian to normal
> software. An operating system will see a warped view of the world when
> it accesses external chips such as video and network hardware. Fixing
> this warped view of the world requires that the motherboard perform an
> unconditional 64-bit byte swap on all data entering or leaving the
> processor. Endianness thus becomes a property of the motherboard. An OS
> that operates in little-endian mode on a big-endian motherboard must
> both swap bytes and undo the exclusive-OR when accessing little-endian
> chips.”
>
> Sounds like those were fun times
>
> Do you think it will be a safe assumption that windows will never run
> on a big-endian architecture?
>
> James
>
Jake,
Doing so would have implied some fundamental on-disk incompatibilities in file formats
for applications which were unaware of endian issues.
What do you mean??? It is understandable that a binary built for arch X just cannot run on arch Y ( I ignore emulators here), so that when a system loader on arch Y examines it it will just say “File format is not recognized”. Why on Earth an app’s code should be aware of endian issues - after all, it seems to be the question of compiler/preprocessor, i.e. of macro definitions in headers that come with the build environment…
Anton Bassov
Sometimes, programs have to read binary data that was produced on an
alternative-endian machine. There is a program of planetary orbital
dynamics that produced its output on a Sun workstation (big-endian) but the
source compiles and runs on any machine architecture; when it reads the data
file, it determines the endianness of the data file and will swap bytes in
the representation if it discovers that the data has an endianness opposite
the host machine (it also works if you were to generate the data on an x86
and then read that file on a Sun).
Given the binary data is .6GB, it is not desirable to re-generate it in
alternative formats, but it is expected the app will run on alternative
platforms, using the same binary master data file.
Similarly, sending binary data in a network packet has the same problem; I
send a byte-count as part of the header for my “data packet” (that is, the
protocol I implement above the IP level). I encode it in big-endian byte
order. Different apps will have to either swap it or not (but in user
space, ntohl handles this).
This is not a binary-code-compatibility issue, but a
binary-data-compatibility issue.
joe
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Saturday, January 10, 2009 2:28 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] conveting into little endian
Jake,
Doing so would have implied some fundamental on-disk incompatibilities
in file formats for applications which were unaware of endian issues.
What do you mean??? It is understandable that a binary built for arch X just
cannot run on arch Y ( I ignore emulators here), so that when a system
loader on arch Y examines it it will just say “File format is not
recognized”. Why on Earth an app’s code should be aware of endian issues -
after all, it seems to be the question of compiler/preprocessor, i.e. of
macro definitions in headers that come with the build environment…
Anton Bassov
NTDEV is sponsored by OSR
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
–
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.
Also, in MFC, there were a lot of #ifdef _MAC which handled the endianness
of the 68K and PPC architectures, before Microsoft abandoned MFC support on
the Mac (interesting point: perhaps that decision should be reconsidered now
that the Mac is x86-based)
joe
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Saturday, January 10, 2009 12:50 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] conveting into little endian
Do you think it will be a safe assumption that windows will never run on
a big-endian architecture?
Well, in order to make it run on big-endian machine compiler support is
needed, don’t you think???
Therefore, if they decide to re-introduce support for non-Intel
architectures, they will have to provide a new development environment -
after all, contemporary WDK does not support anything, apart from
x86,x86_64 and IA64.
It has not always worked this way - if you look at old UM header files you
will notice quite interesting declarations (for example, of CONTEXT
structure) that indicate support of a wide range of platforms…
Anton Bassov
NTDEV is sponsored by OSR
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
–
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.
Joe,
Similarly, sending binary data in a network packet has the same problem; I send a byte-count
as part of the header for my “data packet” (that is, the protocol I implement above the IP level).
I encode it in big-endian byte order. Different apps will have to either swap it or not
(but in user space, ntohl handles this). This is not a binary-code-compatibility
issue, but a binary-data-compatibility issue.
This is exactly the reason why I say “it seems to be the question of compiler/preprocessor, i.e. of macro definitions in headers that come with the build environment”. In your example, htons() and friends will have different declarations for big-endian and little-endian machines, and these declarations will be in #ifdef block. Surely some apps that don’t care about the endianness issues may ignore these macros, and, hence, be unportable across different architectures, but this is already app’s problem, don’t you think. After all, if app designer has decided that his app should not be portable across different platforms, how on Earth may it be related to the OS , build environment, file formats,etc???
Anton Bassov
Part of the reason why Windows is so successful is the enormous spread of apps (well-written or otherwise) that work on the platform.
Many of these are so entrenched in little-endian that it becomes a large porting deterrant.
? S
-----Original Message-----
From: xxxxx@hotmail.com
Sent: Saturday, January 10, 2009 09:31
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] conveting into little endian
Joe,
> Similarly, sending binary data in a network packet has the same problem; I send a byte-count
> as part of the header for my “data packet” (that is, the protocol I implement above the IP level).
> I encode it in big-endian byte order. Different apps will have to either swap it or not
> (but in user space, ntohl handles this). This is not a binary-code-compatibility
> issue, but a binary-data-compatibility issue.
This is exactly the reason why I say “it seems to be the question of compiler/preprocessor, i.e. of macro definitions in headers that come with the build environment”. In your example, htons() and friends will have different declarations for big-endian and little-endian machines, and these declarations will be in #ifdef block. Surely some apps that don’t care about the endianness issues may ignore these macros, and, hence, be unportable across different architectures, but this is already app’s problem, don’t you think. After all, if app designer has decided that his app should not be portable across different platforms, how on Earth may it be related to the OS , build environment, file formats,etc???
Anton Bassov
—
NTDEV is sponsored by OSR
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’ve ported a number of applications to/from Windows, and in only one of
them was there an endian-dependency, in one line of code (it did cause the
program to fail spectacularly, and was therefore easy to find and fix…in
fact, it was fixed by *removing* the endian-dependency, since there was
apparently no valid reason for it to have existed except a “clever”
programmer who decided that he could play a trick that was “more efficient”
and was “smaller code”. It saved two assembly-code instructions in what was
about 100K SLOC, and was executed once every few minutes, but this was in
comparison to writing the obvious C-language endian-neutral code. My
estimate was that by being “clever”, he would regain the cost of a single
compilation in about six years of running the program 24/7).
joe
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Saturday, January 10, 2009 12:39 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] conveting into little endian
Part of the reason why Windows is so successful is the enormous spread of
apps (well-written or otherwise) that work on the platform.
Many of these are so entrenched in little-endian that it becomes a large
porting deterrant.
- S
-----Original Message-----
From: xxxxx@hotmail.com
Sent: Saturday, January 10, 2009 09:31
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] conveting into little endian
Joe,
> Similarly, sending binary data in a network packet has the same
> problem; I send a byte-count as part of the header for my “data packet”
(that is, the protocol I implement above the IP level).
> I encode it in big-endian byte order. Different apps will have to
> either swap it or not (but in user space, ntohl handles this). This is
> not a binary-code-compatibility issue, but a binary-data-compatibility
issue.
This is exactly the reason why I say “it seems to be the question of
compiler/preprocessor, i.e. of macro definitions in headers that come with
the build environment”. In your example, htons() and friends will have
different declarations for big-endian and little-endian machines, and these
declarations will be in #ifdef block. Surely some apps that don’t care about
the endianness issues may ignore these macros, and, hence, be unportable
across different architectures, but this is already app’s problem, don’t you
think. After all, if app designer has decided that his app should not be
portable across different platforms, how on Earth may it be related to the
OS , build environment, file formats,etc???
Anton Bassov
—
NTDEV is sponsored by OSR
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
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
–
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.