A long tale that is vaguely related to video games and recent news that has been sitting half finished in my drafts folder for over 18 months.
What were you doing in 1997?
One of the tasks I had at work during that year was “WinLogo certification” for our software. That was the term used at the time for going through the process of getting Microsoft to declare you compatible with their operating system.
Anybody could, of course, claim that they were Windows 95 compatible. But to get the official Microsoft Windows compatible logo on your software, Microsoft had to affirm that your software was indeed up to spec.
I think it says something that in searching for that logo the best one I could come up with was in .gif format… is there anything in that format these days that isn’t also animated? I feel cheated that the logo isn’t moving. Also, I feel old.
I was installing Windows 95, which was the style at the time
Moving on.
For logo you had to go through a Microsoft approved testing lab. The closest one to us was down in Los Angeles because the Microsoft position has nearly always been, “Screw Silicon Valley.”
Getting that logo on our product was my job for a couple months, and it was kind of a big deal for the company. We made most of our money through OEM agreements with computer manufacturers like HP, Dell, Compaq, Micron and a few other, and for them to keep their Windows logo (and be able to sell the Windows OS) they had to make sure that all of the crap shovelware fine software they included on your new computer was also Win logo certified. So that was dropped in my lap, which was kind of odd. I was the new guy, so I understood getting the crap assignment. But given how much of our income was riding on it, I am not sure that “stick it to the new guy” was the optimum strategy for success.
In the end I did succeed, so I guess their trust was well founded. And I actually enjoyed the whole thing in a perverse way sort of way. It involved a lot of minutia and making sure everything was “just so.” And while I have forgotten most of the arcana involved with the process over the years… I moved to enterprise level software on Windows shortly thereafter, and enterprise doesn’t really care about that sort of thing, then eventually to Linux based enterprise level software, which double-double doesn’t care about that stuff… two things stand out in my mind fourteen years later.
First, I had to fly down to LAX, rent a car, and drive out to the certifying lab because could not figure out how to run our installer. And, seriously, it wasn’t hard. It was in freaking InstallShield. And we had sent them a computer all setup with the right hardware. All they had to do was put the CD-ROM in the drive. I don’t know how they managed to mess that up.
Anyway, I had to travel about a thousand miles round trip in a day to pretty much press “Next,” “Next,” “Next,” and “OK.” Not the biggest travel fiasco I ever had… there was that one trip down to New Mexico with another company to figure out why we were having so many hardware defects only to find out that the guy soldering on the power connector was Red/Green colorblind… but it certainly wasn’t the most efficient method. And it worked, so blunt force method for the win I guess.
Second was the 32-bit requirement for the certification. In order to get that Win logo approval, your application had to be 32-bit. No 16-bit executables or DLLs or whatever were allowed.
Which seemed kind of silly at the time, since Windows 95 would run 16-bit software just fine. There was a ton of 16-bit software laying around, left over from the Windows 3.1 days. Hell, Microsoft was installing some 16-bit code with the Windows 95 operating system. And it shouldn’t have been an issue because our software was all 32-bit already.
Unfortunately, the version of InstallShield we were using was not.
Here is how the software check worked. The lab would run a program that would scan and catalog everything on the hard drive. Then you would run your installer. After that, they would run their scan again, it would identify all changes to the system and list out all of the components installed. They gave you the software so you could run it yourself in preparation for the certification. I ran it many times.
And every time I ran it, it came back with several items highlighted in red because they contained 16-bit code.
I was quickly able to identify the offending DLLs as being part of InstallShield. And, since there was a process for getting an exemption for 16-bit code under certain circumstances, it was deemed a better use of the company’s time to have me get the exemption than to upgrade our version of InstallShield. Given the number of hoops we had to jump through in order to get through each computer manufacturer’s OEM process and that the installer had to support both Windows NT 4.0 and Windows 95, both of which included a number of special OEM requirements, and had to do so in seven languages (I could install Windows NT 4.0 in Japanese without a hitch… eventually) I could see the point.
Of course, that didn’t make the exception process any easier. One of the rules of any sort of exception procedure seems to be to say “No” to any first request on the theory that it will weed out those looking for an easy exit and then only those with a real need will move forward. So on we went with that process, with Microsoft making it extremely frustrating to complete, with them responding with rejections that seemed to indicate that they had not bothered to actually read our submission. As I recall, one of the acceptable reasons for an exception was third party DLLs that were not used during run time. We would point out that it was just the uninstall that had a couple of 16-bit DLLs and that our software was all 32-bit.
This was made all the more frustrating by the fact that Windows 95, by necessity, had to run 16-bit software. There was a huge library of software available and Microsoft was not at all keen to piss off its installed base… and maybe save IBM from itself on the OS/2 front along the way… by turning its back on that foundation. So it wasn’t as though we were shipping something that didn’t work. Our software did not even violate the rules, it was just the installer… an installer that almost no customer would ever use because our software came pre-installed.
Eventually we hit some sort of persistence threshold and were granted our logo certification. By that point I had moved on to another company, but I was friends with the person who took over for me so got to hear the ongoing tale of getting Microsoft to grant us our exemption.
And then, for at least the next decade, actually being a 32-bit application was not all that meaningful. I went on playing the original, 16-bit version of Civilization II for a long time on Windows 95, Windows 98, Windows 2000 Professional, and then on Windows XP. 16 bit applications were supported, and remain so, on Microsoft’s 32-bit operating systems… at least to the extent that they support anything. A lot of apps have been broken by changes and updates over the years, 16 and 32-bit alike.
16-bit apps didn’t lose support until Microsoft got to 64-bit operating systems. But almost nobody went there initially. It wasn’t even practical until Windows Vista… which had its own serious problems and which was effectively rejected by the marketplace… and didn’t really start becoming a popular choice until Windows 7 came along about five years back.
By which time the market had probably weaned itself off of 16-bit applications. Even I had to finally give up the 16-bit version of Civilization II and go with the 32-bit version, the Civilization II Gold Edition, that could at least be patched to work with Windows 7 64-bit.
That is basically the inertia of the market. Getting millions of people to upgrade both their computer and get onto a 64-bit operating system took a while, and the groundwork for that started way back with Windows 95 and the push to get developers onto 32-bit apps. What I was doing in 1997 was part of the many steps to get to the point where companies could make these sorts of system requirement announcements:
It is almost a requirement to have a 64-bit client to play in the big leagues these day. The bleeding edge gamers all have 64-bit systems and lots of memory and get kind of antsy if you don’t support their hardware to its fullest extent.
But it was a bit of a surprise to find somebody actually dropping support for their 32-bit client. Daybreak just announced that 32-bit support is on its way out for PlanetSide 2.
We wanted to let you know that with the next Game Update (tentatively scheduled for next week), PlanetSide 2 will no longer support the use of the 32-bit Operating System client. We do note, based on our internal metrics, that a very small group of folks are still using this client. We hope this doesn’t prove too inconvenient to anyone impacted, and we appreciate your understanding.
That is actually a big step and I would be interested to know how big “a very small group of folks” really is. And I wonder if we’ll hear anything else like that at E3 this week. (Topical!)
I suppose by the time most mainstream software finally becomes 64-bit only we’ll be about ready for 128-bit operating systems.
The Ancient Gaming Noob 