I was reflecting on the fact that while the PC world has seen a great degree of at least theoretical backward compatibility, the Macintosh of 2011 is almost entirely unlike the Macintosh of 1984, except for some UI conventions.
The Macintosh has gone through THREE different processor families (Motorola 68k, PowerPC, and x86), including a change of endianness, while the PC has remained in the x86 family, but just has jumped up from 16 to 32 to 64 bit.
Also, during the PowerPC era, the Mac transitioned to a UNIX based operating system, completely replacing the old OS. While the PC has transitioned to NT based OS’s, somehow it doesn’t seem as drastic because there was a great deal of backward compatibility, at least in Windows XP. Most software designed for Windows 95 ran fine under XP, and may still run on Windows 7 (though, the transition from DOS to the DOS Shell Windows versions might add to a perception of change, since the Mac always had a GUI, unlike the PC.
So, do y’all agree that the Mac has seen more drastic changes than the PC has? Or, is this an illusion? This is really more of an opinion question since there is no “unit of change of computer architecture” that can be formally measured. “This new Mac is 3 incompatibilitons different from the old one!”.
What hasn’t changed in the Mac? I know that the current Mac GUI widgets do hearken back to the early days, but I don’t know how much of the code remains and to what extent it has been reimplemented to LOOK the same.
yes. a smaller userbase and lower corporate/enterprise entrenchment means you can shuck off legacy without destroying your business.
64-bit Windows cannot run 16-bit x86 code. This is because AMD removed Virtual 8086 mode from the amd64 architecture when the CPU is in long mode. As far as I know, the 32-bit version of Windows 7 still can run 16-bit code.
Single button mouse vanished some years ago. Arguably the laptops have a single button - as the entire surface is the button, however the touch interface supports all manner of multiple button motifs - to the point where a simple multi-button mouse - even with scroll wheel is obsolete. I never bother to physically click anymore. Everything works with the gesture interface.
The rolling backward compatibility on a Mac versus a Windows box has a number of parallels. The change from OS-9 to OS-X was in the same league as the introduction of NT. For all intents it was a totally new operating system, that maintained some legacy capability. The main compatibility issue being the file systems. OS-X provided the ability to run a OS-9 binaries in “Classic” only killing that support a few years ago. Support for PowerPC binaries only vanished in Lion, released last week.
On the whole, the only feature of a Mac that has remained essentially constant is the startup sound. Even that has been re-recorded and messed with over the years, but despite this, the sound is quite clearly the same basic sound.
There are a number of user interface rules that remain constant. One obvious one is the idea that you only have one instance of any application running. If you open multiple files the application is simply asked to open another file - the system does not run up another copy of the application. Also, the file system has remained fairly static over time. The semantics of how files work from the point of view of the user is mostly the same as it was decades ago. The issue of file identity i a case in point. Under the veneer the change to OS-X made some significant changes to the implementation, especially as many of the semantics were not just different to a Unix file system, but actually resulted in contradictory clashes that could not be fully resolved. Case sensitivity being the most obvious.
And the major changes in the Mac environment (both hardware and OS) have all included compatibility modes to run programs from before the change, just like with Windows. I can’t run OS9 apps on my current system any more, but that’s the same basic thing as what you’re saying about Windows no longer running 16-bit code.
But it isn’t. For one thing, 16-bit code is more analogous to 68k code, which has been defunct on the Mac forever. Second, 16 bit code continues to run on at least one version of the current system 20 years later. Third, the only reason Windows drops it is lack of hardware. There is no reason why OS X Lion can not run Rosetta. It was artificially removed.
Finally, I can run an emulator and run my 16 bit code. (Heck, one comes with many versions of Windows 7 64-bit). You can’t do that on a Mac. Well, you can, but not legally. You must violate the user agreement, since no software emulates that special chip. And to run 68k code legally, you have to own an old Mac to download the ROM code off of it.
It really is only the same on a very superficial level. Once you get under the hood, Microsoft cares about backwards compatibility, and Apple actively tries to thwart it.
This is quite true. Although twart isn’t perhaps the right term. Apple gives it to you for as long as they are prepared to maintain it - and give developers a reasonable chance to port. The difference between MS and Apple on this runs deep. A very significant part of problems that MS face with Windows comes from this legacy support. A lot of the security, instability, and significant difficulties they have faced advancing the technology inside the OS stem from this support. MS have killed off major technological changes (Longhorn for instance) that they simply could not get to work properly, despite many years of effort and probably hundreds of millions invested. Apple have the luxury of being able to kill off legacy support. Apple simply never got into the market segments where such support was critical, and by continuing to de-commit such support, they never will. They probably think this is a good bargain. MS probably think so too by now. But MS built a lot of their success on the back of this support. MS’s bedrock success is in commercial operations, and they would have found it very difficult to have succeeded as they did without the legacy support they provide. The Faustian bargain they have is that this appears to be a critical part of why MS are now faltering.
All things considered, I think Macintosh has been pretty decent about backwards compatibility. The later 68k series machines didn’t seem to have any major problems with original Mac software. The later Amigas that ran on '020 and '030 CPUs were not fully compatible with older Amiga software; likewise, the Atari TT and Falcon were not fully compatible with ST software. Mac didn’t have any problems until they moved to the PowerPC, which came after quite a good while. Apple didn’t really have much choice, by the way; unlike x86, the 68k family of processors were not continually upgraded in perpetuity.
About the poor Falcon/ST compatability. This was due to the way software was written. If software was written today how it was written for the ST in the 80s and early 90s, you’d find software that worked fine on one PC would stop working on a different PC.
It’s not a matter of computer design, it’s a matter of programming.
The Atari ST was never designed to be upgradable, so most programmers made assumptions about what capabilities the computer had or did not have, and about how the hardware worked.
Also, the ST was single tasking, so software routinely took over the entire machine. Since there was never any other software running, the programme didn’t have to worry about messing it up.
If you want software to work as fast as possible, the 100% best way to do this is to completely ignore the OS and access the hardware directly. Which in the earlier days of computing was a perfectly common way of doing things. But it did mean that even slight hardware changes could prevent software from working.
There’s a much greater degree of hardware compatibility between the Atari ST from 1985 and the Atari Falcon from 1992, than a PC from 2011 and a PC from 2004. Or even 2011 and 2007 for that matter.
But since programmers today know that their software will be sharing a computer with other software, and that each PC will vary in hardware, and that new hardware will routinely be created after the software is released, the programmer can’t access the hardware directly and have any expectation that it’ll work without seriously messing things up. So today all software accesses a PC’s capabilities through the compatibility layer of the OS.
This is true. I’m a Windows/.NET developer and basically everything that I’ve developed under Windows XP runs fine on Windows Server 2003 and now Windows 7, on boxes purchased in different years with different RAM configurations, different processors, different chipsets, etc.
[1] You can still — at least for time being — write an application in Carbon, Apple’s bridge API for software meant to run under MacOS 8, 9 and X. The Carbon API is not quite the same as the old Classic Mac API, but it does keep many of the old routines, some going back to 1984. Carbon is also a C API, so it has the same “procedural” style that was common for programming personal computers back in the 80s.
Not that I personally would want to write an app in a procedural language anymore.
[2] The classic Mac also introduced the resource fork — a secondary data stream in a file that can hold content independent of the file’s primary content. Resource forks still exist, although they’re hardly used in anything except Carbon applications, which are now quite rare. More than that though, both Apple’s HFS+ and Microsoft’s NTFS support multiple alternate data streams.
[3] The Mac’s command key, with it’s cloverleaf symbol, still exists and still has the same function it did in 1984. There’s also the option key, still being used for composing extra characters.
None of the old Classic code for drawing GUI elements is in OS X proper. This old code would have lingered on a bit in some OS 9 files, which were used to run Classic applications back when that was still possible. Support for Classic was dropped in Leopard (10.5) though.
I wouldn’t want to do a whole enterprise n-tier application in it, but I still use procedural code in web client scripting, and can do it when it otherwise is reasonable.
I remember those keys from the Apple 2 days when they were originally called the “open apple” and “closed apple” keys, then became Command and Option under the 2gs.
That’s misleading; System 7 broke a lot of apps, and it was on 68k just like System 6 was. (And that’s not even getting into System 7.0.0’s bugs… man was that OS a stinker!)
It would be a real stretch to say Apple, even when sticking with a single CPU architecture, has compatibility on-par with Microsoft.
