64-bit Driver Development

Posted August 31, 2004

Chat Date: August 26, 2004

Please note: Portions of this transcript have been edited for clarity

Introduction

Moderator: Eric_S (Microsoft)
Welcome to today's Chat. Our topic is 64-bit Driver Development. Questions, comments, and suggestions are welcome.

Moderator: Eric_S (Microsoft)
Let's introduce our hosts for today!

Host: Mark (Microsoft)
My name is Mark Kieffer. I am a Group Program Manager in the Windows division responsible for 64-bit Kernel work.

Host: forrest (Microsoft)
Forrest Foltz, Windows NT Base Architect, mainly finishing up the AMD64 port right now.

Host: Nar (Microsoft)
My name is Nar Ganapathy. I am development manager for the Windows Driver Foundation team working on frameworks for our driver models. My expertise is in driver model and I/O architecture for Windows.

Moderator: Eric_S (Microsoft)
Welcome everyone, let's get started!

Start of Chat

Moderator: Eric_S (Microsoft)
Q: Why AVSHwS sample doesn't support 64bit?
A: Our understanding is that this is an audio driver sample, correct? Unfortunately we don't have anyone here with expertise in that specific area, if you can post your question in the driver newsgroup at microsoft.public.devlopment.device.drivers we will see if we can get someone to respond to your question.

Host: Mark (Microsoft)
Q: Will PREfast support x64 anytime soon?
A: Currently the tools that support 64-bit development are at various stages of development. The Prefast tool is a key tool for us and will be ported to 64-bit in the near future. Unfortunately I don't have exact dates when it will be ready.

Host: forrest (Microsoft)
Q: Are there any differences between a 64-bit driver and a driver for the 64-bit extended memory system?
A: Not at the source code level. Physical memory addresses are 64-bits in both environments, while virtual addresses are of course 32 bits for 32-bit x86 environment, including PAE-enabled systems. So a correctly written 32-bit driver will already function correctly in a PAE environment.

Host: Mark (Microsoft)
Q: Are there any good resources to look at for AMD 64 development?
A: I'm not sure what types of searches you did, (MSN Search, MSDN, or others) however there is starting to be more and more data on MSDN and of course the AMD web site has significant information also.

Host: forrest (Microsoft)
Q: Forrest indicated he is finishing up the AMD64 port right now. Does that include the EM64T processors?
A: Yes, absolutely. Both vendor's implementation will be fully supported. We've used "AMD64" for a long time in dev, but our official, vendor-agnostic name is of course x64.

Host: forrest (Microsoft)
Q: It is my understanding the Windows XP 64-bit Edition has an 8KB pages size. Is that correct and do the AMD64/EM64T have same pages size?
A: On IA64, Windows uses an 8K page size. The x64 architecture supports only 4K page sizes (and 2MB large pages, of course). Pages and the page table layout on x64 are very closely related to the PTE format.

Host: Mark (Microsoft)
Q: Correct me if I'm wrong. WinXP 64bit is v5.1 and Win2003 is v5.2? When I develop driver for WinXP 64bit, can I use those API that's new to Win2003?
A: Are you speaking of WinXP 64-bit for Itanium based machines?

Host: Mark (Microsoft)
Q: no, WinXP x64. Is there WinXP IA64?
A: There is a version of WinXP IA-64 that was released concurrent with the 32-bit versions. The answer to your question is yes, you should be able to use the new API's.

Moderator: Eric_S (Microsoft)
Q: I would like to know the differences among cabarc.exe for 32 bit and x64 bit. Is there any tool using which one can make the cab file for all 32 bit and x64bit platforms?
A: Unfortunately we don't have any setup experts with us today... we recommend posting in the driver newsgroup at microsoft.public.development.device.drivers

Host: Mark (Microsoft)
Q: This is a follow up to my other question -- most of the info on the AMD site that I found is from October 2003 -- that's almost a year old. Was just wondering if there was a good place on msdn that you know is current.
A: The MSDN articles would vary, however most of the are fairly recent. The AMD site data may not be stale since they are still pretty much on the first version of the processor so data contained there would be current still. October was the original release date of the processor so that would be when AMD went public with documentation also.

