Fog Creek Software
Discussion Board

Microsoft Backwards Compatibility Religion not

Maybe I missed it but Joel seems to claim Microsoft lost their backwards compatibility religion.  His proof is all the new APIs that come out that ignore old APIs (like Windows Forms)

But that's a flawed example.  MS hasn't dropped backward compatibility at all.  Did someone say DOS programs or Win32 API programs will stop running on Longhorn?  No!  All that is happening is Longhorn programs won't run on XP.  Same has Win95 programs didn't run on Win 3.1 and Win3.1 programs didn't run on DOS.

New APIs don't break old stuff if the old stuff doesn't disappear, New APIs just provide new features the old APIs didn't.  This has always been the case, nothing new here, no reason to think the sky is falling.

This is not like Mac and OS-X which basically didn't run lots of OS 9 programs.  It's going to be more like 3.1 -> 95.  All the old programs will run, they'll run fine in fact, but new programs will do new cool things.  Pretty straight forward no?

Gregg Tavares
Friday, June 25, 2004

Not really no.

Currently we write applications for the workstations and O/S's that are out there.  We can write, develop and distribute applications for 9x, 2k and XP (and NT if really needed), without thinking too much about it.  Yes there are anomalies but for the most part its manageable.

If we write applications targetted at Longhorn and using Avalon then they will not run on current platforms.

If we take no notice of Longhorn and carry on regardless, those applications may run, or they may not on this future operating system.  Before going anywhere near it we're going to have to be more than just sure whatever API mechanism exists that it will run on all those platforms.

The take up of new operating systems is getting proportionately slower, we are stuck with 9x machines existing (there are still many users using DOS applications at the core of their business, they still work), for the forseeable future.  We will have 2K and XP for at least the next ten years.

For, as the man says, software does not rust.

At the moment there is zero incentive for me to develop in anything like .NET or its descendants.  If I were to make the change I'd want that change to be completely cross platform and that means I'm likely to still make my choice from XUL/Gecko, wxWindows, Swing and possibly Mono but only if I can see openness between the MS Frameworks and Mono's Frameworks.

Simon Lucy
Friday, June 25, 2004

Backwards compatability is not just about running old code.  It is also about allowing new code to age gracefully.

For an application created in VB1 for Windows 3.1 there has been a steady upgrade path.  There has been some work to upgrade from one version of VB to the next, but nothing like a rewrite was every required.  In most cases new features were made available, but the old stuff still worked.

Now that path is broken.  Developers are faced with a choice if they begin to write a new app.  The can write it in VB and take advantage of there experience and the huge installed base.  However, VB is not going to be upgraded.  No new features will be added.  In a few years time that VB code will look ancient and upgrading it to look smart be hard.  Eventually you will have to rewrite that app in .Net.

On the other hand, you can go with .Net now, but then you're application has to wait for the framework to become generally available.

Microsoft have never made developers face this type of choice before and it is frustrating.  To make it even worse, the even refuse to lighten the load a little by providing a linker. 

Ged Byrne
Friday, June 25, 2004

If converting VB to is enough of a problem then someone will solve it with a compiler to automate the conversion.  Sounds like a market opportunity.

Friday, June 25, 2004

"Sounds like a market opportunity. "

Yes, actually I've wondered what would happen if someone came up with  VB 7.  Something very close to the syntax of VB 6 (for zero learning curve).

I think it may be hard to have an app migrate easily because VB 6 had some wierd fieatures to give it "object oriented-like features".

However, even just giving it a zero learning curve would be great.

Imagine the power of Delphi and the ease of VB.

I'd pay $2k for that IN A SECOND.

Mr. Analogy
Friday, June 25, 2004

The important backward compatability that MS lost is VB.  VB.Net simply cannot read in a VB6 project unless you run it through the .net-ifier tool first.  There are a blue ton of VB6 projects just sitting there, and MS certainly could have written a VB6 runtime and parser/compiler that targeted .Net.  The CLR can handle a really wide range of languages (there's a demo lisp machine in the SDK, for Pete's sake, pretty dang far from Java/C#/C++/VB.Net), so the back end shouldn't be the issue - it can be done.

I think the real issue is trying to cram the VB6 language into the CodeDOM for nifty code generation features.  I believe that VB.Net fits much more neatly into CodeDOM than VB6 would.  I could be wrong on that.

Anyway, it would be really nice if people could incrementally improve existing VB6 projects in .Net beginning with a simple recompile.  Open the old project, rebuild it, and bang, a .Net app.  No conversion of code, no errors (except those that already showed up in VB6, of course), no thinking required.  Sure, the project wouldn't be taking full advantage of all the neat new .Net features, but so what?  It would *work*.  Then gradually add new components, refactor over time, and eventually you have all the old stuff replaced by the new.  Right now it's pretty much an all-or-nothing scenario.

Aaron F Stanton
Friday, June 25, 2004

You reasoning seems to have 2 flaws.

First, you remark that "[...] Win3.1 programs didn't run on DOS", which is misleading.  Early Windows programs, like Excel, *did* run on DOS -- or rather, they ran on a Windows runtime that was shipped with the application.  As Joel points out, this is one of the obstacles to adoption that Microsoft had to overcome to get people to use Excel.  (I'm not sure this changes the conclusion, but it's a glaring error, to me.)

Second, you say Mac OS X didn't (past tense?) run a lot of Mac OS 9 programs.  I was a full-time Mac user during the OS 9 -> OS X transition, and I had zero applications that didn't work under Classic (OS X's OS 9 emulation layer).  A lot of people cried "the sky is falling!", but I never figured out why.  I still can't name a single application that works under Mac OS 9 but doesn't work under Mac OS X.  (Can you?)

I have a bunch of Windows NT 4 compatibility horror stories, though, if you're interested.  :-)

happy Mac
Saturday, June 26, 2004

*  Recent Topics

*  Fog Creek Home