7 ms·

Arguably one of the most successful companies in the world is Microsoft. The reasons for their success are many, but at least one is the focus on backwards com

Arguably one of the most successful companies in the world is Microsoft. The reasons for their success are many, but at least one is the focus on backwards compatibility. Hook users, and never give them a reason to leave. As developers we know it is painful to maintain backwards compatibility, but it's incredibly valuable. It builds user confidence in your products, and most importantly it builds user trust that upgrading is safe and thus encourages adoption of newer versions of your software/libraries. The only mistake Microsoft made was not doing rolling releases. Major updates are slow and scary, so even though upgrading to a new version of Windows didn't mean loss of compatibility, it was never "easy" and always jarring. Backwards compatibility, automated testing, rolling releases. That's the magic bullet to keeping everyone happy and on the latest updates. If your users have to think about version numbers, you're doing it wrong. * Yes, there are instances of Microsoft breaking compatibility, more-so post Windows 7. The point is that they tend to focus on it, and they get it right 97% of the time which is a technological feat. See the Rust programming language for a great example of this recipe.

Longhanks 10y ago
And now we're stuck with decades old software and API stacks while Metro/Modern UI/UWP struggles to take off since about 5 years.
- fygdttysf 10y ago
  The day MS depracates WinAPI, they're control of the desktop is over, as every company which develops huge codebases will switch to an environment where their programs doesn't have to be rewritten at MS's discretion.
  - derefr 10y ago
    Is there any platform an enterprise could switch to that would guarantee a slower rate-of-change than Windows? "One major rewrite-requiring breaking change in 20 years" sounds like—if not a good deal—the best one I could foresee getting anywhere.
    - dispose13432 10y ago
      Once you rewrite once, the red line is broken. I think joelonsoftware has an article about that.
    - Someone 10y ago
      IBM (Oracle, too, I would guess). http://www.longpelaexpertise.com.au/ezine/IBMBackwardCompatibility.php http://www.longpelaexpertise.com.au/ezine/IBMBackwardCompati... has a very good observation, though: "The reality is that backward compatibility is only possible if there are enough users paying […] for it." It is the same for Microsoft. If, for example, several big customers would want 16 bit support on x64, I'm sure they would provide it.
  - umanwizard 10y ago
    What platform is that?
  - pjmlp 10y ago
    Sure they will rather change to a platform in the hands of Oracle,Apple or Google.
- paulddraper 10y ago
  > stuck with decades old software "reap the rewards of mature software"
- fl0wenol 10y ago
  The issue is that this is only of concern to application developers who don't want to use old APIs. Systems owners, managers, and users won't care if it gets the job done predictably and cost-effectively. And if the vendor is willing to keep that stack around and support it...
jonathonf 10y ago
> Microsoft breaking compatibility, more-so post Windows 7 IIRC, there have been several instances of this between releases, less so from the user application perspective, but rather from the driver model. Windows 3.1 to Windows 95 (16- to 32-bit), Windows ME to Windows 2000 (NT kernel), Windows XP to Vista (UAC etc.) each saw various issues with device drivers. The extent of user application backwards-compatibility is impressive, with only Windows 10 removing 16-bit application support (boo). For example, even now it's possible to double-click on the application icon at the left-hand of the window title bar to close the application - à la Win 3.1. > The only mistake Microsoft made was not doing rolling releases I think they're 'fixing' that with Windows 10.
- dtech 10y ago
  > The extent of user application backwards-compatibility is impressive, with only Windows 10 removing 16-bit application support (boo) It's still supported on the 32-bit versions of win10! It has never been supported on a 64-bit version of windows though.
  - jonathonf 10y ago
    That raises several questions for my next team meeting...
    - jonathonf 10y ago
      Well, it does. I was told one thing and reality is different. I'm supposed to trust other members of my team rather than fact-check their input.
