Blame Visual Studio .Net

64-bit Windows’ incompatibility with much of the Windows Server System traces back to VS .Net

I dreamed that Microsoft put me in charge of development for its 64-bit enterprise server applications, the Exchange and SQL Server, and so on, all of which travel collectively as Windows Server System. I was asked to find out why some elements of WSS won’t run on 64-bit Windows, even though Opteron and 64-bit Xeon run 32-bit apps unmodified. “That doesn’t make sense,” I said to myself as I sized up my expansive corner office.

I awoke feeling uneasy and got back to watering the plants in Steve Jobs’ Thursday Afternoon Auxiliary Office. Water is truly relaxing and an aid to focus — and damned if that dream didn’t start making sense.

At the time of its debut, VS .Net (Visual Studio .Net) was dubbed the dev tool. Microsoft made its case for wide adoption by showing how well received VS .Net was in-house. VS .Net was supposed to usher in a new era of responsible programming. For a time, Microsoft bought into the Sun-inspired portrayal of C++ programmers as gaggles of thrill-seeking toddlers running customers’ sites with nail guns.

Sun met the challenge with a constrained run time and a language, Java, that was much easier to use than C++ and could be used in anything from a telephone to a mainframe.

Microsoft perceived a similar threat from native coders, but it chose a different approach: behavior modification. Visual Studio .Net didn’t like interleaving server-side scripting code with HTML in one file, so it didn’t permit it.

VS .Net had a C++ compiler, but if you failed to use the wretched, managed (.Net) extensions, it tagged your code “unsafe.” It removed editing and debugging capabilities for JavaScript, even though it was still a supported language. I imagine the Microsoft proponents of these tools saying, “They’ll thank us for it later.”

Microsoft’s developers, however, did not thank their employer. What they did — and I have no idea how this got started — was push back. I won’t say that nothing got done while VS .Net was fouling the Redmond air: Work on projects migrating to managed code had no reason to slow down. But VS .Net handed C++ a brutal gutting with the clear intent of forcing developers into C#.

I don’t know whether Microsoft pressured its own C++ developers into using C#. I do know that the Whidbey project — Visual Studio 2005 — was born of the demands of Microsoft’s internal developers, most of whom code in C++. I’ll never forget the longtime Microsoft developer who, presenting the new C++ at a Whidbey reviewer’s workshop, pounded excitedly on the table and exclaimed, “They gave us our C++ back!”

There is so much that didn’t happen while Visual Studio .Net ruled the roost, that I fully expect a renaissance of Windows development for 32-bit and 64-bit applications, inside and outside Microsoft. It’ll start with the appearance — soon, I’m told — of Virtual Server for 64-bit machines, a move that will allow the complete WSS application stack to run in one or many 32-bit virtual machines. That’s a good intermediate step, but I’d like to see licensing that acknowledges the necessity of Virtual Server’s use. But at least Microsoft’s developers now have the tools they need to move forward.

From CIO: 8 Free Online Courses to Grow Your Tech Skills
Join the discussion
Be the first to comment on this article. Our Commenting Policies