Host: forrest (Microsoft)
Q: winnt.h header file in SDK 3790.117 has a new pragma preprocessor definition (#define pragma intrinsic __segment limit) which we didn’t find in previous SDK winnt.h file. When we try to build our program with this entry it gives compilation issue.
A: It sounds like you are somehow using an older version of the compiler with the current header files. That intrinsic is a relatively recent addition.

Host: forrest (Microsoft)
Q: 32-bit Windows system automatically fixes kernel-mode memory alignment faults and 64-bit does not according to DDK. Can you provide more info or link that explains this further?
A: x86 kernel-mode code does not generate alignment faults for kernel- or user-mode code.

Host: forrest (Microsoft)
64-bit code on x64 has the same behavior.

Host: forrest (Microsoft)
64-bit code on IA64 does generate alignment faults by default for user-mode code, although this can be changed by the app (not recommended). Kernel-mode code always generates an alignment fault on IA64.

Host: forrest (Microsoft)
Q: What is the #pragma to force 64-bit alignment? Can it only be used once, or multiple times within a structure definition?
A: You can use pack() pragma to change the "ambient" alignment. The sdk/ddk build environment by default uses pack(8). Also, you can use __declspec(align()) (a.k.a. DECLSPEC_ALIGN() in the sdk/ddk) to specify alignment for a specific structure.

Host: forrest (Microsoft)
The pragma applies to a structure in its entirety.

Host: forrest (Microsoft)
A: That musical note was intended to be left paren, 8, right paren

Host: Mark (Microsoft)
Q: Does setupiteratecabinet() differently in case of 64 bit and 32 bit..?? I am facing some problem while extracting a file from a cab file in 64 bit but same API works fine in case of 32 bit. If there is any difference then can you pleas API behaves differ
A: I don't know of any issues with this API however if there is a problem with it on 64-bit there are two things you can do. First check in with the microsoft.public.platformsdk.msi newsgroup and if you are in the beta for WS03SP1 then please file a bug through the normal beta channels.

Host: forrest (Microsoft)
Q: So, if I want all the items (that are less than 64-bits wide) to be 64-bit aligned, I have to add padding manually?
A: Two adjacent ULONGs in a 64-bit aligned structure will be adjacent. pack(8) means that everything with natural alignment up to and including 8 bytes will be naturally aligned, not (necessarily) 8-byte aligned.

Host: forrest (Microsoft)
If you have specific data types that you want aligned, consider something like this:

Host: forrest (Microsoft)
typedef DECLSPEC_ALIGN(16) ULONG ULONG_A16;

typedef struct {

ULONG_A16 a;

ULONG_A16 b;

} TEST;

Host: forrest (Microsoft)
This means that TEST.a, TEST.b and (therefore) TEST all have 16-byte alignment.

Moderator: Eric_S (Microsoft)
Q: Hi, Anybody knows any such online chat room for general driver discussions
A: We don't have a 24x7 chatroom available that's specific to device drivers, but stay tuned and I will give out a link to the driver development newsgroup. In addition, you might want to joking the OSR mail lists on driver development, see https://www.osr.com. There is a lot of good activity on that list.

Host: forrest (Microsoft)
Q: When will the compiler be fixed to provide enough information (local variables, etc.) for debugging AMD64?
A: Current compilers are emitting the information, it's more a question of the debugger's capability. KD will show local variables today with the DV command. Unfortunately, the efficiency of the calling standard often causes (for example) function parms to be discarded, and therefore unrecoverable by the debugger. Sometimes it takes some detective work back up the stack to determine what was passed in.

Host: forrest (Microsoft)
The tools folks are working to improve the situation but there will always be cases where some data is unrecoverable. If nothing else, they will endeavor to display "????" or something in lieu of a garbage, seemingly legit value.

Host: forrest (Microsoft)
Compiling with optimization disabled helps. Just adding the compiler switch "-d2home" (and leaving other optimizations enabled) will force the first four input parms to be stored on the stack for later recovery.

Moderator: Eric_S (Microsoft)
Thanks for joining us today and thanks for the questions. It's time for us to go now. If we couldn't get to your question, please post it in the driver newsgroup at:

Moderator: Eric_S (Microsoft)
Please see the chats schedule for upcoming topics at https://msdn.microsoft.com/chats.

Host: forrest (Microsoft)
Thanks, folks...

Host: Mark (Microsoft)
Thanx for joining us. Chat with you soon. Mark

For further information on this topic please visit the following:

Newsgroups: microsoft.public.development.device.drivers

Embedded Transcripts: Read the archive

Website: Visit the Windows Hardware Developer Central (WHDC) site

Top of page