- wvenable 10y ago
  > Windows 10 removing 16-bit application support (boo). CPU's in 64bit mode don't support running code in 16bit mode -- Windows 10 (actually 7) didn't remove support, it never existed to begin with. This is also why 32bit versions of Windows can and do still run 16bit applications.
ebbv 10y ago
This isn't really true. If Microsoft of 2016 has a focus on backwards compatibility it is only because of their myriad mistakes in the past. I know people have this false impression because of fluff pieces that have been written about Microsoft having a focus on backward compatibility but anyone who has lived through the last 30 years of computing history knows this isn't really true. They have broken backward compatibility numerous times. Many, many DOS programs would not run under Windows 3.1, necessitating users to boot into or exit out into DOS to run those programs, and of course Windows programs could not run under DOS. Windows 95 generally did better at running DOS programs but it was far from flawless. Many programs required all kinds of workarounds and even patches. Windows NT was originally a complete departure from DOS and Windows 3.1, 95, etc. only later on did Microsoft realize that they needed a compatibility layer for NT to ever go mainstream (along with a rebranding.) Windows Vista broke tons of stuff too. Including everybody's printer drivers. When Vista was released you could buy a Vista computer along with a printer which had no drivers for Vista and which HP would tell you there's no Vista drivers ever coming. Windows 8 may not have broken execution of Windows 7 apps but the entire UI was a complete shift from what users were accustomed to. Whether you liked it or not, that kind of major change is a big mistake when so many of your customers are tech novices who are not going to have an easy or enjoyable time learning how to use their computer from scratch. This is just scratching the surface. My point is let's tell the truth here, Microsoft is not some hero of backward compatibility who has never made a mistake and always kept their users at heart.
- filereaper 10y ago
  Not really arguing with your points, but it seems Microsoft has a lot of lessons learnt from maintaining backwards compatibility. It'd be wonderful if their architects collected and codified these somewhere, ie "we did X because of Y, it didn't work, because Z ends up happening" Mostly as a lesson for the rest of us not to fruitlessly repeat.
  - jschwartzi 10y ago
    It's probably all there in their issue trackers. That's partly why software teams track issues, because somewhere there's a decision to be made and a story to be told, and that story is written in the issue before it's closed. Software development is really all about finishing stories.
codemac 10y ago
There was a great talk recently by Rich Hickey[0] about how change itself is breakage. Breaking early and often is catastrophically worse than python 2.7 in my opinion. [0]: https://www.youtube.com/watch?v=oyLBGkS5ICk https://www.youtube.com/watch?v=oyLBGkS5ICk
- nickbauman 10y ago
  Agreed. Hickey, in that talk, claimed if you really did break backward compatibility, you should just name it something else. So in real terms Python3 should have been renamed to Pythonidae or something like that. Eventually the last folks working in the 2.7.* branch would notice that nobody else was in the room and hopefully figure out where they went.
  - btrask 10y ago
    If you look at long-running, successful projects, they don't do this. One example is the original V8 dev team that went off to create Dart (AIUI). Nobody followed them and V8 got replacement developers. (But perhaps that was a particularly egregious case.)
    - derefr 10y ago
      I feel like the only responsible thing to do in such cases—if you truly believe that the thing you're abandoning is just a plain-old failure of engineering, and it's effectively self-flagellation to be subjected to maintaining it—is to poison the well/salt the earth when you leave, so that people are at least forced to switch to something else, if not your replacement project. Badly-engineered buildings get condemned, and we make it illegal to use them, even if it might benefit someone to use the building in exchange for the (likely not-very-well-considered) risk of the roof falling on them. What sort of political/social infrastructure would it take to allow someone to condemn a codebase?
      - kibwen 10y ago
        Google has begun building "time bombs" into Chrome that will start inconveniencing users once the binaries reach a certain age without being updated (I believe this is specifically related to certificate validation, but I'm not going to look up details because I don't want to be put on a watchlist for googling "chrome time bomb" :P ).
