I have been warned that come mid-year, I’ll be trading in my office with a view for returning to an open-plan experience in the newly constructed Sir Samuel Griffith Building up here on the Nathan campus. Beloved view, I love you!
As you might understand, I’m a little mixed about returning to an open-plan experience. It really isn’t conducive to going and staying deep in the flow, and you’d think that after research on what facilitates flow, maybe peeps would get the message that open-plan layouts actively work against certain kinds of productivity. Then again, I was raised on the open-plan experience, and this being my first “own office” experience, there’s not much shock expected.
I’ve heard that the open-plan nature of the building falls out in the wash whilst maximising amount of natural light coming into the building, reducing its carbom footprint. So, what we’ve got here peeps, is an attempt to find a sweet-spot between an environmentally sustainable building played off against maximising people’s output. I guess only time will tell on how well these researchers can maintain their flow in the new environment. Still, I feel for those researchers, entering the world of prarie-dogging for the first time.
So, in preparation for a move to the new building, our IT team has just returned my laptop. Gone the 32-bit Windows XP operating system. Hello to a 64 bit Windows 7 upgrade. The 64-bit thing was a surprise. The consequent breakage of my development environment was not. Though, now I’ve had some time to investigate it, I’m now able to describe the particular nature of my non-surprise.
It seems that we have a 32-bit install of Microsoft Office on our 64-bit machines, thanks to some incompatibilities with other 32-bit software that is in common use on campus. My “Species Benefit Optimiser for the Murrumbidgee Wetlands” relies on Microsoft Excel to import model data through the usage of the ACE Database engine. As Excel is 32-bit, I need the 32-bit ACE library.
Though I can compile my tool to use “Any CPU” as my target platform via Visual Studio, I get this fun little runtime error unless I specify a target platform of “x86”, guaranteeing that the 32-bit ACE driver gets picked up and used for conversations with Excel:
If I DO compile it against a target platform of “x86”, I get this runtime error instead:
Which is in many ways worse, because my most foundational support library is apparently borked, as opposed to just a rogue Microsoft library that with a little more work, could be made optional. Lots of interesting trawling ensued.
Once again, StackExchange delivered the non-nonsense heart of the issue. Ihe VisualStudio debugger is running 64-bit, and has a cow trying to debug a 32-bit application. I tested this out and confirmed it for myself. I can run my application just fine from within VisualStudio so long as it’s not with the debugger.
I’ve considered and rejected a lot of workarouds. The winner is an approach where I coax VisualStudio to run its debugger as a 32-bit application. They tell me I need to run a command from the VisualStudio command prompt in administrator mode. Here’s a picture of that happening:
They also warn me that the command modifies the debugger executable, meaning we’re taking an all-or-nothing approach to debugging 32-bit applications. As I may want to get back to 64-bit applications, here’s another picture of me keeping both a 32-bit and a 64-bit backup of the exeutable, so I can toggle this hackery later:
And done. The debugger is working again on my 32-bit application, though this degree of hackery last left me shaken, not stirrred.