Confessions of a Longhorn User

A Computer Says 'Mooooooo!'

February 2004 - Posts

  • Herding Cattle - Pulling the 16-bit plug

    Filed under: ,

    Note: I thought I’d start a new little gimmick on my blog here - I’ve got a bunch of feature requests that I’d like the developers at Microsoft to take a look at, and I’m sure a lot of the other bloggers and visitors to this site do as well.  I gave up on trying to think of a catchy name for the series, and settled with “Herding the Cattle.”  Apologies to any Microsoft devs who either don’t want to be herded, aren’t cattle, or both.

    This last year, in October, I was lucky enough to be one of the many developers who attended Microsoft’s PDC conference, at which the covers were finally lifted from this little thing called “Longhorn.”  Out of all the cool things that were discussed and displayed at PDC, one thing stood out in my mind, because my initial reaction was “Why?”

    During the keynote, in one of the first demonstrations of Longhorn, the presenter launched an application that I, for one, don’t believe has any place running on a modern PC.  VisiCalc. 

    What’s wrong with VisiCalc?  I have no problems with VisiCalc itself – I appreciate what VisiCalc did for the computer industry.  What I have a problem with is 16-bit code running on a modern computer.   For those of you who haven’t been keeping track, it’s 2004 now.  Windows 95 was released nearly 9 years ago, along with the ability to both run and write 32-bit code.  So why, almost a decade later, are we still concerning ourselves with running 20 year old software?  We shouldn’t be.

    VisiCalc is, of course, just an example.  What I’m really trying to say is that I believe it’s time to start killing off 16-bit support forever, and here’s why:

    • Security, security, security.  Let’s face it – any programs that require 16-bit support to run were not designed with modern security techniques in mind, so the 16-bit programs themselves could pose a security risk.  According to this page, DOS applications each run in their own Virtual DOS Machine, and each VDM has its own address space, whereas Win16 apps share a common VDM.   Assuming that the VDM is a secure environment, this should be enough isolation to protect the OS from any rogue application, or any application that has an exploitable security vulnerability.

      That, however, is a pretty big assumption. 
      This Microsoft Knowledge Base article explains how “thunking” works between 16 and 32-bit code on Windows.  It lists different methods that 16 and 32-bit applications can use to communicate with each other, and RPC happens to be one of them.  If RPC sounds familiar, it’s because the MSBlaster worm, which struck earlier this year, used a vulnerability in RPC to infect PCs on the Internet.

      Now, to my knowledge, no vulnerability has been discovered that exploits any security holes in the 16-bit compatibility subsystems in Windows, so I’ll be the first to admit that claiming 16-bit compatibility is a security risk is unsubstantiated.  I do know, however, that part of designing a secure system is to reduce attackable surface area.  Removing 16-bit compatibility would, indeed, reduce the attackable surface by removing possibly insecure, legacy code from the operating system.

    • Beating a dead horse.   How long can we continue supporting legacy technology?  Ford no longer offers any support for the Model-T, why should we be stuck with making sure that Quicken for DOS 1.0 can still run?  I understand that a lot of small businesses still use 16-bit applications to do their daily business.  The company I work for is fairly large, and even we have a smattering of 16-bit apps in some departments (which will be corrected in a few months, if I have anything to say about it).  Even so, I believe it’s time that the line be drawn.  As I said earlier, Microsoft development tools have been able to produce 32-bit binaries for 9 years – if you’re a software vendor who is still producing 16-bit code, you’re doing your customers (assuming you even have any customers…) an amazing disservice.

    • Obsolete Design Decisions and Shifting Standards of Quality.  If you look at older software and compare it with modern programs, you can see and feel the difference almost immediately.  Once you start to actually use them, you can tell that something’s a miss as well.

      The company I work for has one very specific piece of third-party 16-bit software (actually, the vendor says it’s a 32-bit/16-bit hybrid – what kind of excuse is that?  Part crap is still crap, guys… sorry to break it to you) that is used for market research.  The software’s setup program is a proprietary 16-bit installer that doesn’t recognize long file names.  It also, by default, installs the program to its own folder off of the root of the C drive.  Updates to the market data are installed by different executables, which are an entirely different 16-bit installer which also doesn’t like long file names.

      The look and feel of the program is almost, but not entirely, completely archaic and foreign compared to the current Windows 2000 / Windows XP interface.

      These are some of the things that are being carried forward by supporting legacy software.  In today’s world, nobody in their right mind would install a program on the root of the C drive.  You just don’t do it, what with having to deal with file-system security, and all.  But whenever the code for this program was written, there wasn’t anything wrong with doing so – in fact, people were probably used to having the root of C being the place where everything goes.  I’m not blaming the developers of this application for making that choice (though I’m a little ticked that they haven’t changed it yet…) – there was nothing wrong with the choice when the made it.  It’s the software world that’s changed, and some apps – this one included – needs to be updated to match.

      Long file names are another thing.  LFN support was added back in 1995 – 9 years later this program still adores the xxxxxx~1 naming scheme.   Try describing file name truncation to a user – just try it.  It’s next to impossible, especially if you have a large amount of similarly named files.

      Now, don’t get me wrong – it’s totally possible to write crappy 32-bit programs as well, with either poorly functioning code, or an interface that would make UI designers wretch.  That’s the development team’s fault, and that’s something we’re going to have to live with (or just don’t purchase the software, which I’m beginning to think isn’t a popular enough option…).  But the older a program gets, the further out of the loop it becomes with relation to what the customer/user is used to.

      Minimally, killing 16-bit support would make an application vendor recompile the old code to get 32-bit binaries, and hopefully use newer components (like common dialogs) when doing so.  Hopefully, app vendors would look at the old code and decide that it would be more cost effective to start over with today’s standards and best practices in mind.

    So what about all those applications that will break?  What about all those business critical applications that will break!?!  That’s an excellent question, and I’ve got a couple of ideas.

    Number one: Ask Apple.

    Dana Epp has written an awesome article which talks about breaking backward compatibility in Longhorn (which I agree with!  I think 16-bit is just the tip of the iceberg), and brings up a great point.  When Apple moved to OSX, it included a way for older applications to run in an OS9 environment.  Microsoft could do the same by leveraging it’s newly acquired virtualization technology.  Simply put, Microsoft should add VirtualPC to Longhorn, and allow legacy applications to run only inside of that virtual sandbox.

    Number two: Let the user decide.

    Longhorn could also be designed so that the 16-bit subsystem could be added or removed, similar to IIS, and as such, the user/administrator would have to explicitly opt to install it.  This would keep 16-bit apps running (for now…), while still allowing those of us who have no need to the compatibility code to rid ourselves of it. 

    This is a perfect time for Microsoft to step up as a market leader and start advancing the industry again.  By eliminating the old code, a whole new era of innovation in the software market will be born.  Old code that’s still hobbling along today will have to be rewritten or refactored, and in doing so, it could take advantage of some of the more amazing pieces of technology available today.  Not only would it be a great thing for software developers, but it would be a great thing for software consumers, and I look forward to being both.