greglindahl 10y ago
Here's an example of Microsoft Office killing off backwards compatibility for some older document formats: https://tech.slashdot.org/story/08/01/01/137257/office-2003-service-pack-disables-older-file-formats https://tech.slashdot.org/story/08/01/01/137257/office-2003-...
- dogma1138 10y ago
  They've dropped support for 15-16 year old file formats with a workaround in place.... The old versions of Word is Word 2 for Windows, and Word 4 for Mac, and Excel 4.... The work around isn't complicated it's long because they gave you 3 methods of how to get the functionality back (the simplest way is to download 1 to 3 self installing hotfixes depending on what files you still need to access, I'm pretty sure they just didn't want to pay royalties anymore for supporting some of the non-MSFT formats nor did they really want to support nearly 20 year old binary formats) and that document has been revised as late as 2011, MSFT dropped support for Office 2003 in 2014, 11 years after release. Yes MSFT does break backward compatibility once in awhile, but it's usually quite warranted, they offer supported workarounds or exemptions and they tend to break it once in 1-2 decades rather than once every 2 years. Sorry but giving an example of MSFT dropping support for Word 2 or Excel 4 file formats that were designed probably in the late 80's in 2008 isn't exactly a good example of a company breaking backwards compatibility. If your organization circa 2008 was still dependant on 2 decades old formats don't blame the vendor, you should have migrated that data, It's like complaining that verbatim stopped making floppy disks, oh noes what would you do?!
  - Someone 10y ago
    Even assuming conversion works flawless, I don't think full migration is possible. I bet archive.org has zillions of files that now aren't easily readable anymore. Do you think it is realistic to expect them to fetch every single copy from storage and convert it? I bet they cannot even find _all_ of them, given that documents may be embedded in mailbox files of various formats, in disk images, in usenet posts, in archives using various obsolete compression methods, embedded using OLE in other files, etc. Even if they can find them, conversion in-place may not be possible. A file inside some archive file may grow in size, making the archive file larger than the archive file format allows. For example, a few years after they declared conversion done, somebody could find an old CD and upload an old brochure or logo. A converted version may already be available, but how would that somebody know that that file looks the same? All they have are the files, and they are different. Except for scale, archive.org isn't exceptional here. Large corporations face the same issue. They likely will bite the bullet, though, keep around some way to convert files for a few years after they declare to be 'done', and accept that some data will be lost after that.
