Migrating Your Code to Run Natively on 64-Bit Windows: Insider Tips and Indispensable Tools

Posted November 16, 2004

Chat Date: November 10, 2004

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

Introduction

MSFT_Don (Moderator):
Welcome to today’s chat. Our topic today is "Migrating Your Code to Run Natively on 64-Bit Windows: Insider Tips and Indispensable Tools."

MSFT_Don (Moderator):
We are pleased to welcome our experts for today. I will have them introduce themselves now.

MSFT_kanggatl (Expert):
Hello, my name is Kang Su Gatlin. I'm a Program Manager on the Visual C++ team, where I specialize in code optimization and 64bit fun stuff.

Kevin Frei MSFT (Expert):
Hello, I'm Kevin Frei. I'm a primary developer on the x64 code generator, and have been involved with the x64 platform from day one. I also have the distinct honor of being the in-house exception handling guru.

MSFT_Don (Moderator):
And I'm your moderator, Don Spencer. I'm an editor for the Windows Platform SDK.

MSFT_Don (Moderator):
Questions are welcome now.

Start of Chat

MSFT_kanggatl (Expert):
Q: may I ask a question related to outlook
A: Shoot, although we don't know for sure if we can answer it. But we'll try. :D

Kevin Frei MSFT (Expert):
WinDBG is the most indispensable tool. VS Whidbey works pretty well, too. A good debugger is a great start.

Kevin Frei MSFT (Expert):
AMD64 & EM64T are close enough to identical to be considered the same thing. If you want a brief explanation, check out my blog: https://blogs.msdn.com/FreiK

Kevin Frei MSFT (Expert):
Q: Any special configuration gotcha's when configuring Whidbey for AMD64 or EM64T platforms?
A: Nothing to special - just be sure that when you create your x64 project that you tell it to inherit settings from your x86 one, otherwise most of your compiler settings will be blank.

MSFT_kanggatl (Expert):
Hi Nanoock. It's pretty straightforward to convert an application to a 64bit application. Go to the Configuration Manager, and then from there go to the Platform selection, and pick x64 or Itanium. Remember to also copy settings from Win32. Let me get a pointer to our web talk. We walk through it there.

Kevin Frei MSFT (Expert):
Q: this is annoying to have to keep selecting Submit a Question - does WinDBG work on both AMD and Intel
A: WinDBG works fine or x86, x64, and IA64 - cool, huh? VS Debugger works for all three as well.

MSFT_kanggatl (Expert):
Q: Can I build the device driver right from Whidbey?
A: Yes, you can build the device driver from Whidbey, although the DDK has additional tools. Remember all kernel mode device drivers run on Win64 must be 64bit driver. There is NO WoW subsystem for kernel mode drivers.

MSFT_Don (Moderator):
A reminder--you can view the 64-bit Webcast series from last week here: https://www.microsoft.com/en-us/default.aspx. Kang Su presented on Migrating native code, and migrating on native frameworks

MSFT_kanggatl (Expert):
How many here already are running Win64?

MSFT_kanggatl (Expert):
Good job Bob!

Kevin Frei MSFT (Expert):
Q: Several of the webcasts mentioned that it is desirable to reorder the members of a class or struct to get better packing or to make it more likely that members that are often accessed together are included on the same code line.
A: This is _very_ important. In the compiler, we had a structure used for sparse bit vectors that had an int, a pointer, and another int. We rearranged that one structure to be int, int, pointer instead, and we saw a 10% perf improvement.

Kevin Frei MSFT (Expert):
Q: Does the Microsoft compiler team have any plans to provide attributes or some other mechanism to specify what offset to place members without having to reorder them?
A: Not right now. This would be great, but it's A) a lot of work, and B) pretty 'non-compliant'. At the same time, though, I'm working on a 'power tool' to report the amount of wasted space in your structures.

MSFT_kanggatl (Expert):
Q: What kind of program/device drivers will need to be modified for xp64? Is there a chance for a device driver designed for xp32 to work on a xp64 ?
A: In terms of "design" there are no major rearchitecting necessary, but you will have to deal with a lot of new details related to bitness. The other issue related to implementation is that the ABI has changed from x86 to x64. The Software Calling Convention Doc which details this is in the DDK.

Kevin Frei MSFT (Expert):
Q: Would it also be 'non-compliant' for the compiler to automatically order the member to pack them (including packing into the padding of a base class)?
A: That particular optimization is only reasonable for a 'benchmark' compiler. In real code (and a lot of benchmarks, too :-) there is rarely a code base where this is legal. It is valid C/C++ to take the address of a structure, then use that address to get at various members of that structure. Our whole program optimization framework may be able to do this in the future, but there are very few instances where it's possible...

