I would say that though not the oldest hand in town by any means, I definitely qualify as an experienced user of Microsoft development tools. Nonetheless, what follows simply documents my history of using them (or not) rather than anything more general, and contains much personal opinion, vagueness and inaccuracy, for which I don’t apologise since I’m not writing for anyone’s benefit but my own.
For the period from 1987 to approximately 1990, where their MSDOS served as the operating system for my development platform, but the actual tools were from elsewhere - mainly cross-assemblers with proprietary hardware links to various 8 and 16-bit CPU based machines. The most notable amongst these were Andy Glaister’s PDS (for Z80 and 6502) and Cross Product’s SNASM (for 68000). Both came with proprietary hardware that turned the target machine into a willing zombie, able to accept complete memory dumps at a moments notice, and be debugged at the hardware level with full control of the CPU. This was the ultimate development environment, the pleasure of which I’ve never had again since.
From 1990 onwards, MSDOS became both the target and the host for development, sadly both on the same machine. An 8086 version of PDS was always promised, but never arrived - this became a running joke to the point that deep within the extended hidden “boss screen” on the PC version of Star Wars we included a cheeky ‘tribute’ by way of a mock-up (the emphasis on the mock) of the source code of said vapourware. Initially, we used a lightweight but good 8086 assembler which I think was called asm86, developed by a one-man band whose name I forget. In the end, this gave way to MASM, the first Microsoft development tool in the story. MASM was a good quality assembler, and very stable, but it quickly lost out in our eyes to Borland’s TASM (Turbo Assembler) which was ahead of the game feature-wise and had a less clunky syntax. So much so, that we were still using TASM until the end of the decade.
Until 1994, our main projects remained 100% assembler using these tools, but from this point onwards they began to incorporate an element of C/C++ which grew over the next 5 years to probably 95% of the total source in a finished project. For the early part, while the target remained MSDOS, Microsoft tools still failed to feature, with our compiler of choice being Watcom C++. Eventually though, the advent of Windows 98 and Direct X warranted an immediate mid-project switch to targetting Windows. At this point, it didn’t take long for us to decide to switch to Microsoft’s C++ compiler. It must have been solid and stable in that role, because I don’t have much to say about it. Then again, since it was invoked from our own build tools and we didn’t use the IDE, all it had to do was compile properly, which it did.
When DirectX was initially announced, I must admit I never believed Microsoft were capable of pulling it off. While we considered ourselves graphics and performance gurus, Microsoft had consistently demonstrated little or no understanding of any of the issues involved. We were streets ahead, and I dreaded what was coming, since good or not it was invevitable that it would come to dominate desktop 3D graphics sooner or later, and for a long time. The profusion of diverse graphics hardware would inevitably reach such proportions that only Microsoft would have the resources to support them all, and the DIY talk-to-the-hardware option, though invariably superior, would become uneconmical. In the end though, I was proved wrong, and by DirectX 5 or 6, it had become a very respectable platform. The sub-optimality always grated in the background, but you just couldn’t argue with the practicalities. In short, I consider DirectX to be one of Microsoft’s finest triumphs, past and present.
Visual C++ 5 and 6 were my first day-to-day-use experience of working within a Microsoft IDE. These were used for GUI-based applications, both front-ends and launchers for lower-level applications, and as stand-alone business applciations. The majority of these used Microsoft’s MFC class library, which was their C++ class library which provided a thin wrapper over the Windows API - thin enough to punch your way through with little effort, which is good because MFC lacked so much functionality that it was never long before you had to do just that. MFC is widely despised, but once you come to accept the countless idiosyncracies and see it for what it is, I actually think it’s always been a better alternative to direct API access, although there are those who strongly disagree - e.g. Reliable Software. Whatever the right and wrongs, I still have a number of live (i.e. actively used and maintained) projects hosted under Visual C++ 6 and MFC.
Part of the Visual Studio 6 platform was Visual J++, Microsoft’s short-lived attempt to achieve some Java lock-in, and though I did various bits of serious Java development during that period, their moribund effort thankfully never featured, and their JVM went the same way. Java is undoubtedly Sun territory, and it’s probably no coincidence that during this period their Solaris became the first non-Microsoft OS to make an appearance, ignoring occasional hobby tinkering with Linux. Pre-Windows 98, if there was an OS at all (and more often than not, there wasn’t, our code started from the beginning of the boot sector) it existed only as something from which control should be wrenched on startup. MSDOS was the in between stage, we kept it alive in a limited sense to provide a filing system only.
In parallel to this, I’ve had considerable experience in the trenches with Visual Basic 6. From a technical standpoint, VB6 is a terrible abomination of a development tool, which was never in any way suited to professional software development. Used well, it was a shaky foundation for any non-trivial project. On a project where it was abused, you could see enough material to supply The Daily WTF with material for a month without even touching the scrollbar. Technical matters aside, what VB6 had in its favour was accessibility to a wider audience, one which included a higher proportion of people you would actually dare to put in front of a customer, and rely upon to get out of bed in the morning - those for whom coding is a necessary evil, not a sacred art form or precision engineering. One thing’s for sure - there’s an awful lot of VB6 code hard at work out there right now performing business-critical functions and providing idiosyncratic home-brewed user interfaces to the desk-bound workers of the world. So in the end, it has to be said that VB6 got the job done, albeit frequently in a Heath Robinson style.
Thankfully, when VB6 gave way to VB.NET, and Visual Studio .NET in generally, it did so rapidly. Despite the name, VB.NET is a far cry from VB, although by way of some bizarre compatibility features (which can and should be ignored) and semi-successful automatic project upgrades, it’s not too difficult to port a project across. In fact, I’ve now come to appreciate it as a valid language for professional development, semantically equivalent to C# (more or less) but with a more verbose and noddy-style syntax. Visual Studio 2002 and 2003 were basically good development platforms with 2003 representing, for me, the peak of the curve that gives this post its title.
In addition to VB.NET and C#, Visual Studio introduces a new flavour of C++, Managed C++, as opposed to the original, which we now refer to as Unmanaged. In a nutshell, we are talking about C++ integrated with the garbage-collected .NET runtime environment. I passionately dislike garbage collection, though always with a resigned realism in mind. The whys and wherefores could easily fill another post, so I’ll cut a long story slightly shorter by not recounting them here.
Version 1 of the .NET framework, I have always thought, is a superbly designed and implemented piece of software, well documented and with a highly functional development environment in VS.NET 2002/2003. It’s not without it’s horrors of course, one highlight being the rotten and ill-considered DateTime implementation, which we are now stuck with - for one aspect of this, see the first question in the BCL Team’s FAQ on the subject. It’s nice, and sometimes necessary, to have this level of access to the inner workings of the development team though, so I hope they don’t read this and take a less open stance in future. Anyway, without going into too much detail, the horrors are the exception, not the rule. I had, and still have, a lot of respect for the .NET framework at that point in time. That last sentence does make sense, if you think about it. Within the IDE though, we start to see the first signs of unpleasantness to come, and various other spectres loom. This is a good place to end part one of this tale. Part two will be downhill all the way…..