dispose13432 10y ago
I think another example was by joelonsoftware, where when MS moved to win 95, they actually ran popular software looking for bugs, and found the SimCity would use-after-free (which, before 95 wouldn't crash), so they modified their OS to leave that memory cell intact even after free.
- monochromatic 10y ago
  They do this kind of stuff all the time[0], and it provides enormous value to users. [0] https://blogs.msdn.microsoft.com/oldnewthing/ https://blogs.msdn.microsoft.com/oldnewthing/
- rasz_pl 10y ago
  They do it to this day. Application compatibility assistant or whatever its called now runs on every single machine and hot patches loaded programs. Malware authors love it. https://tzworks.net/prototype_page.php?proto_id=33 https://tzworks.net/prototype_page.php?proto_id=33
saurik 10y ago
I would argue the most relevant example here would be Visual Fred (aka, Visual Basic .NET), the saga of Microsoft throwing people who had relied on Visual Basic 6 under the bus; for more on this topic as it relates to Python 3 and Ruby 1.9, I wrote a comment a month ago that contrasts. https://news.ycombinator.com/item?id=13062777 https://news.ycombinator.com/item?id=13062777
- guitarbill 10y ago
  > the saga of Microsoft throwing people who had relied on Visual Basic 6 under the bus Even though the IDE isn't supported, Microsoft still supports VB6 applications, and will throughout the lifetime of Windows 10 [0]. As an ex VB6 developer, I find this crazy. Just goes to show how much legacy VB6 must still be out there. VB.NET got me to move to dot.NET, and then to C#. And I'm a better dev because of it. So you could say it fulfilled its role at least once. And let's not kid ourselves here, VB6 was always limited. E.g. subclassing was almost mandatory for advanced functionality, but would cause the debugger and program itself to crash when it hit a breakpoint. 64-bit compatibility was never going to happen, my understanding is the IDE includes some 16-bit programs which is why it's no longer supported. At some point, you've got to cut your losses. If anything, IMO, Microsoft's continued support of VB6 is sending the wrong message to managers and developers. [0] https://msdn.microsoft.com/en-us/vstudio/ms788708.aspx https://msdn.microsoft.com/en-us/vstudio/ms788708.aspx
  - deleted 10y ago
    [deleted]
  - catnaroek 10y ago
    The real reason why Microsoft had to drop VB6 is because its object model was fundamentally incompatible with .NET. VB6 was a very thin wrapper around COM, after all. That C# happens to be technically superior to VB6 in most (but not all) respects just provided Microsoft with a convenient excuse for deflecting criticism. That being said, I don't mourn the loss of VB6. It was a truly horrible language, and the fact a whole generation of programmers preferred it over superior contemporary alternatives (e.g. Delphi) doesn't speak well of them. The only good thing about VB6 was its form editor, and that isn't even a language feature.
rdw 10y ago
I feel like you could make this argument about Apple just as well. It's got a larger market cap, so even more arguably successful. And they break compatibility (judiciously) in order to create a better product.
mrich 10y ago
It's hard to collect money for a rolling upgrade. This was the pre-cloud era and you sold products. With Windows 10 that's changed and it looks like they found a way to monetize user data also.
coldtea 10y ago
>Arguably one of the most successful companies in the world is Microsoft. The reasons for their success are many, but at least one is the focus on backwards compatibility. Well, Apple is another very successful company, and follows the exact opposite model. So, the empirical data support both approaches (if the goal is being a succesful company).
- noselasd 10y ago
  Does this mean most OS X applications or drivers break when OS X is updated, and have to be recompiled or have is source code updated or re-written ?
  - coldtea 10y ago
    No, it just means that Apple breaks backwards compatibility much more often (for PowerPC to Intel transition, for 32 to 64 bits, drops Carbon, changes APIs, etc). Though what you describe also happens to some apps using certain APIs that need code changes to run on a newer OS X. We weren't talking about MS satisfying that basic level of compatibility (that Apple usually satisfies as well), but much much increased levels (which Apple doesn't).
Latty 10y ago
Backwards compatibility can tie you to things that you need to get rid of though. At some point you have to decide to drop support for stuff and move on, otherwise something else that has will come in and eat your lunch.

Longhanks 10y ago

And now we're stuck with decades old software and API stacks while Metro/Modern UI/UWP struggles to take off since about 5 years.

fygdttysf 10y ago
The day MS depracates WinAPI, they're control of the desktop is over, as every company which develops huge codebases will switch to an environment where their programs doesn't have to be rewritten at MS's discretion.
- derefr 10y ago
  Is there any platform an enterprise could switch to that would guarantee a slower rate-of-change than Windows? "One major rewrite-requiring breaking change in 20 years" sounds like—if not a good deal—the best one I could foresee getting anywhere.
  - dispose13432 10y ago
    Once you rewrite once, the red line is broken. I think joelonsoftware has an article about that.
  - Someone 10y ago
    IBM (Oracle, too, I would guess). http://www.longpelaexpertise.com.au/ezine/IBMBackwardCompatibility.php http://www.longpelaexpertise.com.au/ezine/IBMBackwardCompati... has a very good observation, though: "The reality is that backward compatibility is only possible if there are enough users paying […] for it." It is the same for Microsoft. If, for example, several big customers would want 16 bit support on x64, I'm sure they would provide it.
- umanwizard 10y ago
  What platform is that?
- pjmlp 10y ago
  Sure they will rather change to a platform in the hands of Oracle,Apple or Google.
