[scarface74]

No MacOS X when it was originally released had parts from NextStep and parts ported from Classic MacOS including QuickDraw, AppleScript, QuickTime, some audio frameworks etc.

The entire Carbon API was a port of classic MacOS APIs to make porting from classic MacOS to OS X easier.

MacOS X was a combination of both. That was the whole brouhaha of why Apple ported Carbon APIS to OS X because major developers like Adobe and Microsoft insisted on it.

That’s not to mention that the first 5 versions of MacOS had an entire OS 9 emulator built in.

To take the analogy to the extreme. MacOS had two parents - Classic MacOS and NextStep.

[cptskippy]

I would disagree, most of what was brought from Classic OS was ported, adapted, out of necessity and short lived. OSX was an entirely new operating system that ported some frameworks and software but wasn't backward compatible. Were it so, they wouldn't have provided an emulator.

I think you're just supporting the original assertion that Apple does not support things for very long. Does Software written for OS X v10.1 run on Catalina today without using 3rd party tools or emulators? Software written for Windows 95 still runs on Windows 10.

[scarface74]

You call the Carbon API that existed from 2001-2018 “short lived”? The entire Carbon API was used to port software like PhotoShop and Office.

Carbon was a port of enough of the Classic API to port major important programs.

AppleScript is still built into the current version of OS X. It was introduced in 1993-94

And seeing that 10.1 was PPC only, do you expect them to keep a PPC emulator around?

Can you run PPC based Windows NT software today on an x86 PC?

[dahauns]

Sounds to me more like the ported programs were short lived - and IMO, in that they are not entirely wrong.

Sure, Carbon and Rosetta certainly were no mean feat, and the drastic PPC/x86 break is something Microsoft never really had to deal with (heh, the biggest problem trying to run a PPC/MIPS/Alpha based NT application today is actually finding one :) ).

But Apple never went to the same lengths as Microsoft regarding backwards compatibility, and while Carbon and Rosetta immensely eased the transition, the continuity definitely wasn't comparable and it was never transparent to the developers (and in Apple's defense, this was never their intention and they always were quite open about it.)

For one, Rosetta (and thus PPC compatibility) was dropped with Lion in 2011, so no amount of Carbon would help 10.1 applications after that.

And even with Rosetta, each release, especially after Tiger, came with quite a list of API changes and deprecations (with the whole of Carbon declared obsolete in 2012) - and and increasingly longer list of high-profile software that would not run anymore and require an update or upgrade. And while Microsoft did a lot even to prevent and/or work around issues with notorious software (hello Adobe! :) ), Apple was far less willing to do so.

I mean, just as an example - I can run Photoshop 6.0 (from 2000) on Windows 10 (certainly no thanks to Adobe), but no chance for PS 7.0 even on Leopard...

[scarface74]

Carbon was declared obsolete in 2012 but wasn’t discontinued until 2019.

Porting from PPC to x86 was relatively easy. But you’re also forgetting about the first transition - from 68K to PPC.

Can you run the PPC version of any Windows NT apps?

[cptskippy]

PPC to x86 possibly the smoothest transition I've seen in my lifetime, for most it was just a recompile, and I'm convinced it was only as smooth as it was because of the shit show transition to OS X.

Apple announced it's plans to move to OS X in 1997 and that they'd ship an emulator, Blue Box, to run classic apps. That was met with a resounding "no" from the community.

Carbon was never suppose to exist, the Classic APIs were not memory safe, don't support thread, and had a lot of other issues. Apple wanted a clean break in the form of Cocoa but the community said no. So Apple came up with Carbon, which was sort of a port of Classic APIs to OS X, but because the two operating systems were so different it wasn't anywhere close to a 1:1 copy and required developers to port to it.

Since it's inception, Apple wanted Carbon dead, it required them to rewrite core parts of OpenStep in C and they had to maintain them alongside their Obj-C equivalents. It took them 12 years to get to the point where they felt comfortable killing it off and almost 20 years before they actually could.

> Can you run the PPC version of any Windows NT apps?

Developing for PPC was much like targeting x86 and PPC on a OS X. It was mostly a recompile unless the App used assembly. You can't run the PPC version of an NT app on modern hardware just as you can't run the PPC version of an OSX app on MacOS.