Kevin Frei MSFT (Expert):
Q: does managed code need recompilation, or is everything taken in charge by the framework ?
A: Managed code _may_ require recompilation. Managed C++ code _definitely_ requires recompilation. Verifiable managed code will probably just work. At the same time, though, your managed 32 bit code will work just fine when running under WoW64

MSFT_kanggatl (Expert):
Q: We went to considerable effort to integrate VBA into our application. Can you discuss at all the rationale behind not porting it to 64 bits and what you would recommend as a replacement technology?
A: As you know, while VBA is supported on 32bit, we're moving to a new flexible architecture. There is a roadmap for a new framework called VSTA, with a programming model consistent with the VSTO model (in Beta1).

MSFT_kanggatl (Expert):
Q: Any cluster configs on the SuperComputing 2004 floor running Windows Server 2003 Datacenter 64-bit?
A: I don't see any running Datacenter, but they may be here. I'll look around later though, as I haven't really been looking at specific SKUs. Just know they're running WS03 :-)

MSFT_kanggatl (Expert):
I believe it stands for "Visual Studio TOOLS for Applications". VSTO is Visual Studio Tools for Office. Check out: https://msdn.microsoft.com/en-us/office/default.aspx

MSFT_kanggatl (Expert):
Rob, shot me an email at kanggatl@microsoft, and I'll get you in touch with the person running VSTA. I don't think that the roadmap is public yet. In either case, she'll get you the right info.

Kevin Frei MSFT (Expert):
BTW - On my Blog, I have a set of useful things to know about self-hosting on Win64.

mikehall_ms (Moderator):
we're moving to a new topic in about 10 minutes - Windows XP Embedded SP2

MSFT_kanggatl (Expert):
Q: do every device driver need to be (at least) recompiled to work on a xp64, or might some work correctly ? (I am working in an OEM and my concern is to check the minimum part of my process I will have to change to preload amd64 machines with xp64)
A: Yes, every kernel mode device driver will need to be recompiled to work correctly on xp64.

Kevin Frei MSFT (Expert):
Q: When you say "using portions of the 64 bit pointers to contain extra information", do you mean bits 44-64 that are above the 8 TB range?
A: What I'm thinking is using some range of bits, like bits 40 through 48, as a type. Then you have to use a custom allocator to reserve the entire range of memory, and allocate the structure types from the correct place in memory. If you do a lot of things that check type info of a datastructure, and the type never changes, once it's created, this _could_ help (I think). I'm thinking about prototyping it in the compiler to see. Currently, because we use pointers so much in the compiler, we don't really see any performance win when running the x64 native tools, because the working-set is about 50% larger...

MSFT_kanggatl (Expert):
Q: off topic question, will there be a windows xp home edition 64 bits *-) ?
A: There will not be a home edition for 64bits. Rather a pro-edition. Although I use pro-edition at home myself (H)

Kevin Frei MSFT (Expert):
Q: We did things in the past to utilize the high bit in 32 bit world. We have had to modify that code as 3GB became available. I would be leary that something else would cause those bits to be unavailable in a future 64 bit world.
A: I know - we do have 1 limitation, right now, that I could take advantage of: an .exe or .dll can never be larger than 2 gigabytes, so we'd never need more than 2 billion of our IR nodes, even if we have the entire program in memory. "640K is enough for anyone" right? :-)

Kevin Frei MSFT (Expert):
Q: We did things in the past to utilize the high bit in 32 bit world. We have had to modify that code as 3GB became available. I would be leary that something else would cause those bits to be unavailable in a future 64 bit world.
A: What I'm thinking about doing is actually not ignoring those bits, but just overloading their meaning, so that you can tell, simply by where in memory the pointer resides, what type the pointer is. The structure really does point to that location in memory - that's why I'd use VirtualAlloc to allocate the memory...

MSFT_kanggatl (Expert):
So ask those questions fast! :-)

MSFT_Don (Moderator):
For a schedule of other chats that you might be interested in, go to https://www.microsoft.com/technet/community/chats/default.mspx

Kevin Frei MSFT (Expert):
Read my stupid blog: https://blogs.msdn.com/FreiK/

MSFT_Don (Moderator):
Thanks for your interest and feedback! We are going to leave now.

Top of page