paulddraper 10y ago
> stuck with decades old software "reap the rewards of mature software"
fl0wenol 10y ago
The issue is that this is only of concern to application developers who don't want to use old APIs. Systems owners, managers, and users won't care if it gets the job done predictably and cost-effectively. And if the vendor is willing to keep that stack around and support it...

jonathonf 10y ago

> Microsoft breaking compatibility, more-so post Windows 7 IIRC, there have been several instances of this between releases, less so from the user application perspective, but rather from the driver model. Windows 3.1 to Windows 95 (16- to 32-bit), Windows ME to Windows 2000 (NT kernel), Windows XP to Vista (UAC etc.) each saw various issues with device drivers. The extent of user application backwards-compatibility is impressive, with only Windows 10 removing 16-bit application support (boo). For example, even now it's possible to double-click on the application icon at the left-hand of the window title bar to close the application - à la Win 3.1. > The only mistake Microsoft made was not doing rolling releases I think they're 'fixing' that with Windows 10.

dtech 10y ago
> The extent of user application backwards-compatibility is impressive, with only Windows 10 removing 16-bit application support (boo) It's still supported on the 32-bit versions of win10! It has never been supported on a 64-bit version of windows though.
- jonathonf 10y ago
  That raises several questions for my next team meeting...
  - jonathonf 10y ago
    Well, it does. I was told one thing and reality is different. I'm supposed to trust other members of my team rather than fact-check their input.
wvenable 10y ago
> Windows 10 removing 16-bit application support (boo). CPU's in 64bit mode don't support running code in 16bit mode -- Windows 10 (actually 7) didn't remove support, it never existed to begin with. This is also why 32bit versions of Windows can and do still run 16bit applications.

ebbv 10y ago

This isn't really true. If Microsoft of 2016 has a focus on backwards compatibility it is only because of their myriad mistakes in the past. I know people have this false impression because of fluff pieces that have been written about Microsoft having a focus on backward compatibility but anyone who has lived through the last 30 years of computing history knows this isn't really true. They have broken backward compatibility numerous times. Many, many DOS programs would not run under Windows 3.1, necessitating users to boot into or exit out into DOS to run those programs, and of course Windows programs could not run under DOS. Windows 95 generally did better at running DOS programs but it was far from flawless. Many programs required all kinds of workarounds and even patches. Windows NT was originally a complete departure from DOS and Windows 3.1, 95, etc. only later on did Microsoft realize that they needed a compatibility layer for NT to ever go mainstream (along with a rebranding.) Windows Vista broke tons of stuff too. Including everybody's printer drivers. When Vista was released you could buy a Vista computer along with a printer which had no drivers for Vista and which HP would tell you there's no Vista drivers ever coming. Windows 8 may not have broken execution of Windows 7 apps but the entire UI was a complete shift from what users were accustomed to. Whether you liked it or not, that kind of major change is a big mistake when so many of your customers are tech novices who are not going to have an easy or enjoyable time learning how to use their computer from scratch. This is just scratching the surface. My point is let's tell the truth here, Microsoft is not some hero of backward compatibility who has never made a mistake and always kept their users at heart.

filereaper 10y ago
Not really arguing with your points, but it seems Microsoft has a lot of lessons learnt from maintaining backwards compatibility. It'd be wonderful if their architects collected and codified these somewhere, ie "we did X because of Y, it didn't work, because Z ends up happening" Mostly as a lesson for the rest of us not to fruitlessly repeat.
- jschwartzi 10y ago
  It's probably all there in their issue trackers. That's partly why software teams track issues, because somewhere there's a decision to be made and a story to be told, and that story is written in the issue before it's closed. Software development is really all about finishing stories.

codemac 10y ago

There was a great talk recently by Rich Hickey[0] about how change itself is breakage. Breaking early and often is catastrophically worse than python 2.7 in my opinion. [0]: https://www.youtube.com/watch?v=oyLBGkS5ICk https://www.youtube.com/watch?v=oyLBGkS5ICk

