I’ve finished porting my debugging tools support libraries to x64 now and thought it was worth putting up a summary of the issues that I’ve noticed:
A 32bit exe can’t start a 64bit exe for debugging - pretty obvious really.
When a 64bit debugger is running a 32bit debugee the debugger seems to get TWO “loader breakpoints” one when the 64bit dlls are loaded and a second when the 32bit dlls have been loaded.
The x64 version of our I/O completion port based, networking client and server framework, The Server Framework, is now shipping. This is the licensed version of the free server framework that’s available here. An overview of the licensed version can be found here. The changes from that version to the latest version can be found here.
The documentation for this version is available online, here. Please be patient, the docs are a work in progress and I know they could be better.
It seems that I’ve located the “issues” in my Debug Tools library. This library is used in my TickShifter (time control) tool and my native Win32 Deadlock Detection tool. Due to how I wanted to control the debugged processes start up and how I needed to halt the debugged process at a particular time there were some hoops that I found I had to jump through. Those hoops have changed shape; either because of differences between Vista and XP or due to x64 and the WOW64 layer, I’m not sure which yet.
I should be finishing some docs for the x64 release of The Server Framework… But this is more interesting…
When running my Win32 debugging code on x64, this time when compiled natively as x64 code and when debugging an x64 CLR process, I’ve been getting an ‘unexpected’ ExceptionCode in an EXCEPTION_DEBUG_EVENT. The code is 0x4000001f and, after some searching around, it seems that it’s a STATUS_WX86_BREAKPOINT event and I sometimes get these instead of EXCEPTION_BREAKPOINT events…
I spent a little time looking at an x64 port of my debugging tools library at the weekend. Since this requires me to set breakpoints and manipulate process memory and image files and all sorts I expected it to be a little more complex to port than the higher level sockets code and the bulk of my Win32 code. So far things are going reasonably well, but I’ve just come across a strangeness with DebugSetProcessKillOnExit(TRUE) in an x86 debugger that’s running an x86 process on an x64 machine.
Sad but true… The “Typical Programmer” has a piece on Thirteen Patterns of Programmer Inverviews. I think I’ve probably been interviewed in all of these styles over the years and taken part in several of them from the interviewing side of things…
I’m finalising the testing of the x64 version of The Server Framework and, since it’s a fairly major release, I figured that it waranted an email to existing customers to see who wanted to have the update shipped to them straight away (although all existing customer are entitled to all upgrades to The Server Framework free of charge I usually rely on them monitoring this RSS feed and asking for new releases rather than just sending them out; generally only critical bug fixes are worthy of an email notification…).
What with holidays and having my head down doing x64 and CLR hosting stuff for a client it seems that the last month and a half has rushed by…
The good news is that the x64 port is slowly slipping out to clients; the bulk of the work has been done for ages but I’m using this release to bring all of my example servers in line with best practices for using The Server Framework.
Interesting… It seems that rumours of C++’s demise in the brave new world of .Net were slightly over exagerated, perhaps, maybe…
From a recent issue of MSDN magazine:
“There are two main reasons why this column was born. First, despite the phenomenal success of the Microsoft® .NET Framework, there are still plenty of scenarios where it makes more sense to use native C++. Adoption of .NET will continue to grow, but C++ is here to stay.
It’s interesting, no, really, how the more things change the more they stay the same… I’ve been doing COM for a long time. I first discovered COM back at Interlink when I was writing a windows version of a product call CardMaster which did credit card production. The system supported lots of different machines and each of these machines needed different drivers, the drivers were written in C and usually spoke to the machine via a serial port.