The difference thought is that PPC on NT never took off so there's something like 4 or 5 Apps for NT versus the thousands or hundreds of thousands for OSX.

[dahauns]

I haven't forgotten anything, I just fail to see the relevance to this discussion. (68k? Really? That one's been dead for 14 years. And what is with you and NT on PPC? You really want to start comparing a 25 year old, short-lived, ultra-niche side version no one bought or even wrote software for with the "mainline"?)

I think you missed the entire point of my posting, i.e. that even outside the architecture changes long term compatibility was never even near the same level (and different arch often not even the culprit). Carbon being available doesn't help you a thing when old software still doesn't work.

[scarface74]

If you are complaining that you can’t run 25 year old Mac software on an x86 Mac, the only option is for Apple to ship MacOS with a 68K emulator and a PPC emulator. The first version of MacOS that ran natively on x86 came out in 2006.

Yes I realize that PPC Macs came out in 1994. But they required a 68K emulator because even parts of MacOS were 68K.

[virtue3]

https://en.wikipedia.org/wiki/Carbon_(API)

"Carbon was an important part of Apple's strategy for bringing Mac OS X to market, offering a path for quick porting of existing software applications, as well as a means of shipping applications that would run on either Mac OS X or the classic Mac OS. As the market has increasingly moved to the Cocoa-based frameworks, especially after the release of iOS, the need for a porting library was diluted. Apple did not create a 64-bit version of Carbon while updating their other frameworks in the 2007 time-frame, and eventually deprecated the entire API in OS X 10.8 Mountain Lion, which was released on July 24, 2012. Carbon was officially discontinued and removed entirely with the release of macOS 10.15 Catalina."

I think you are confusing "supported" with EoL. Adobe was pissed because there was originally talk of doing a carbon64bit and they never supported it so they had to move their entire app over.

The main point is, that Windows would never stop that api from "existing" In some manner. Unlike Apple.

This is just a difference in how both companies view themselves. While Apple claims "it just works". That isn't quite true in some of the cases we have seen. Microsoft has actually done a far better job of this.

I know someone that worked on the visual studio team. They literally had 100-200 servers that would run overnight with each build guaranteeing that the software would install and run on every single permutation of windows on an array of hardware.

[scarface74]

So, what exactly did you say they refuted anything I said?

The Carbon API was 32 bit only and was supported until the latest release of MacOS.

Do you realize how many deprecated end of life frameworks that Microsoft has been lugging around for decades?

So should Apple have kept support for 68K software in 2019?

Also, do you realize that for all intents and purposes the entire .Net Framework is deprecated and EOL except for minor compatibility updates?

There are plenty of “pissed” .Net Framework developers who feel abandoned by MS.

[jsgo]

I've only heard complaints from Silverlight and Windows Phone/Mobile developers anecdotally.

From a web perspective (and my experience), .NET Framework 2/4 -> Core is actually not a big changeover outside of the views (probably better if you switched to MVC).

The Windows Phone apps I built are dead now, but that isn't a matter of APIs no longer being supported, but an entire platform going under.

As a macOS user, I had one operating system update kill external GPU w/ Nvidia cards (that sucked) and another update kill 32 bit apps (that one isn't a big one for me personally). All on the same computer.

[scarface74]

The entire ASP.Net Core and Entity Framework architecture was changed and is not compatible. Not to mention all of the legacy third party .Net Framework only third party packages that don’t work.

Microsoft also completely abandoned Windows CE/Compact Framework while there were plenty of companies that had deployed thousands of $1200-$2000 ruggedized devices for field services work.

[int_19h]

And yet you can still run .NET 1.0 apps on Win10, and this isn't changing in the foreseeable future.

Hell, you can run VB6 apps on Win10 - it even ships the runtime! - and the remaining hold-outs in that developer community have been complaining about abandonment for two whole decades now.

[scarface74]

https://docs.microsoft.com/en-us/dotnet/framework/install/ru...

The .NET Framework 1.1 is not supported on the Windows 8, Windows 8.1, Windows Server 2012, Windows Server 2012 R2, or the Windows 10 operating systems. In some cases, the .NET Framework 1.1 is specifically identified as required for an app to run. In those cases, you should contact your independent software vendor (ISV) to have the app upgraded to run on the .NET Framework 3.5 SP1 or later version. For additional information, see Migrating from the .NET Framework 1.1.