nickbauman 10y ago
Agreed. Hickey, in that talk, claimed if you really did break backward compatibility, you should just name it something else. So in real terms Python3 should have been renamed to Pythonidae or something like that. Eventually the last folks working in the 2.7.* branch would notice that nobody else was in the room and hopefully figure out where they went.
- btrask 10y ago
  If you look at long-running, successful projects, they don't do this. One example is the original V8 dev team that went off to create Dart (AIUI). Nobody followed them and V8 got replacement developers. (But perhaps that was a particularly egregious case.)
  - derefr 10y ago
    I feel like the only responsible thing to do in such cases—if you truly believe that the thing you're abandoning is just a plain-old failure of engineering, and it's effectively self-flagellation to be subjected to maintaining it—is to poison the well/salt the earth when you leave, so that people are at least forced to switch to something else, if not your replacement project. Badly-engineered buildings get condemned, and we make it illegal to use them, even if it might benefit someone to use the building in exchange for the (likely not-very-well-considered) risk of the roof falling on them. What sort of political/social infrastructure would it take to allow someone to condemn a codebase?
    - kibwen 10y ago
      Google has begun building "time bombs" into Chrome that will start inconveniencing users once the binaries reach a certain age without being updated (I believe this is specifically related to certificate validation, but I'm not going to look up details because I don't want to be put on a watchlist for googling "chrome time bomb" :P ).

greglindahl 10y ago

Here's an example of Microsoft Office killing off backwards compatibility for some older document formats: https://tech.slashdot.org/story/08/01/01/137257/office-2003-service-pack-disables-older-file-formats https://tech.slashdot.org/story/08/01/01/137257/office-2003-...

dogma1138 10y ago
They've dropped support for 15-16 year old file formats with a workaround in place.... The old versions of Word is Word 2 for Windows, and Word 4 for Mac, and Excel 4.... The work around isn't complicated it's long because they gave you 3 methods of how to get the functionality back (the simplest way is to download 1 to 3 self installing hotfixes depending on what files you still need to access, I'm pretty sure they just didn't want to pay royalties anymore for supporting some of the non-MSFT formats nor did they really want to support nearly 20 year old binary formats) and that document has been revised as late as 2011, MSFT dropped support for Office 2003 in 2014, 11 years after release. Yes MSFT does break backward compatibility once in awhile, but it's usually quite warranted, they offer supported workarounds or exemptions and they tend to break it once in 1-2 decades rather than once every 2 years. Sorry but giving an example of MSFT dropping support for Word 2 or Excel 4 file formats that were designed probably in the late 80's in 2008 isn't exactly a good example of a company breaking backwards compatibility. If your organization circa 2008 was still dependant on 2 decades old formats don't blame the vendor, you should have migrated that data, It's like complaining that verbatim stopped making floppy disks, oh noes what would you do?!
- Someone 10y ago
  Even assuming conversion works flawless, I don't think full migration is possible. I bet archive.org has zillions of files that now aren't easily readable anymore. Do you think it is realistic to expect them to fetch every single copy from storage and convert it? I bet they cannot even find _all_ of them, given that documents may be embedded in mailbox files of various formats, in disk images, in usenet posts, in archives using various obsolete compression methods, embedded using OLE in other files, etc. Even if they can find them, conversion in-place may not be possible. A file inside some archive file may grow in size, making the archive file larger than the archive file format allows. For example, a few years after they declared conversion done, somebody could find an old CD and upload an old brochure or logo. A converted version may already be available, but how would that somebody know that that file looks the same? All they have are the files, and they are different. Except for scale, archive.org isn't exceptional here. Large corporations face the same issue. They likely will bite the bullet, though, keep around some way to convert files for a few years after they declare to be 'done', and accept that some data will be lost after that.

dispose13432 10y ago

I think another example was by joelonsoftware, where when MS moved to win 95, they actually ran popular software looking for bugs, and found the SimCity would use-after-free (which, before 95 wouldn't crash), so they modified their OS to leave that memory cell intact even after free.

monochromatic 10y ago
They do this kind of stuff all the time[0], and it provides enormous value to users. [0] https://blogs.msdn.microsoft.com/oldnewthing/ https://blogs.msdn.microsoft.com/oldnewthing/
rasz_pl 10y ago
They do it to this day. Application compatibility assistant or whatever its called now runs on every single machine and hot patches loaded programs. Malware authors love it. https://tzworks.net/prototype_page.php?proto_id=33 https://tzworks.net/prototype_page.php?proto_id=33

saurik 10y ago

I would argue the most relevant example here would be Visual Fred (aka, Visual Basic .NET), the saga of Microsoft throwing people who had relied on Visual Basic 6 under the bus; for more on this topic as it relates to Python 3 and Ruby 1.9, I wrote a comment a month ago that contrasts. https://news.ycombinator.com/item?id=13062777 https://news.ycombinator.com/item?id=13062777

guitarbill 10y ago
> the saga of Microsoft throwing people who had relied on Visual Basic 6 under the bus Even though the IDE isn't supported, Microsoft still supports VB6 applications, and will throughout the lifetime of Windows 10 [0]. As an ex VB6 developer, I find this crazy. Just goes to show how much legacy VB6 must still be out there. VB.NET got me to move to dot.NET, and then to C#. And I'm a better dev because of it. So you could say it fulfilled its role at least once. And let's not kid ourselves here, VB6 was always limited. E.g. subclassing was almost mandatory for advanced functionality, but would cause the debugger and program itself to crash when it hit a breakpoint. 64-bit compatibility was never going to happen, my understanding is the IDE includes some 16-bit programs which is why it's no longer supported. At some point, you've got to cut your losses. If anything, IMO, Microsoft's continued support of VB6 is sending the wrong message to managers and developers. [0] https://msdn.microsoft.com/en-us/vstudio/ms788708.aspx https://msdn.microsoft.com/en-us/vstudio/ms788708.aspx
- deleted 10y ago
  [deleted]
- catnaroek 10y ago
  The real reason why Microsoft had to drop VB6 is because its object model was fundamentally incompatible with .NET. VB6 was a very thin wrapper around COM, after all. That C# happens to be technically superior to VB6 in most (but not all) respects just provided Microsoft with a convenient excuse for deflecting criticism. That being said, I don't mourn the loss of VB6. It was a truly horrible language, and the fact a whole generation of programmers preferred it over superior contemporary alternatives (e.g. Delphi) doesn't speak well of them. The only good thing about VB6 was its form editor, and that isn't even a language feature.

rdw 10y ago

I feel like you could make this argument about Apple just as well. It's got a larger market cap, so even more arguably successful. And they break compatibility (judiciously) in order to create a better product.

mrich 10y ago

It's hard to collect money for a rolling upgrade. This was the pre-cloud era and you sold products. With Windows 10 that's changed and it looks like they found a way to monetize user data also.

coldtea 10y ago

>Arguably one of the most successful companies in the world is Microsoft. The reasons for their success are many, but at least one is the focus on backwards compatibility. Well, Apple is another very successful company, and follows the exact opposite model. So, the empirical data support both approaches (if the goal is being a succesful company).

noselasd 10y ago
Does this mean most OS X applications or drivers break when OS X is updated, and have to be recompiled or have is source code updated or re-written ?
- coldtea 10y ago
  No, it just means that Apple breaks backwards compatibility much more often (for PowerPC to Intel transition, for 32 to 64 bits, drops Carbon, changes APIs, etc). Though what you describe also happens to some apps using certain APIs that need code changes to run on a newer OS X. We weren't talking about MS satisfying that basic level of compatibility (that Apple usually satisfies as well), but much much increased levels (which Apple doesn't).

Latty 10y ago

Backwards compatibility can tie you to things that you need to get rid of though. At some point you have to decide to drop support for stuff and move on, otherwise something else that has will come in and eat your lunch.