Apple Prepares MacOS Users For Discontinuation of 32-Bit App Support (arstechnica.com)

Last year, Apple announced that macOS High Sierra "will be the last macOS release to support 32-bit apps without compromise." Now, in the macOS High Sierra 10.13.4 beta, Apple is notifying users of the impending change, too. "To prepare for a future release of macOS in which 32-bit software will no longer run without compromise, starting in macOS High Sierra 10.13.4, a user is notified on the launch of an app that depends on 32-bit software. The alert appears only once per app," Apple says in the beta release notes. Ars Technica reports: When users attempt to launch a 32-bit app in 10.13.4, it will still launch, but it will do so with a warning message notifying the user that the app will eventually not be compatible with the operating system unless it is updated. This follows the same approach that Apple took with iOS, which completed its sunset of 32-bit app support with iOS 11 last fall. Developers and users curious about how this will play out will be able to look at the similar process in iOS for context. On January 1 of this year, Apple stopped accepting 32-bit app submissions in the Mac App Store. This June, the company will also stop accepting updates for existing 32-bit applications. iOS followed a similar progression, with 32-bit app submissions ending in February of 2015 and acceptance of app updates for 32-bit apps ending in June of 2015.

Comments

Apple compatibility is a joke

[Anonymous Coward]

I can still run Windows apps originally compiled in 1992 on Windows 10.

Just sayin'.

Re:Apple compatibility is a joke

[Anonymous Coward]

Microsoft needs to maintain Windows compatibility because it's used extensively in the business world for mission-critical applications, sometimes requiring that old and unsupported software still work the way it always did. Apple can get away with this more easily because most Macs are in the home, being used for... well I'm not exactly sure what people use them for, Facebook or something I guess, but they wouldn't be caught dead using old software.

Re:Apple compatibility is a joke

[sit1963nz]

Weird because we have lots of Windows XP, Win7 and Win8 Apps that fail to run under Win10. Just sayin'

Re:Apple compatibility is a joke

[0100010001010011]

Apple has handled 68k -> PPC -> PPC64 -> x86 -> x64 -> arm -> arm64 fairly well.

How much 'cruft' and security holes exist in Windows because of that backwards compatibility? Let some things die. If you want to run an app on Windows 3.1, run a VM of Windows 3.1.

Re: Apple compatibility is a joke

[Anonymous Coward]

Once had a woman laugh at me because I used the WSDOT webpage to view Seattle traffic maps. Literally said "Your 'app' looks so old fashioned" and remarked how quaint it was, like I was using fucking Gopher or something.

She was an Apple user.

Re:Apple compatibility is a joke

[Anonymous Coward]

You must be the exception or doing some weird shit. We just finished our migration from win7 to win 10, only 3 of the ~150 apps had any compatibility issues.

Re:Apple compatibility is a joke

[Anonymous Coward]

Um, x64 -> arm -> arm64? You're having bad hallucinations again, stop snorting oven cleaner, fucking moron.

Re: Apple compatibility is a joke

[Anonymous Coward]

VMs do jack shit when that application powers a $1m CNC mill that it talks to over RS232

Re:Apple compatibility is a joke

[sit1963nz]

Last count of Apps we use at our institution, it was 20,000. Most of our incompatibilities are with instrument controllers. We are trialing one system with a 32 bit version of Win10 with some new software they say should work. Upgrades are not always easy, they can be locked to a CPU serial number, ethernet MAC address, ID of a hard drives, etc.

Re: Apple compatibility is a joke

[sit1963nz]

Well I have run a Parallels VM with Windows 95 that I mangled to get working with a USB to serial adaptor so we could revalidate our Laminar Flow cabinets. But yes, instruments are the bane of my existence too for compatibility issues.

Re:Apple compatibility is a joke

[bursch-X]

There are some games that just won't ever be ported to 64 bit. That's a crying shame those will go the way of the Dodo. For everything else you shouldn't use apps that are so old. The transition to 64-bit apps on macOS has happened long ago. It's a non issue for everything but games.

Re:Apple compatibility is a joke

[DontBeAMoran]

He's clearly from the future.

Wait for Apple to unveil the MacBook Air and Mac mini replacements and you'll understand.

Re:Apple compatibility is a joke

[0100010001010011]

Do a diff of find / on both iOS and MacOS. It's just BSD with a pretty paint job. People pay for the paint job not the BSD.

Re:Apple compatibility is a joke

[steveb3210]

I can still run Windows apps originally compiled in 1992 on Windows 10.

Just sayin'.

But you deal with the consequences in the limitations legacy support has put on windows development over the last 20 years.

Re:Apple compatibility is a joke

[Anonymous Coward]

I'm pretty sure you can't run a 16bit windows 3.1 application compiled in 1992 natively on the 64 bit version of Windows 10.

Re:Apple compatibility is a joke

[Anonymous Coward]

Sounds like you are inept. You should get on the Apple train so your uselessness can be seen as an asset.

Re: Apple compatibility is a joke

[Anonymous Coward]

Whatâ(TM)s an A11 CPU? Is that not arm64 derived?

Re:Apple compatibility is a joke

[Anonymous Coward]

Wait for Apple to unveil the MacBook Air and Mac mini replacements and you'll understand.

I hear they're going to remove the spacebar this time.

So brave. So innovative.

(CAPTCHA = 'travesty' incidentally what this company has become)

Re:Apple compatibility is a joke

[Anonymous Coward]

You're correct, they run just fine on the 32 bit version. It's called WOW, not WOWOW.

Re: Apple compatibility is a joke

[Midnight Thunder]

While I do feel Apple can be too eager in breaking backwards compatibility, I also think Microsoftâ(TM)s model is equally absurd.

In many ways I imagine the better model would be to to break backwards compatibility and then run legacy apps in a transparent VM. Maybe something like Wine for Legacy Windows?

Re:Apple compatibility is a joke

[Anonymous Coward]

Right, but then you're limited to 32 bit applications. So you can either run a 64 bit version of Windows 10 and run 32 and 64 bit applications, or run the 32 bit version and run 16 and 32 bit applications. So depending on the version of Windows 10 being run, you may not be able to run a Windows application compiled in 1992 as the parent states.

Re: Apple compatibility is a joke

[Hal_Porter]

You should go to Raymond Chen's Old New Thing blog and tell him this. I'm sure he'd be eager to hear one liner technical advice from Slashdotters on how Microsoft should handle back compatibility.

https://blogs.msdn.microsoft.c...

Re: Apple compatibility is a joke

[sg_oneill]

Any OSX app going back to the start of the intel era still runs, so this is the first break in compatibility. However itâ(TM)s entirely reasonable , itâ(TM)s been a very long time since apples actually made a 32bit machine and weâ(TM)re talking about 12 year old software

Re:Apple compatibility is a joke

[SvnLyrBrto]

Which ones? No really... serious question. Can you think of any titles?

Don't get me wrong... I have a fair assortment of classic games. But most are purchased from GoG and run in dosbox, which I have no doubt will be updated to support 64-bit Macs, assuming it hasn't already. (Sid Meier's Alpha Centauri still gets regular gameplay and is still much better than the disappointment that is Civ: Beyond Earth.) But in the last decade and a half, going from old versions of OS X that included Classic OS 9 emulation, to Intel, to 64-bit, to Cider ports, official and unofficial; I have had exactly *ONE* game that I cared about quit working. That game was Homeworld 2, which was a PPC title and quit working with whichever version (I forget) dropped Rosetta. But, go figure, an updated Homeworld 2 came out a few years back, with updated and remastered graphics for modern monitor resolutions, and a similarly updated remastered Homeworld 1 (Which, for some reason, I had never gotten around to playing, despite my great affection for the sequel.) thrown in as a bonus.

Re: Apple compatibility is a joke

[Anonymous Coward]

Good fucking luck with control systems.

A system that costs a million bucks bought from ABB for example is guaranteed to never run on anything but the developerâ(TM)s machine and the one computer he installed it on. The developer was probably a sub-sub-sub-contractor from a company long out of business in a country that changed names twice. The source code is probably on an 8â floppy disk with sector errors.

Thereâ(TM)s also a good chance that the electronics engineers who made the system implemented everything to run on CANBUS using a controller board made by a vendor that was bought four times over and dissolved and the drivers, schematics, etc... were all lost.

Then thereâ(TM)s nifty things like SCADA, the next generation of stupid. 12000 pages of specifications which are implemented selectively. Every company is 100% SCADA compatible but no two systems can inter-operate. You find yourself buying Siemens Ethernet switches because the vendor couldnâ(TM)t be bothered to even follow Ethernet standards and used some awesome âoeStandardâ loop prevention protocol which is only standard because Siemens wrote an ignored RFC.

I have worked with lots of industrial control systems which only run on Redhat 6 (not RHEL, but the disti from the â90s)

Re:Apple compatibility is a joke

[Anonymous Coward]

Yeah, in the same way that Windows 10 is really just MS DOS with a paint job.

Re:Apple compatibility is a joke

[Freischutz]

Um, x64 -> arm -> arm64? You're having bad hallucinations again, stop snorting oven cleaner, fucking moron.

Naw, he probably just reads techradar: http://www.techradar.com/news/...

Re: Apple compatibility is a joke

[Gadget_Guy]

In many ways I imagine the better model would be to to break backwards compatibility and then run legacy apps in a transparent VM. Maybe something like Wine for Legacy Windows?

You mean like Windows XP Mode for Windows 7? It was a Virtual PC environment that ran a copy of Windows XP which was viewed with Remote Desktop to appear as if the application Windows ran on the main desktop. It was a good way to run 16-bit applications on a 64-bit version of Windows.

Of course, the way that you run 32-bit programs on 64-bit Windows is through a layer called WoW64. This quite literally stands for Windows on Windows. It is a subsystem that translates the differences between 32- and 64-bit APIs so that the software doesn't notice the changes.

Re:Apple compatibility is a joke

[Anonymous Coward]

Bad project management. Find a Ukrainian or Russian assembler head programmer to take the old code and make it work on the new.
Never buy shit that can't be reverse engineered, in case that company shafts you into early obsolesce. Once there were American assembler heads who could write machine code interpreters/emulators. You can do this over the web for a success fee, and get unwanted vendor license checks and call home stuff removed.

I used to laugh when big companies built software time bombs into stuff the government bought, but hey idiots abound. At the bank, source code was in the vault. You are in this position because management 'stretched' stuff to save money short term, and did sloppy product evaluation. At least Google have the brains to be self reliant.

Old 32 bit can be recompiled - if the source code exists. Only if 32bit binary driver blogs exist may there be troubles, and really experience grey beards can find and transplant similar drivers from elsewhere.

64 bits main disadvantage is that the processors are crippled so that software programs can find out if they are being traced or under debug mode. This will lead to expensive troubles later. Seriously consider open source - if your business will be around in 12 years time.

Re: Apple compatibility is a joke

[Anonymous Coward]

However itâ(TM)s entirely reasonable , itâ(TM)s been a very long time since apples actually made a 32bit machine and weâ(TM)re talking about 12 year old software

It is never "reasonable" to needlessly replace perfectly working software, no matter how old it is.

Re: Apple compatibility is a joke

[colinwb]

I still use Gopher, you insensitive clod!

(Well, actually I've never used Gopher, but apparently some people still do: Gopher protocol:
... Gopher has been described by some enthusiasts as "faster and more efficient and so much more organised" than today's Web services. The Gopher protocol is still in use by enthusiasts, and although it has been almost entirely supplanted by the Web, a small population of actively maintained servers remains. ...)

Re:Apple compatibility is a joke

[TheRaven64]

Windows 10 uses the same kernel, libc, init system, display server, and core libraries as MS DOS? Microsoft is a lot better at code reuse than I thought!

Re: Apple compatibility is a joke

[TheRaven64]

Why? VMs have been able to do RS-232 pass-through for ages. About 10 years ago, I visited a company that had just moved their old DOS-based control software into a VM for precisely this reason: they could install a USB RS-232 adaptor on their host and expose an emulated RS-232 device to the VM. This was a lot easier than trying to port the software (most of which was 8086 assembly) or get a USB serial interface working with DOS. There was some overhead, but line rate on RS-232 is so slow that you can burn a lot of cycles on emulation without noticing.

Re:Apple compatibility is a joke

[TheRaven64]

A lot of the games (including a lot of the ones bought from GOG) that I run are 32-bit Windows binaries running in WINE. That said, it's not clear that WINE needs to actually be a 32-bit Mach-O binary: it already includes its own PE loader and a bunch of translation layers that turn Windows structures into host system structures. It could probably be a 64-bit binary that would switch to 32-bit mode before jumping into Windows code and back to 64-bit code before switching out.

I doubt that Apple wants to ship x86 chips without 32-bit support, they just don't want to ship 32-bit versions of all of the core libraries and this approach would address that problem.

Re:Apple compatibility is a joke

[thegarbz]

By fairly well you fail to acknowledge the massive fuck you that was given to it's core audience (content creators) as companies like Adobe struggled to produce versions of their software thanks to the change. There were whole versions of Photoshop not available on Mac (THE platform to have if you used Photoshop professionally) because of the "fairly well" handled transition.

Cruft? Definitely. When the Windows source code leaks happened years ago there was a lot of comments in security circles on how much code was dedicated to ensuring something "legacy" didn't break. But security holes... to make that assertion you need to start by addressing the assumptions that replacement code is better than legacy code, and thus far the security bugs that have been "forward compatible" from old versions of Windows have been architectural, i.e. due to the way NTFS or SMB was designed and similar shit like that.

Re: Apple compatibility is a joke

[TheRaven64]

That's true. There are; however, very few examples of perfectly working software. Most software requires ongoing maintenance to keep it working in a changing environment (new hardware, integration with other components and new or changed OS services). This maintenance costs money. Apple can either spend developer resources on maintaining the 32-bit versions of software years after they've stopped selling any 32-bit CPUs, or they can invest that in other things (such as better security audits). Given finite developer resources, I'd prefer that they spent their effort on things that will benefit most users.

Re:Apple compatibility is a joke

[TeknoHog]

Apple has handled 68k -> PPC -> PPC64 -> x86 -> x64 -> arm -> arm64 fairly well.

IMHO, it was idiotic for Apple to go x86, because x86-64 was already available at the time. Soon after their first x86 machines, they moved on to Core 2, but the performance was crippled for a long time due to compatibility. And now they need this final transition stage to clean it all up.

Re: Apple compatibility is a joke

[Hal_Porter]

If you read Raymond Chen's Old New Thing blog he explains how the compatibility stuff is mostly in shims that get loaded only when an application needs them. So the notion that worrying about compatibility held back Microsoft is dubious.

Despite that Microsoft did abandon back compatibility around XP SP3 and Vista which both broke insecure code. And then they tried to convince people to stop writing Win32 code and start writing code for their newest API which changed every year. Joel ranted about this memorably

https://www.joelonsoftware.com...

Unfortunately the effect was that people stopped writing Win32 code and started writing code for IOS and Android. And people started doing everything they could to avoid OS versions because they broke all their third party apps and pushed them obnoxiously to use Metro ones. Which no one was writing.

Ie abandoning back compatibility gained them nothing and will probably kill the Windows as a platform in the long run.

Re: Apple compatibility is a joke

[MightyYar]

I downloaded porn with Gopher.

Now get off my lawn!

Re:Apple compatibility is a joke

[ChunderDownunder]

You mean Apple will release an iPad Pro running OS X,
As us Apple-haters have been demanding all along?! ;-)

Re:Apple compatibility is a joke

[Anonymous Coward]

Which ones? No really... serious question. Can you think of any titles?

Areena 1 to Areena 4, they used to work on windows machines up until windows 7.. On windows 10? Fail.

http://www.pelikulma.net/pelit/seikkailu-ja-roolipelit/areena-3/

Re: Apple compatibility is a joke

[serviscope_minor]

About 10 years ago, I visited a company that had just moved their old DOS-based control software into a VM for precisely this reason: they could install a USB RS-232 adaptor on their host and expose an emulated RS-232 device to the VM.

Some really clunky old kit requires obscure features of RS-232 that aren't all that well supported on USB-RS232 adapters. Fortunately you can buy PCIe RS232 cards which present a full UART and pass that through instead in those odd cases.

Re:Apple compatibility is a joke

[codlong]

I know a lot of people use linux, but our shop uses exclusively Apple macbook pros for developers. The system admins lobbied for it because they claim they are much easier to maintain, and OS X gives us a BSD-based system to develop on. Apple is fantastic for professional developers, not just grandma using Facebook.

Re:Apple compatibility is a joke

[Anonymous Coward]

Macs are in the home, being used for... well I'm not exactly sure what people use them for

I use a mac (both at home and at work) for web development, graphic design, and whatever administrative tasks work requires. Applications include Aptana Studio, Eclipse, MavensMate, Photoshop/Creative Suite, Microsoft Office, MySQL Workbench, and a wide variety of tools I use all work wonderfully on Macs. I'm not sure if anything I'm using is still 32 bit, but I'll be quite annoyed if I lose it...

Re:Apple compatibility is a joke

[Ol Olsoc]

Weird because we have lots of Windows XP, Win7 and Win8 Apps that fail to run under Win10. Just sayin'

This! I've always wondered what world the backwards compatible people live in. Probably using XP and only think that everything they have is forwards compatible.

It's hard to get happy about, but Windows does the same thing as Apple. It even removes apps without asking. If they pray at the altar of backwards compatibility, they should just leave the programs like WMP alone.

This isn't to excuse Apple. The High Sierra update killed my Final Cut Studio suite's Apps.

So I installed them on a Core2Duo 27 inch iMac that doesn't get upgrades any more. Its a pain in the ass to re-buy perfectly functioning software

Re:Apple compatibility is a joke

[Ol Olsoc]

You mean Apple will release an iPad Pro running OS X, As us Apple-haters have been demanding all along?! ;-)

Or even MacOS?

Re:Apple compatibility is a joke

[Ol Olsoc]

Do a diff of find / on both iOS and MacOS. It's just BSD with a pretty paint job. People pay for the paint job not the BSD.

MacOS is Unix, and, as my Linux Guru told me once, " Just think of it as the sllckest, shiniest version of Linux you've ever seen."

Noting this drives some Slashdotter Linux lovers crazy. Just watch the responses.

Re:Apple compatibility is a joke

[_merlin]

I still wish Bugdom and Deimos Rising didn't stop working, even before Apple switched to x86. Stuff gets broken by OS updates all the time.

Re: Apple compatibility is a joke

[Anonymous Coward]

Any OSX app going back to the start of the intel era still runs, so this is the first break in compatibility.

It's the first break in compatibility since they broke compatibility with PowerPC software in 10.7. So it's the first one since the last one.

However itâ(TM)s entirely reasonable , itâ(TM)s been a very long time since apples actually made a 32bit machine and weâ(TM)re talking about 12 year old software

You're a bit off there. The Intel era itself only goes back about 12 years, so even 32-bit software isn't going to be older than that. Plenty of software was slow to move to 64-bit, most notably Microsoft Office, which got a 64-bit version in 2016, less than 2 years ago. Even if you assume that Office was the last to make the switch, that leaves a decade worth of 32-bit Intel software out there, from freeware widgets to $1,000 software packages. To put that in perspective, PowerPC software for Mac OS X was only made for about 5 years. It was possible to prepare for the 64-bit change a lot sooner than the Intel switch, but that just means that it took a lot longer for it to become necessary, leaving us with a ton of legacy software.

Re:Apple compatibility is a joke

[omnichad]

Final Cut Pro 7 (the last version before X) is already incompatible with High Sierra, but it's also 32-bit. I'm going to have to keep around a machine with Sierra if I want to keep using this expensive ($999 originally) software package.

Re:Apple compatibility is a joke

[omnichad]

The High Sierra update killed my Final Cut Studio suite's Apps.

Sierra killed Motion first. I might have to buy an ancient iMac for FCP, since I don't do enough video work to buy new software - or worse, subscribe.

Re:Apple compatibility is a joke

[omnichad]

They already put an ARM chip in the latest Macbook Pros and the iMac Pro. They are already testing the waters.

Re:Apple compatibility is a joke

[omnichad]

When they do, it'll be their idea.

Re:Apple compatibility is a joke

[Anonymous Coward]

Macs are also been used in industry, but they are expensive so they don't tend to be the standard issue computer for from which the really invasive systems (order/inventory mangment, time tracking, etc.) are accessed nor the ones provided to secretaries and the like.

You're more likely to find macs in the art/design department, in IT, or on an executives desk.

Re: Apple compatibility is a joke

[the_skywise]

I killed a gopher on my lawn!

Re:Apple compatibility is a joke

[Anonymous Coward]

I don't think any 16-bit applications have worked for a while on 64-bit OS's. There are also lots of problems with anything that used very early versions DirectX (1-3 mainly).

Re:Apple compatibility is a joke

[Ol Olsoc]

The High Sierra update killed my Final Cut Studio suite's Apps.

Sierra killed Motion first. I might have to buy an ancient iMac for FCP, since I don't do enough video work to buy new software - or worse, subscribe.

Yes, that was some years ago, and I forgot. I used Motion fairly often too. My old iMac with dual core isn't a speed demon by today's standards, but fast enough.

Re:Apple compatibility is a joke

[Rob Y.]

That was my question. I have a win32 app that runs on the Mac under WINE, and I've seen no reason to port it to be Win64 code. It still works fine on Windows and Linux/WINE, and to tell the truth, requests to run it on Macs have been pretty few and far between - though it works well there under WINE too.

Are you saying a 64-bit version of WINE will retain the ability to run 32-bit windows apps - or will this mean WINE can only run 64-bit windows apps in the future? What about Parallels? Will it run 64-bit Windows and retain Windows' ability to run 32-bit apps?

Re:Apple compatibility is a joke

[omnichad]

Windows 10 is just Windows NT with a paint job or two.

Windows ME was the last legacy 9x OS that ran on top of MS-DOS.

Re:Apple compatibility is a joke

[omnichad]

And I'm sure the important thing is that it doesn't rely on any 32-bit macOS APIs.

Re: Apple compatibility is a joke

[Anonymous Coward]

I AM the gopher, coo coo ca choo.

Re: Apple compatibility is a joke

[dgatwood]

You're a bit off there. The Intel era itself only goes back about 12 years, so even 32-bit software isn't going to be older than that.

Almost 13, if you include the developer reference platform hardware. The first 64-bit 10.5 seeds were first available in June of 2007 at WWDC, IIRC, so anybody writing new apps in the past ~11 years should have been using 64-bit. So saying that 32-bit apps are 12 years old really isn't that far off.

Plenty of software was slow to move to 64-bit, most notably Microsoft Office, which got a 64-bit version in 2016, less than 2 years ago.

IMO, that's a strong indication that Microsoft has never taken the Mac platform particularly seriously. Even Adobe Photoshop has been 64-bit for almost a decade (late 2008). I can't remember the last time I encountered a 32-bit app on OS X. (I don't use MS Office.)

To put it another way:

• OS X supported 64-bit apps six years earlier than iOS did, so developers have had 6 extra years to update their Mac apps.
• Native 32-bit-only Intel Macs only existed for about 18 months, whereas 32-bit-only iPhones existed for over 6 years. So developers had only 1/4 as much time in which to write 32-bit-only Mac apps.
• 32-bit apps were dropped on iOS simultaneously with dropping support for the last hardware that wouldn't run 64-bit apps. The last 32-bit-only Mac hardware became unsupported way back in 10.7 (2011) and they're just dropping app support now.

I think they should have dropped 32-bit app support on OS X long ago, and I think they should have retained 32-bit iOS support a bit longer, because 32-bit-only iOS apps were still common when they dropped support, and 32-bit-only Intel Mac apps are almost nonexistent. In fact, Microsoft lagging behind the rest of the industry by nearly a decade is probably the only reason Apple didn't drop 32-bit support in 10.7 when they dropped support for the last 32-bit CPUs. In other words, all those extra gigabytes of libraries are basically a Microsoft tax.

Re:Apple compatibility is a joke

[Anonymous Coward]

I'm going to have to keep around a machine with Sierra if I want to keep using this expensive ($999 originally) software package.

No you don't. You just have two systems on the same machine. I have one running High Sierra (default system) and Snow Leopard (on a separate drive). The Mac has supported booting from different drives for longer than I have been a Mac user.

Re: Apple compatibility is a joke

[sydbarrett74]

Chen wrote that back in 2005. VM technology is drastically better than it was more than 12 years ago.

Re: Apple compatibility is a joke

[Hal_Porter]

I've got a Mac and I run Windows 10 in a Parallels VM. It's true that Parallels has a number of technical advances on the XP mode for Windows 7. However much of this paragraph would still apply

Since the virtual machine is running its own operating system, you can't easily share information across the virtual machine boundary. For example, suppose somebody double-clicks a .XYZ file, and the program responsible for .XYZ files is set to run in a virtual machine.

* Start the virtual machine.
* Log an appropriate user on. Hopefully, the user has an account in the virtual machine image, too. And of course the user will have to type their password in again.
* Once the system has logged the user on, transfer the file that the user double-clicked into the virtual machine's hard drive image somehow. It's possible that there are multiple files involved, all of which need to be transferred, and the identities of these bonus files might not be obvious. (Your word processor might need your spelling exceptions list, for example.)
* Run the target program with the path to the copied file as its command line argument.
* The program appears on the virtual machine operating system's taskbar, not on the main operating system's taskbar. Alt+Tab turns into a big mess.
* When the user exits the target program, the resulting file needs to be copied back to the main operating system. Good luck dealing with conflicts if somebody changed the file in the main operating system in the meanwhile.

The hassle with copying files around can be remedied by treating the main operating system's hard drive as a remote network drive in the virtual machine operating system. But that helps only the local hard drive scenario. If the user double-clicks a .XYZ file from a network server, you'll have to re-map that server in the virtual machine. In all cases, you'll have to worry about the case that the drive letter and path may have changed as a result of the mapping.

And that's just the first problem. Users will expect to be able to treat that program in the virtual machine as if it were running on the main operating system. Drag-and-drop and copy/paste need to work across the virtual machine boundary. Perhaps they get information via e-mail (and their e-mail program is running in the main operating system) and they want to paste it into the program running in the virtual machine. International keyboard settings wouldn't be synchronized; changing between the English and German keyboards by tapping Ctrl+Shift in the main operating system would have no effect on the virtual machine keyboard.

Isolating the program in a virtual machine means that it doesn't get an accurate view of the world. If the program creates a taskbar notification icon, that icon will appear in the virtual machine's taskbar, not on the main taskbar. If the program tries to use DDE to communicate with Internet Explorer, it won't succeed because Internet Explorer is running in the main virtual machine. And woe unto a program that tries to FindWindow and then SendMessage to a window running in the other operating system.

If the program uses OLE to host an embedded Excel spreadsheet, you will have to install Excel in the virtual machine operating system, and when you activate the object, Excel will run in the virtual machine rather than running in the main operating system. Which can be quite confusing if a copy of Excel is also running in the main operating system, since Excel is a single-instance program. Yet somehow you got two instances running that can't talk to each other. And running a virus checker in a virtual machine won't help keep your main operating system safe.

As has already been noted, the virtual machine approach also doesn't do anything to solve the plug-in problem. You can't run Internet Explorer in the main operating system and an Internet Explorer plug-in in a virtual machine. And since there are so many ways that programs on the desktop can in

Re: Apple compatibility is a joke

[Agripa]

About 10 years ago, I visited a company that had just moved their old DOS-based control software into a VM for precisely this reason: they could install a USB RS-232 adaptor on their host and expose an emulated RS-232 device to the VM.

Some really clunky old kit requires obscure features of RS-232 that aren't all that well supported on USB-RS232 adapters. Fortunately you can buy PCIe RS232 cards which present a full UART and pass that through instead in those odd cases.

It isn't just the lack of emulation of obscure features. I gave up on USB-RS232 adapters long ago when they could not even handle a three wire connection to my GPS. If the RS-232 is not on an expansion card with a full UART interface, then I am not interested because it is a waste of time.

Re:Apple compatibility is a joke

[Lord Flipper]

I'm not exactly sure what people use them for, Facebook or something I guess,

That your best guess? Really. Well, try these, dumbass:

Final Cut Pro

Logic Pro

And guess what? When plugin guys are too lazy and/or stupid to update their 32-bit stuff to 64 bit, they're out of the show (and post-production, also), like, immediately, no matter how crucial they think they are. Bye bye, see ya...

Oh, and I run Windows 10 Pro, and a couple versions of Linux at the same time (rarely) on the Mac, also, in that one-in-a-hundred scenario where I actually need some old thing to do some oddball operation... So, Windows isn't entirely "useless," just, not as necessary... in the production world as it might once have been. Probably great for Chrome and other google/nsa/MS spycraft bullshit, though, I'd imagine... Good luck with all that shit, sport.

Re:Apple compatibility is a joke

[wombley]

Install it in a virtual machine. Parallels Desktop Lite uses macOS's built in virtualisation and is free on the Mac App Store (as long as you don't want to install Windows), or failing that use VirtualBox. Just install the last working version of OSX and your software on it and keep it as an image, using shared folders so everything's stored on your main computer. It'll work more or less like any other app. This is how I'm still using my old Adobe CS5 suite (which REALLY doesn't like more modern macOS variants).

Re:Apple compatibility is a joke

[omnichad]

Unless there's Firewire passthrough and decent video performance, I think it would be a rough battle for video. I am using CS5.5 successfully on Sierra (though not Premiere). What happens with CS5?

Re:Apple compatibility is a joke

[wombley]

I believe Firewire is partially (mass-storage only) supported in Parallels, at least in the full version - not that I've tried it personally (I don't deal with video). I don't think video-capture devices are supported if that's what you're using (unless the host thinks its a normal camera, in which case it might).

Video performance REALLY depends on the application - some work well, others don't. This can also vary between the backend used (Lite uses builtin macOS virtualisation, the full version uses it's own, and presumably VMWare/others have different ways). Could be worth trying a couple of trial versions.

As for CS5 (which despite the name experiences rather different problems to 5.5 as far as I've seen), every macOS release has introduced new problems - first depreciation of Java, then installation problems, then odd font issues, then a variety of crashes while doing everyday tasks, etc. You can get Photoshop working OK but the other programs (particularly InDesign) are far more problematic - in the end it was far less stressful to run on a VM than deal with the quirks and crashes, with the added benefit I no longer need to worry about fixing it on OS upgrades.

Re:Apple compatibility is a joke

[omnichad]

If I had known I'd lose my chance to buy full suites ever again, I would have bought CS6. I got extremely lucky to have 5.5 over 5, I guess. If you want to see quirky, try running Photoshop CS2 on 64-bit Windows 10 with high DPI settings (zoom) turned on. The worst part is that it still sort of works, so I haven't been motivated to do anything about it.

Re: Apple compatibility is a joke

[sydbarrett74]

Thanks for your reasoned and detailed response. I should've done more homework before responding to the OP. :(

Re:Apple compatibility is a joke

[Anonymous Coward]

Microsoft backward compatibility is a worse joke because it's DIRECTLY responsible for the greater malware experienced on Windows. It's stove-piped under the hood bypassing security to assure this backward compatibility - even Microsoft doesn't know what it can safely disable! They've recently become braver by abandoning or VMing older compatibility - which is something Apple has been doing for 25 years.

Re: Apple compatibility is a joke

[serviscope_minor]

It isn't just the lack of emulation of obscure features. I gave up on USB-RS232 adapters long ago when they could not even handle a three wire connection to my GPS.

Yeah that sounds par for the course. Some decent name brand USB ones can manage the handshaking with CTR/RTS, but even then it's a crapshoot.

I'm fairly sure StarTech make decent PCIe RS232 cards. I've not tried the serial one, but the parallel one was excellent. Proper full hardware, complete with the old fashioned inb/outb access if you want it. Basically indistinguishable from one built into the motherboard.

Re: Apple compatibility is a joke

[Agripa]

I'm fairly sure StarTech make decent PCIe RS232 cards. I've not tried the serial one, but the parallel one was excellent. Proper full hardware, complete with the old fashioned inb/outb access if you want it. Basically indistinguishable from one built into the motherboard.

PCI and PCIe interface cards are plentiful so it is not much of a problem unless you want to interface to a laptop or something. Even there, you can find RS-232 Expresscard and similar cards for laptops. I keep a couple of legacy desktops for this stuff plus my main workstation has a PCI RS-232 and parallel adapter card. Originally I bought the motherboard for it *because* the documentation for it listed an RS-232 port but they left the external level shifter off. So it has one as far as the OS is concerned but it is unusable.

Re: Apple compatibility is a joke

[Anonymous Coward]

The first 64-bit 10.5 seeds were first available in June of 2007 at WWDC, IIRC, so anybody writing new apps in the past ~11 years should have been using 64-bit. So saying that 32-bit apps are 12 years old really isn't that far off.

I work in the world of requirements; a "should" is a suggestion that will be ignored whenever it is convenient to do so. Which ends up being most of the time. Until Apple announced that they would be ending 32-bit application support, it is unlikely that any developers who didn't go to 64-bit as soon as it was possible would have bothered with it unless there was a specific performance or capability benefit involved. Sure, it would have been a good idea, but the bulk of the benefit would be to users who were only benefiting because they weren't actively paying for new software or support. Hence, no business case for putting in any effort before it was absolutely necessary.

Even Adobe Photoshop has been 64-bit for almost a decade (late 2008). I can't remember the last time I encountered a 32-bit app on OS X. (I don't use MS Office.)

Funny you should mention Photoshop. While Photoshop itself has been 64-bit for a long time, many of the bits and pieces that get installed with it have not (at least as of Photoshop CS5, there's a lot of 32-bit in there).

I think they should have dropped 32-bit app support on OS X long ago, and I think they should have retained 32-bit iOS support a bit longer, because 32-bit-only iOS apps were still common when they dropped support, and 32-bit-only Intel Mac apps are almost nonexistent. In fact, Microsoft lagging behind the rest of the industry by nearly a decade is probably the only reason Apple didn't drop 32-bit support in 10.7 when they dropped support for the last 32-bit CPUs. In other words, all those extra gigabytes of libraries are basically a Microsoft tax.

One of the reasons why a sharp transition is easier with iOS is because Apple has control over the delivery mechanism for apps and there's less app use inertia to contend with. And Microsoft wasn't the only offender where the 64-bit changeover was concerned, just the most egregious. Apple itself didn't release a 64-bit version of Final Cut Pro until 2011 and that version was not well-received due to the completely redesigned interface and multitude of dropped features. Can't afford to piss off Final Cut Pro users until you can convince them to upgrade to the new version.

Re: Apple compatibility is a joke

[Anonymous Coward]

16bit apps never worked on 64bit because the CPU can't do both at the same time.

Going to be some resistance to this one

[fyngyrz]

I think it likely there's going to be a lot of resistance to this one. There are an awful lot of perfectly good apps out there where the developers have gone away - they're just not going to make the transition to 64-bit. Apple's asking a very large number of users to take a serious a hit in terms of lost investment all at once.

There's no particularly good reason for it. The existing OS support can be frozen, and new OS stuff added; it's not like we're short on memory or storage.

For some, the answer will be to simply not move to the new OS (notice I didn't use the term "upgrade.") For others, it may be a VM, unless the VM's can't run in 32-bit mode (don't know why that would be the case, but perhaps it is.)

It is Apple's habit to go with "hey, I have an idea" where for some reason, no one stands up and tells them "you know, that's not a good idea..." They did it with the PPC emulation, they did it with headphone jacks, they did it with slowing down people's phones, and now... now they're going to kill a lot of people's tools.

Interesting times for Apple.

Re:Going to be some resistance to this one

[msauve]

Bend over and take it.

Macs haven't run my 68K apps for years. 8088 MS-DOS 3.1 batch files still (mostly) work in Windoze, though.

Re:Going to be some resistance to this one

[sit1963nz]

What the hell are you talking about ????

If you do not move to the new OS, all you existing Apps will work just fine, there is no "hit"

You do NOT have to move, you do NOT have to upgrade, these choices are 100% the end users. Version 13.4 of OSX will simply be warning you in advance that OSX 14 will no longer support 32 bit Apps. You can then either choose to stay on 13 and get support for another couple of years or move to version 14 and upgrade your Apps.
Apple is not going to kill anyones tools, they will continue to function tomorrow just as they did today.

For example my old iPad still works today even though Apple no longer supplies updates for it. It is stuck at IOS 9.
Bento on it however works fine and is still useful.

Re:Going to be some resistance to this one

[Anonymous Coward]

If only there were some way to stop Apple from the constant daily nags to upgrade to their latest defective crap. They torture you as punishment for not running YOUR computer THEIR way.

FUCK APPLE AND FUCK TIM COOK.

Re: Going to be some resistance to this one

[Anonymous Coward]

Yup kinda a stupid move for a company that has potential to really increase its share of the computer world. The blantent spyware and key logging built into windows 10 and no regard for privacy of anyone using windows give Apple an opportunity that they seem to be missing. Alienating is uses is a bad move if I go to iOS 11 I loses about 50 apps that have not been converted to 64 bit including some very expensive ones like garmin's street pilot so I am stuck on iOS 10. iOS 11 and the bugs and awful control center where you can't even turn off Bluetooth or wifi is bad enough but loosing so many apps is unacceptable. I guess I am stuck on sierra forever too.

Re:Going to be some resistance to this one

[Immerman]

Having developed on both platforms (addmitedly only some on Apple), I have to say that Apple has a tendency to add a lot of little "programmer shinies" with every new update - handy new utilities, programming features, etc. that tempt developers to use them. Which then makes their software incompatible with older versions of the OS. So, if you want to keep running the latest versions of all your modern apps you pretty much need a fairly recent version of the OS.

Contrast that with Microsoft, whose "go suck it" attitude to developers, and tendency to try to replace old, reliable components with newer, more annoying ways of doing things, combined with their commitment to maintaining backwards compatibility, means that developers tend to stick with the old tried-and-true standbys, unless there's some compelling reason to move forward (e.g. powerful new features added in DirectX 10 and 11).

Apple's approach does a lot more to create a constantly improving programming environment (or at least the impression of one), but also keeps their users on a more vigorous upgrade treadmill.

That said - at this point I suspect most 32 bit-only Apple software can probably run in an "emulated" compatibility layer with plenty of performance, much as older XP apps can do on modern windows. But such compatibility is always imperfect, hence "will be the last macOS release to support 32-bit apps without compromise."

Re: Going to be some resistance to this one

[Anonymous Coward]

Tim Cock loves to be fucked in her stupid butthole.
Therefore, prepare for more stupid shit like this.

Re:Going to be some resistance to this one

[Anonymous Coward]

I don't think you have any idea what you're talking about. And your screed and rant against Apple appears to be based on your own biases instead of facts.

There is no reason to be discussing headphone jacks in a post about 32/64 bit apps. Pretty clear you just posted to rave on about Apple.

Re:Going to be some resistance to this one

[Anonymous Coward]

I think it likely there's going to be a lot of resistance to this one. There are an awful lot of perfectly good apps out there where the developers have gone away

Can you name them, along with the number of people who are using them?

Re: Going to be some resistance to this one

[Anonymous Coward]

Apple doesn't give a rat's ass about market share. If the armies of hipsters buy their iPhone every year (and they do, as every device Apple sells always hits record levels), then for all Apple cares, Macs can wind up being completely neglected. In fact, the only reason Apple has likely even kept the Mac platform is that it is must have platform for iOS developers, and it is order of magnitudes more secure than Windows.

Re:Going to be some resistance to this one

[sit1963nz]

There is a way reading this

http://osxdaily.com/2018/01/22...

Re:Going to be some resistance to this one

[Anonymous Coward]

Dang dude. Jobs is dead. You can't suck his cock anymore.

Re:Going to be some resistance to this one

[Anonymous Coward]

> There's no particularly good reason for it. The existing OS support can be frozen, and new OS stuff added; it's not like we're short on memory or storage.

Good luck with that.

Apple has no concept of backwards compatibility here. There is no way to run 10.6 specific software on 10.13, unless enough of the APIs happen to align well enough that the whole thing miraculously still runs. They don't have any sort of a versioned library subsystem where you can state that "I need the 10.6 version of Cocoa" and have the OS provide that to you, which is because OS X as a whole is so tightly coupled together with itself that you literally cannot have multiple versions of Cocoa sitting on the same machine.

They don't even provide different SDKs for different operating systems anymore. If you want to target an older OS, you're compiling against the latest SDK for the latest operating system under Xcode- it's just that all the APIs are marked with macros as either being depreciated or requiring a specific version of the API before they'll work (so you get warnings or errors at compile time). That means that software which was compiled for, say, 10.9, and running on 10.13 is literally only working because the libraries are similar enough that they haven't broken backwards compatibility (yet).

So you can throw all the memory and storage you want at the problem- it's not going to change the fundamental fact that OS X isn't very well suited for backwards compatibility. Even Rosetta only worked because it was able to dynamically translate PowerPC instructions into the equivalent x86 instructions. There were no PowerPC libraries lying around on Snow Leopard- Rosetta (aka QuickTransit) was literally translating all those calls into their equivalent x86 versions, and executing them natively on the host CPU. Rosetta had to be dropped because the x86 versions of those libraries began to diverge too radically from their PowerPC equivalents, thus preventing the software from operating correctly.

Re:Going to be some resistance to this one

[Anonymous Coward]

MacOS has had 64bit support since Leopard (2007) and Apple recommended 64bit for all applications since Snow Leopard (2009). I just checked and all my apps are 64bt including the oldest from 2011. As a developer myself, I have been targeting 64bit for 8 years.

Re:Going to be some resistance to this one

[Anonymous Coward]

Oh yes, those shiny features like a re-written PDFKit that was a subset of the old implementation and broke all software that depended on it. Good Times.

Re:Going to be some resistance to this one

[not flu]

>You do NOT have to move If this were true I would still be on 10.6, back when the OS was reliable and all this annoying crap hadn't been added yet. At some point you stop getting security updates and homebrew stops working. Staying behind more than a couple of versions is unfortunately not feasible for internet-connected devices.

Re:Going to be some resistance to this one

[antifoidulus]

Apple also has no qualms about promoting the crap out of something, then if it doesn't stick quickly deprecating and removing it, which can mean often times having to re-write entire apps because you bought into the Apple hype about a particular framework and it being the "future" of that kind of dev on mac. I ported a bunch of legacy stuff to Apple's "new" video editing/playback framework(whose name escapes me, this was a while back) only to have that framework totally scrapped and a completely new one put in its place.

Re:Going to be some resistance to this one

[Anonymous Coward]

If you choose not to update, eventually you get into a situation where there is newer software which you need (or just want) to run that won't run on your old system. At that point, you have to make the choice of having two systems (maybe one a VM, but hard to do with MacOS) or not using one or another piece of software. Neither is ideal. That's why it is nice to have long-term backward compatibility in an OS.

I still use Photoshop CS3 and Aperture. I don't want to upgrade because it costs $$$ (for photoshop) and time (for migrating in the case of Aperture) and the software does what I need it to do. One day, this will fail. I will be forced to either keep an older machine around or do the migration. I am not looking forward to that day.

Re:Going to be some resistance to this one

[TheRaven64]

I had a look, and there are only 2 32-bit apps on my macOS system currently running. One is the Android File Transfer thing, which can probably work in 64-bit mode without too much effort. The other is WINE, which is likely to be more effort because it will still need to run 32-bit PE/COFF binaries and handle transition to and from 32-bit mode.

Re:Going to be some resistance to this one

[TheRaven64]

They don't have any sort of a versioned library subsystem where you can state that "I need the 10.6 version of Cocoa" and have the OS provide that to you, which is because OS X as a whole is so tightly coupled together with itself that you literally cannot have multiple versions of Cocoa sitting on the same machine.

This is so laughably untrue that I don't know where to start.

First, the OPENSTEP bundle format that Apple inherited from NeXT includes a concept of versioning in the loader. You can link either to the latest version of a framework, or explicitly to an older one, and you can ship multiple library binaries for different versions in the same framework, with the linker correctly finding the right one.

Second, each Mac application embeds a MacOS deployment target, which will put some APIs into compatibility modes if you invoke them on a newer system.

Third, all of the Apple headers include annotations about which versions of each of their operating systems introduced, deprecated, and removed APIs, so you can explicitly target older versions and get compiler errors if you use a newer API. I'm not sure why you think it's better for them to provide copies of older headers instead of doing this.

Fourth, a bunch of the APIs include constants that tell specific subsystems about the expected version. For example, each time they improve the line-breaking algorithm in the text layout engine, they bump an enum value so that code compiled with an older deployment target, or code that explicitly opts into the older behaviour for compatibility, will get the old behaviour.

Re: Going to be some resistance to this one

[Anonymous Coward]

Nope. No resistance at all. In fact pretty soon you will see Apple fanbois expounding on how itâ(TM)s such a good thing that Apple doesnâ(TM)t allow older apps to run anymore. I mean, can you imagine how much it would damage the aesthetic of the experience to allow such an old program to run along side modern ones?

Iâ(TM)m surprised Apple isnâ(TM)t charging them for this.

Re:Going to be some resistance to this one

[Anonymous Coward]

No, you have to suck his Cook instead.

Re:Going to be some resistance to this one

[Anonymous Coward]

Ever argue with an Apple fanatic over the headphone jack thing? "But you have to remember to bring a dongle to use regular headphones" Fanatic: "So what, you have to remember to bring your headphones anyway". "But you have to charge your wireless headphones all the time" Fanatic: "So what, you have to charge your phone anyway".

Re:Going to be some resistance to this one

[Mordaximus]

I think it likely there's going to be a lot of resistance to this one. There are an awful lot of perfectly good apps out there where the developers have gone away - they're just not going to make the transition to 64-bit. Apple's asking a very large number of users to take a serious a hit in terms of lost investment all at once.

The way I see it, if it's a great app that been abandoned, this is a great time for developers to modernize them. If there are apps out there that are laden with patents/copyrights and can't be modernized... there's always virtual machines, which may be a better place for these apps to live.

Re:Going to be some resistance to this one

[SoulRider]

https://discussions.apple.com/thread/8181588

Re:Going to be some resistance to this one

[angel'o'sphere]

A MS-DOS batch file is a text file ... obviously it runs on modern windows.

Posts like this show how less clue you have about computers ...

Re:Going to be some resistance to this one

[Immerman]

Where do you see any support for Jobs? I always disliked him and consider his "look at the shinies" brand of evil preferable only to Microsoft's mafia-esque behavior. And used Windows anyways because that's where all the decent software was, and Macs were way too focused on shiny at the expense of interface functionality.

Re:Going to be some resistance to this one

[Ol Olsoc]

I think it likely there's going to be a lot of resistance to this one. There are an awful lot of perfectly good apps out there where the developers have gone away - they're just not going to make the transition to 64-bit.

Which ones are those? I'm not trying to be a smartass - I'm genuinely curious. I can't recall the last time I used a 32 bit Mac Application.

Apple's asking a very large number of users to take a serious a hit in terms of lost investment all at once.

True, and not true. At this time, a warning is issued that it will eventually not work. Now the true part isn't related to 32 versus 64 bit. When I upgraded to High Sierra, it killed my Final Cut Studio install. Not wanting to spend the bucks for an already functioning software that got botched, I had a Core2Duo iMac sitting around that now runs Final Cut Studio.

Then I tried installing Visual Studio on my new W10 laptop. Nope, won't work. So it will go on my W7 bootcamp install.

Fact is neither Microsoft, nor Apple are going to support a lot of old software, Someone might crippledick together some 1980's DOS games and claim 100 percent backwards compatibility, but I've got some rather expensive software that doesn't run at a couple Operating systems back.

Re:Going to be some resistance to this one

[Ol Olsoc]

Bend over and take it. Macs haven't run my 68K apps for years. 8088 MS-DOS 3.1 batch files still (mostly) work in Windoze, though.

Let me tell you about my copy of Visual Studio 2005 that will not work on W10. But at let you have those mostly working files.

Re: Going to be some resistance to this one

[Anonymous Coward]

Until ones existing hardware fails. Then the option is hunt for working used equivalent hardware or buy new hardware which due to OS support restrictions will not natively run 32 bit applications. A VM might be an option depending on the application but is definitely not an optimal solution. Having run VMs for coming up on 20 years across a variety of hardware and platforms, running applications natively is superior. VMs provide a great deal of flexibilty but are not always TheAnswer(TM).

Re:Going to be some resistance to this one

[msauve]

A batch file is a program. That's it's in human readable ASCII text has no bearing on that. Perhaps you're familiar with JavaScript? That's "just a text file," too.

More specific to my OP - for a while, Apple included a PPC to x86 translator to allow applications compiled for PPC to run on x86. They dropped that too, deliberately breaking backward compatibility. Apple has a short attention span and doesn't give a shit about protecting their customer's investments. (see: recent deliberate slowing of older iPhones)

Re:Going to be some resistance to this one

[Ol Olsoc]

What the hell are you talking about ???? If you do not move to the new OS, all you existing Apps will work just fine, there is no "hit" You do NOT have to move, you do NOT have to upgrade, these choices are 100% the end users.

To be certain, I didn't see any warnings when High Sierra nuked my Final Cut Studio.

I would have taken the day's loss effort to go back to the previous OS, but I had an older Mac that isn't supported any more, so I just installed the programs on that.

But this is the bigger issue to me, not ancient MS-DOS batch files or 68K programs. Having been bit both on the Mac end and the Windows end, it's just screwed up that perfectly functional ad expensive software gets cast aside.

Re:Going to be some resistance to this one

[angel'o'sphere]

If you don't behave loke an idiot in the internet, the OS version has not much to say.
My 17" runs happily on 10.6.8.

Re:Going to be some resistance to this one

[Anonymous Coward]

Well, lucky you. I've got lots of 32-bit apps, from one-off video tools to Adobe and Microsoft products. Replacing all of that functionality will not be easy or cheap. Looks like 10.13 is the end for my 2010 MacBook Pro. Probably won't be able to get much more than another decade out of it, maybe Apple will have a suitable replacement for it by then.

Re:Going to be some resistance to this one

[angel'o'sphere]

A batch file is a program. That's it's in human readable ASCII text has no bearing on that.
Comments like this show how much clue you have about the working of computers ...
A human readable text filed does not (need to) know if the kernal is 32bit or 64bit ... go figure.

Re:Going to be some resistance to this one

[msauve]

No, just whether it's ASCII, EBCDIC, UTF-8, UTF-16, or UTF-32 (and a whole bunch of others). Once you get through CS101, you'll understand.

Re:Going to be some resistance to this one

[angel'o'sphere]

We nave no CS 101 in my country :) And I doubt CS 101 in your ccountry covers EBCDIC etc.

And yet again: no, the text filed does not (need to) know if it ASCII or any other format. The interpreter needs to know ...
And now stop this farce.

Re:Going to be some resistance to this one

[msauve]

Why do you believe that files are self-aware? Is this part of your religion?

Re:Going to be some resistance to this one

[angel'o'sphere]

You said so ... or do I remember wrong?
As an atheist, I have no religion. And before you start nitpicking again: no, Atheism is no religion.

Re:Going to be some resistance to this one

[msauve]

*plonk*

Re:Going to be some resistance to this one

[Norin Radd]

I'm afraid that my opinion is that apps whose developers have "gone away" is the exact opposite of a "perfectly good app(s)" ... it's a liability that only grows over time. Keeping those abandonware apps running in VMs is a perfectly good solution, if only Apple wasn't so opposed to supporting VMs.
This is just as radical as any other API change. And Apple closing the door on 32-bit should surprise no-one at this point. Software development is a treadmill, not a monument.

Re:Going to be some resistance to this one

[Anonymous Coward]

I just checked and I have 300 32-bit applications. The bulk of them are odds and ends from MS Office, Final Cut Pro, or Photoshop, but there are still a lot of useful tools in there, several of which either have yet to release a 64-bit version or are no longer in development. Unless you've been actively purging everything 32-bit, I can't imagine you don't have a few offenders hiding in some dark corner somewhere.

Re:Going to be some resistance to this one

[Immerman]

Yep, that's the impression I got - one of the reasons I didn't stay long - I'd rather spend most my time making new and useful tools than constantly learning how to use the new tools in my toolbox, even if they really are superior to the old ones.

Still, they've obviously got enough of a developer base willing to jump through those hoops to let them get away with it, and it's probably letting them evolve much faster than they otherwise would. Almost Linux-like in a way, with new better technologies constantly replacing old ones to the frustration of many - only controlled by a single golden fist instead of an ecosystem of distros. I kind of suspect they have a lot more developers for their platform than any Linux stack though. Maybe even more good ones.

Re:Going to be some resistance to this one

[Anonymous Coward]

Why are you so stupid?

The text file is irrelevant, it is read in by an actual program. Why would it care when the text file was written as long as it is still valid?

That has zero bearing on whatever bit system that program was compiled to.

numbnuts

32-Bit is like what 16-Bit was in the late 90s

[Anonymous Coward]

32-Bit is now getting the boot just like when 16-Bit got the boot in the late 1990s like when 8-Bit got the boot in the 1980s.

No more support (or unenthusiastic) for 32 bit computers even from Linux so forget about using those old Pentium 4 computers to run some little task. Buh-Bye.

Of course, there will come a time in the not-so-distant future when 64-Bit computers will get the cold shoulder.

Re:32-Bit is like what 16-Bit was in the late 90s

[Zontar The Mindless]

Of course, there will come a time in the not-so-distant future when 64-Bit computers will get the cold shoulder.

Probably not in your lifetime.

Re:32-Bit is like what 16-Bit was in the late 90s

[Anonymous Coward]

Why the hell would you use a P4 to run some little task? Those things consume so much power and run so hot. At least use a Core/Core2 or go back a step to the P3s. The P4 was a rushed to market abomination because AMD was kicking Intel's ass with their Athlons at the time.

You can even see how much Intel though it sucked because "NetBurst" technology disappeared in the Core/Core2 processors. The Core processors are more related to the P3 than the P4

Re: 32-Bit is like what 16-Bit was in the late 90s

[Anonymous Coward]

Wrong, this isn't about hardware. x64 can run 32 bit code just fine.
Fags at crapple want you to stop doing that.
Fags don't care that some of the most useful tools and apps won't be updated because devs have moved on.

Re:32-Bit is like what 16-Bit was in the late 90s

[DontBeAMoran]

As far as I understand it, the Core processors are more related to the Pentium M.

Re:32-Bit is like what 16-Bit was in the late 90s

[Immerman]

>Of course, there will come a time in the not-so-distant future when 64-Bit computers will get the cold shoulder.

You think? I'm not so sure. Or, at least it will take a lot longer than previous transitions.

The driving force behind bit-size increases seems to be RAM - vector processors (aka GPUs these days) and other SIMD techniques address performance issues quite sufficiently, and there's very little call for calculations to be performed more precisely than can be done in 32 bits, much less 64 (neglecting limited demand for exact calculations, which will always need to be implemented in software)

32 bit computers had been flirting with their limitations for a while - 32 bit addresses can only access 4 GB of RAM without all sorts of performance-killing jumping through hoops (pointer arithmetic is fundamental to almost everything). And unlike 16 bit computers (which can only natively address 64kB of RAM and required hoop-jumping from day one on PCs), 32 bit OSes were born in the time of the 386, when a couple MB of RAM was impressive, and 4GB was an unimaginably insane amount, so new OSes could get the performance benefit of assuming all RAM was directly addressable, with vast ranges of "this will never be used" address space that could be allocated to various non-RAM purposes (hence only being able to use ~3.5GB of your 4GB of RAM on Windows XP).

64-bit computers though are a far larger jump again. Going from the 286 (16 bit calculations, 24 bit addresses through "protected mode") to the 386 (32 bit native addresses) only introduced an extra 8 address bits - 256x times the space, from 16 MB to 4GB, or about 16 years by Moore's Law at the time. Going from 32 to 64 bits adds about 4 billion times the natively computable address space - or about 48 years by the modern accelerated Moore's Law. Meanwhile, actual uses for more memory seem to finally be slowing down - over a decade since Microsoft introduced a mainstream 64-bit OS, there's still not really much to be gained by most people having more than 8GB of RAM in a PC.

Re:32-Bit is like what 16-Bit was in the late 90s

[Anonymous Coward]

Pentium M was a laptop friendly version of the Pentium III. The Pentium 4 was built for clock speed, because higher clock speeds sold more processors at the time, remember those days?. It was a GHz race with AMD after AMD was first to roll out a 1GHz CPU with the Athlon, the PIII was pretty well tapped out for clock speeds at that point - they started out at 450MHz.

Core processors were a move back to reality where performance per watt started to matter because desktops were out, and laptops were in.

Re:32-Bit is like what 16-Bit was in the late 90s

[Anonymous Coward]

There were a few rare 100MHz Bus 1400MHz P3s back in the day. You had to use a Sloket to adapt it from S370 to Slot1. They were primarily intended for the server market, but would run fine in a good old 440BX chipset board. I bought one of those. If I remember correctly they whipped the ass of even a 2Ghz clocked P4

Re: 32-Bit is like what 16-Bit was in the late 90s

[Dog-Cow]

Only a fucked-up anonymous shit head would consider it a problem to just not update your OS if you need it to run your apps.

Re:32-Bit is like what 16-Bit was in the late 90s

[Hal_Porter]

64 bit was very necessary for desktop and server OSs but it wasn't necessary for mobile. But it happened anyway.

Now I don't think even Apple are going announce a "brave" move a "128 bit iPhone" in a keynote where Tim Cook does his best to dress up and sound like Steve Jobs. But it wouldn't surprise me if we see some other change that breaks binary compatibility. Hell look at Meltdown and Spectre. A new ABI which makes exploits like that impossible seems very likely. There are some very interesting Intel papers on things like Control Flow Enforcement which point to a binary compatibility break to work. E.g.

https://www.theregister.co.uk/...

CET works by introducing a shadow stack - which only contains return addresses, is held in system RAM, and is protected by the CPU's memory management unit. When a subroutine is called, the return address is stashed on the thread's stack, as per normal, and also in the shadow stack. When the processor reaches a return instruction, the processor ensures the return address on the thread stack matches the address on the shadow stack.

If they don't match, then an exception is raised, allowing the operating system to catch and stop execution. Therefore, if exploit code starts tampering with the stack to chain together malicious instructions to install malware or otherwise compromise a system, these alterations will be detected and the infiltration halted before any damage can be done.

The shadow stack must sit in memory that has a new shadow stack bit set in the page tables. Any attempts by software to access the shadow stack - such as with a MOV instruction - are blocked by the memory management unit and a page fault raised to alert the operating system that shenanigans are afoot. Any attempt to use a control-flow instruction - such as RET - when the shadow stack is not marked as a shadow stack in the page tables will also raise a page fault.

The shadow stack pointer (SSP) for the running thread is stored in the Task state segment. There are various control registers that hold SSPs for privilege rings 0 to 2 (non-usermode rings) and for interrupts. You should really read the above PDF if you're interested in the detail - this is really only scratching the surface.

For this sort of thing to work it must be done everywhere in the OS and applications and all the old insecure applications need to be EXTERMINATED in order to prevent them from tarnishing ze purity of the race, err security of the system.

In fact you might see several binary compatibility breaks as new security features are added and support for applications which weren't compiled to use them is dropped.

Re:32-Bit is like what 16-Bit was in the late 90s

[Anonymous Coward]

sadly there are some pricks requiring SSE2 for their software.
.

Re: 32-Bit is like what 16-Bit was in the late 90s

[Anonymous Coward]

Most people want to access the Internet.
And desktop computers don't change that much anymore, a 15-year-old one still works, for real.

So your plan is to buy a $2000 Mac ; have an unsupported OS after two years, no more security patches ; and then do what with it exactly for the following ten years?

(use a VM, or only use linux.. but that's not what you're saying)
Worse, if you run software with a subscription or mandatory user account etc., that won't work with a computer you're trying to use 100% off-line like in the nineties (or earlys 00s)

Re: 32-Bit is like what 16-Bit was in the late 90s

[Anonymous Coward]

i think 8bit computers can access 64kb.
16bit can do more

Re:32-Bit is like what 16-Bit was in the late 90s

[TheRaven64]

The Pentium M was basically the Pentium 3 with the branch predictor from the Pentium 4 and a few refinements.

Re:32-Bit is like what 16-Bit was in the late 90s

[TheRaven64]

It's worth noting that the failure of the P4 was to do with the fact that Intel (very unusually) mispredicted process improvements. The team running P4 development was expecting 5GHz at launch and 10GHz after a couple of years. Their designs worked at those speeds in the simulators, but the process technology didn't give the faster clocks that they expected. At 5GHz, the P4 would have smoked the Athlon for performance and at 10GHz it would have been incredible, but Intel hit an unexpected brick wall and never made it past 4GHz.

Re:32-Bit is like what 16-Bit was in the late 90s

[Anonymous Coward]

No more support (or unenthusiastic) for 32 bit computers even from Linux

There are still loads of Linux distros with 32-bit versions. I'm pretty sure it'll be at least 10 years before it's impossible to get a supported 32-bit distro - and then you can still run unsupported.

Re: 32-Bit is like what 16-Bit was in the late 90s

[Anonymous Coward]

i think 8bit computers can access 64kb.
16bit can do more

I think you're confusing the data bus size and the address bus size.
8 bit can only count up to 256, where 16 bit can only count up to 65536

When someone says an "8 bit CPU" they are referring to the data bus typically.

For example the 6502 CPU, in the Apple2's and NES and tons of systems from that time, it has an 8 bit data bus but a 16 bit address bus.

That is why they can only address 64kB of memory space, the difference being it deals with 8 bit bytes at each memory location.

When someone says a "16 bit CPU", that means they are dealing with 16 bit values on the data bus.
The amount of memory a 16 bit CPU can have totally depends on the address bus, which isn't implied in the name.

The Intel 8008 for example is an 8 bit CPU, thus 8 bit data bus, but has a 14 bit address bus and so can only use 16kB of memory space directly.
The 8080 was also an 8 bit CPU but had a full 16 bit address bus able to access 64kB of memory.
The 286 was their 16 bit CPU, but had a 24 bit address bus, which can count up to 16 megabytes.

Re:32-Bit is like what 16-Bit was in the late 90s

[Megane]

Pshhh, FORTH was doing the two-stacks thing back in the '80s. It just happened to be ahead of the rest of the world, since there were very few microprocessors that could support it efficiently. The main one was the 6809, which had two explicit stack pointers, and the U stack was almost as easy to use as the regular S stack. The FORTH inner loop was two instructions on the 6809, compared to 20 or so for the Z-80.

Re:32-Bit is like what 16-Bit was in the late 90s

[Megane]

At 5GHz, the P4 would have smoked

I think you can stop right there.

Re: 32-Bit is like what 16-Bit was in the late 90s

[Megane]

Somewhere I have an actual Intel data book where they call the 8088 an 8-bit processor, and include benchmarks that compare it to the Z80 and 6809.

Re:32-Bit is like what 16-Bit was in the late 90s

[Hal_Porter]

There's nothing to stop you having more than one stack. MIPS chips don't have a hardware stack at all - you just have a bunch of registers and you do operations on them. The ABI defines one register as a stack but it could easily define another. Or it could define several.

Still even on MIPS having two stacks is a breaking ABI change.

On Intel they've added new register and new instructions. And it seems like once you enable CET you can't run non CET code. I.e. it's a like the switch from x86 mode to x64 where you can't run old code - everything needs to be recompiled. In the CET paper they have a bitmap to mark 4K code pages as either CET or 'legacy code'

3.6.1 Legacy Code Page Bitmap Format

The legacy code page bitmap is a flat bitmap whose linear address is pointed to by the EB_LEG_BITMAP_BASE.
Each bit in the bitmap represents a 4K page in linear memory. If the bit is 1 it indicates that
the corresponding code page is a legacy code page; else it is a CET-enabled code page.
The processor uses the linear address of the instruction to which legacy transfer was attempted to lookup the bitmap. Bits of the linear address used as index in the bitmap are as follows.

They have to have that because you can't in general execute legacy code once CET is enabled because legacy code might innocently break the CET rules it doesn't know about. E.g. all indirect branches have to end at an ENDBRANCH instruction

http://www.securityweek.com/in...

Additionally, Patel explains that a new instruction was added to ISA, namely the ENDBRANCH instruction, which would mark legal target for an indirect branch or jump. âoeThus if ENDBRANCH is not target of indirect branch or jump, the CPU generates an exception indicating unintended or malicious operation. This specific instruction has been implemented as NOP on current Intel processors for backwards compatibility (similar to several MPX instructions) and pre-enabling of software,â he notes.

Actually if you're going to do that you could enforce code signing for usermode too - the OS could verify the signature when it loaded the executable and would page code into memory it subsequently marked read only.

Kernel mode code has always been signed in 64 bit windows - they knew the switch from x86 to x64 was a breaking change so they decided to enforce that too.

Windows S will only run Win32 code if it is signed by Microsoft and they use that to stop any third party applications. Maybe they could have a more open system which still enforces code signing.

It'd suck for WIn32 developers because they'd need to pay for a certificate like you do for kernel mode code.

Re:32-Bit is like what 16-Bit was in the late 90s

[Anonymous Coward]

there's still not really much to be gained by most people having more than 8GB of RAM in a PC.

... well yeah, as long as you aren't running anything else at the same time as Chrome.

Nope. Don't you remember PowerPC?

[Anonymous Coward]

Perfectly good "apps"? Ha! How about perfectly good HARDWARE.

Apple didn't care about leaving PowerPC users in the dust, and they sure as hell won't give a shit about 32-bitters.

Even Linux distros are giving up on 32-bit machines. People are lazy, and they cannot be bothered to think about machines which they do not have; most developers don't have 32-bit machines anymore. The same problem happened with the Linux kernel; it became really clear when all of the devs switched to multi-core systems, because they kept breaking the single-core code paths.

Re:Nope. Don't you remember PowerPC?

[Wrath0fb0b]

This attitude makes no sense. Sure it's "perfectly good hardware", but it costs real time and effort to keep updating* it. As time goes on and the PGH becomes rarer and rarer, the ratio of benefit from keeping support relative to spending that effort on something else becomes less and less favorable. Eventually, even if the hardware is perfectly good, it doesn't make sense to continue to support upgrading it because so few remain.

It's also incredibly rude to people that volunteer their support to build a free kernel to suggest they are "lazy" for not supporting your Pentium III. The whole of Linux is their gift to you, and you can continue running the existing kernel on it as long as you like, but instead you have to insult a gift horse in the mouth over it?

* Note that much of this support cost is probably QA. You can't just ship it because you'll end up like Microsoft where everyone was pissed at them recently for bricking some old AM2-based system that they claimed to support.

Re: Nope. Don't you remember PowerPC?

[0xdeaddead]

I used to think the same thing, but then I out a 2006 Mac pro vs a 2005 Quad G5. The Intel cpu is way cooler, and faster. Be the G5 was a crap processor. It was good to jump out of PowerPC, but yeah it's a joke how quickly they killed OS X on PowerPC.

But the real truth is that iPod, and the iPhone, and iPad sell a hell of a lot more than any Mac.

Apple computers are effectively dead.

Re: Nope. Don't you remember PowerPC?

[Anonymous Coward]

Not until software development finds a new platform. Look inside most tech companies and the coding is being done on Macs because its Unix under the hood and Windows is a shitty experience from an end user point of view through to the administration and deployment of Windows. And what's in most data-centers? Linux.

The reality has become that macOS is the client, and Linux is the server. The only Windows shit we keep around is for Active Directory and Exchange.

Re: Nope. Don't you remember PowerPC?

[TheRaven64]

I remember realising how much faster the Core 2 Duo was than the G4 when I noticed that VLC was using a little bit more CPU in Activity Monitor on my new MacBook Pro than on my old PowerBook: almost 80% of one core, when it had been closer to 60% (of the only core) on the old machine playing the same video. Then I realised that VLC wasn't a fat binary and I was still running the PowerPC version: even CPU-bound applications running in emulation were only slightly slower in the new machine. Switching to the Intel version of VLC dropped the CPU usage down to 10-20%.

Re: Nope. Don't you remember PowerPC?

[tepples]

Look inside most tech companies and the coding is being done on Macs because its Unix under the hood and Windows is a shitty experience

I have a simpler explanation for use of Macs in client software development: Xcode is Mac-exclusive and the only way to build, test, and ship iOS apps. If only Android apps and server apps were needed, more developers might use GNU/Linux.

Re: Nope. Don't you remember PowerPC?

[Ol Olsoc]

Apple computers are effectively dead.

People write those applications on their iPhones? The idea that no one produces, only consumes, makes as much sense as the old "Everyone will be a boss" concept.

Re: Nope. Don't you remember PowerPC?

[angel'o'sphere]

I used to play Diablo 2 in emulated mode. Just don't remember if I played the 68k version on my G4 17"
Or if I played the PPC version on my first Intel, lol.

Re: Nope. Don't you remember PowerPC?

[TheRaven64]

If you haven't looked recently, they released an updated version of the installer a couple of years back. I was pleased to discover a couple of years ago that I could enter my CD keys into Blizzard's web site and download an installer that ran D2 + LoD on my Intel Mac on a recent macOS. Unfortunately, it looks as if it's a 32-bit binary, so it may not work for much longer...

How the hell am I supposed to

[tgibson]

do anything useful using only numbers larger than 2,147,483,647?

Re:How the hell am I supposed to

[Immerman]

Hey man, the new OS is 64 bit, not 33 - you can only use numbers greater than 9,223,372,036,854,775,807.

Linux distros still run 32 bit apps. Firefox was

[Joe_Dragon]

Linux distros still run 32 bit apps. Firefox was 32 bit only (main line builds) for a long time.

ineptoids are stuck @ pre-1996 levels

[Anonymous Coward]

Fact: 64-bit processors and 64-bit OS's have been available since late 1992. 25 Years (Alpha - been there, worked on that in 1992). If you are writing application code that is not working for 64-bit platforms 25 years later, your company both: is inept at engineering, and deserves to die due to inept market tracking.
Linux on Alpha (64-bit) was working at about 1.3.5x ish (1995/1996)

Re:ineptoids are stuck @ pre-1996 levels

[quetwo]

Well, considering Macs didn't start shipping 64-bit processors until 2008, and didn't fully support it in the OS until 2010, I don't know if I'd call them inept. Actively maintained and sold software isn't the issue, but software that may only be 8 years old certainly is. People who bought some Adobe software for major dollars 7 years ago and haven't jumped onto the subscription model since are going to be the ones who are screwed. 8 years is a long time ago, yet a short time ago as well.

Re:Corrected headline:

[Anonymous Coward]

"Apple Prepares MacOS Users For Anal Ramming"

It this what ARkit is all about?

Bye Bye iWork '09

[Anonymous Coward]

Apple has never fixed the latest versions of Pages, Numbers and Keynote to include the features ripped out when they "upgraded" to the latest iWorks. If fact, for those who need these features, they recommend keeping a copy of iWorks '09 and using it. But it's only 32 bit software.

Apple prepares customers...

[Anonymous Coward]

"...Loyal customers - your old stuff is screwed, just buy all our new computers and software. Thanks for your money."

Been there, done that, with PowerPC, OS9 Classic, OSX Intel, etc.

Re:Corrected headline:

[Dog-Cow]

It's only correct in your mind because you are fixated on anal sex.

Slow

[dohzer]

Don't they normally do this by slowing the device down until the user upgrades?

Re:Corrected headline:

[Aighearach]

What I like about it is, there is no indication which end of the ramming the users are being prepared for. It is a very accessible phrasing for being so personal.

Steve Job's Apple is dead

[Anonymous Coward]

I remember when Intel Macs came out they made a big deal about using your old apps using Rosetta, and when PowerPC OSX came out you could use your old Apps using classic, and when PowerPC chips came out you could use old 68k apps.

Tim Cook is running a Facebook machine company, they even advertise "what's a computer"? No one will want to buy a $5000 iMac Pro now that their enterprise apps won't work. And when the millennial generation hits their 40s they will be going back to real computers.

Apps?

[Anonymous Coward]

Wait, is this about apps or is it all software? The summary is confusing on that point.

I'm not an app developer, so if it's only about apps, I don't need to worry.

UNLOCK ALL 32BIT HARDWARE

[Anonymous Coward]

Come on apple, give us source code to boot loaders, unlocked, run home brew on old 32bit iDevices?
Surely there are over 50 million iPhones+iTouches that are pure 32bit, that are working, that should NOT
be just disabled, turned into trash!

Re:UNLOCK ALL 32BIT HARDWARE

[Anonymous Coward]

they don't disable anything. My old 4 (no S) is working perfectly.

Opensource

[DrYak]

Macs haven't run my 68K {NOTE: binary} apps for years. 8088 MS-DOS 3.1 batch {text, source} files still (mostly) work in Windoze, though.

NOTE: {notes} are mine.

Which makes a great argument in favor of accessible source.
Because your batch file are human readable text-file, you can even edit what's needed to remove the "(mostly)" part of the sentence.
Much more difficult with binary 68k machine code.

If you had access to the original C / Pascal code that the 68k apps were compiled from, it would be much more easy for devs to adapts them to modern architectures/APIs.

Re:Opensource

[djrobxx]

Much more difficult with binary 68k machine code.

OK, but you can install the 32 bit version of Windows 10, and still load the GWBASIC.EXE compiled in 1986 on a current operating system.

Microsoft did away with 16 bit compatibility layer in the 64 bit OS, but as others have pointed out, VMs and things like DosBox make it not a big loss.

Mac users seem more accustomed to having old software getting obsoleted into oblivion. I don't even know how I'd go about running some PPC-era app now if it wasn't open-sourced or modernized. They had Rosetta on early Intel OSX builds. It only lasted from 10.4 through 10.6, I think about 3 years.

Quicken 2007?

[Chriscypher]

So what special exception will they make to kowtow to Intuit, who has steadfastly refused to update their Quicken 2007 locally hosted app. This 11 year old app is still used by many, and made use of Rosetta so its 68K code could run on Intel iron. When Rosetta was retired by Apple, Apple made special dispensation so that lazy intuit could still run this essential financial application on modern Mac OS with little modification, up to today under High Sierra. I have no doubt most of its code is the same 68K code from 2007.

I was an early adopter of Quicken back in 1988 and have 30 years of financial data socked away in it, and do not want all my financial transactions stored by Intuit in the cloud where they will keep it "secure". Yeah, trust Intuit. Quicken Essentials has a more limited feature set. They do not offer a true substitute, which is why so many of Intuit users have been stuck in time running an ancient release.

Re:Quicken 2007?

[Anonymous Coward]

Those financials are now over 10 years old (from 2007 edition anyway).

I guess there is little reason for Apple to support that old stuff, since the number of people who still need to access that older version of the app are probably somewhat limited. I imagine the options for such users to be thus:

a) Upgrade to modern Quicken (there is a 2018 edition available)
b) Run in a VM
c) Run inside Windows (perhaps in a VM)
d) Export the data, and import into a Quicken competitor (everyone parses Quicken format files these days) -- I imagine there are a few on the app store.
e) Export the data and import into GnuCash
f) Print the data (back to paper & ink)
g) Print the data to PDF, and store it somewhere (on a CDROM? USB? Cloud? All of the above?)

The reality is damned few people need to go back to data from more than 7 years ago -- even the IRS says 7 years is the longest you need to keep records for.

If you're still putting your *new* *critical* financial data on a program that is over a decade old, and not at least updating to a new version, then you're to blame for your own lack of foresight. Anyone these days should understand the risks therein, as it won't always be possible to run those programs on new hardware in the indefinite future. Furthermore, its easy to imagine hitting a bug where your data files get corrupted or trigger a program crash, and with such an old program you have zero chance on getting commercial support.

  (Virtualization really helps, but I suppose it might not even be the case forever that x86 32-bit virtualization options exist. But I cannot see any time in the reasonable future where you won't be able to at least load and print PDF files.)

Word to the wise

[zarmanto]

If you plan on keeping your OS up-to-date, than I would highly recommend that you keep an eye out for -- nay, even seek out -- these warning messages. I had an experience with my iPhone, which I view as a bit of foreshadowing here:

I was participating in the iOS beta program, and I pretty much ignored the iOS 10 obsolescence warnings, even though I knew better. That meant that I was essentially blazing the trail, so there were no user stories online to enable me to learn from the mistakes of other people... so when I updated to iOS 11 and all of those apps ceased to function, I actually found myself in a bit of a pickle. It was over a single app: an older "Notes" type app, dating from well before Apple's own Notes app had incorporated several of the more useful features that it now has. So this old app had a bunch of old personal notes in it, which I wanted to recover... but there was no possibility that this app was ever going to be updated for iOS 11, because it had long since been removed entirely from Apple's App Store.

Now, I'm a geek with multiple spare devices lying around, so my own little pickle was resolved -- but not exactly easily, and any number of things could have gone wrong to prevent me from succeeding: Since it too me awhile to realize what I'd lost, I first had to hunt through Time Machine to find the last iOS 10 backup of my iPhone. I then copied that into the iTunes backup repository, grabbed an older iPhone which hadn't been updated to 11 yet, used iTunes to restore the old backup to that surrogate device, and then restored the app itself from the legacy iTunes app repository, where it was (fortunately) still lurking. (I also had to do a bit of research to see if that last step was still even possible, given that Apple had already disabled app management in iTunes awhile back; thankfully, you can still simply drag-and-drop existing app backups onto your iPhone within iTunes.) After some trial and error, I was finally able to get into the app and recover all of my old notes.

So ultimately, I sort'a got lucky, because I just happened to have all of the pieces in exactly the right place to enable such a recovery. (If my iOS backups had been in the cloud instead of on my Mac, or if I hadn't been using Time Machine, or if I hadn't had an old device at hand, or if that old device hadn't had the right version of iOS on it, or if... etc, etc, ad nauseam.) So keeping all of that in mind, I have very little confidence that such a scenario would play out with similar success upon updating my Mac... and there are probably far more legacy apps there than there were on my iPhone.

So, this time around, if Apple provides some type of compatibility list for all of the legacy apps on my Mac -- as they had done in iOS 10 -- then I'll be paying quite a bit more attention to what's on that list, so that I can salvage my old data before doing so becomes a practical impossibility.

Good Example

[Anonymous Coward]

This is a pretty good example of an app and a user vulnerable to this change.

The other worrisome scenario are the careless/clueless/disconnected users or shops, who've "always used This Program in This Way." They are totally unaware of a breaking change coming down the pipe. You think that Apple's warning fixes that? No, it does not.

True story. A payroll application I supported was ending support for a specific reporting environment. This app was nearly 100% dependent on user reporting, and the vast majority of reports used an older reporting system. So the vendor announced the deprecation (responsibly, long in advance, doing all the things you'd expect and want). They also picked a version, prior to the deprecating version, and issued warning messages for every single report run that used the older technology.

Thus, an average payroll user would have been warned hundreds of times prior to the removal of the old tech. Did it help? Nope! Our users had spent roughly a year or two determinedly ignoring every such message. And it wasn't just the in-app messages either, they ignored the documentation notes, the advanced update bulletins, the release notes, all of it. They didn't want to deal with the issue and so they ignored it.

The whole thing wound up in a panic at the last minute. Our users went ballistic when they finally faced the breaking version upgrade. They actually got together, made a conference call to the vendor, and stated that they "could not possibly be expected" to cope with the tech upgrade. And it worked! They got the vendor to back down.

That was roughly 10+ years ago now. To the best of my knowledge that vendor still supports an archaic reporting technology alongside their newer technology.

They are idiots

[Anonymous Coward]

The 8088 was a 16 bit processor with an 8 bit I/O bus. The registers are 16 bit registers. AX has AH and AL 8 bit components, for example.

Re:They are idiots

[Megane]

I know all that. But this was in actual ink from Intel, which is why it was so interesting to find.

Re:Corrected headline:

[Anonymous Coward]

Yes, they use those kits in ARkansas.

Long term compatibility

[DrYak]

OK, but you can install the 32 bit version of Windows 10, and still load the GWBASIC.EXE compiled in 1986 on a current operating system.

Yup. Indeed, Microsoft (and FreeDOS. And DosBox. And dosemu) do maintain the set of API needed to get it running. (Basically, IBM-PC BIOS Interrupt call APIs, and DOS int 21h API. And an extra ton of emulated audio/video hardware in the case of DosBox).
(It helps that 3 out of the 4 mentioned software are opensource, and thus can share a bit of the workload: Indeed, dosemu uses bits from FreeDOS to provide the Int 21h MS-DOS API).

Though note again that most of the things that you will run *inside* GWBASIC.EXE are basically (pun intended) scripts with source code available. And even in the case of GWBASIC.EXE not running anymore (because in the future, tablets take over and we decide to switch away from x86/x86_64 to AArch64), you could still port them to, say, FreeBasic.

In general, it looks that the DOS legacy is so strong (and so low-cost to keep around nowadays) that we'll probably still have it around for as long as there's some hardware still able to execute real-mode x86 machine code.

You know, for that weird data acquisition machine in the corner of the lab that can't work with anything else but some weird specific executable that has DOS bits.

Microsoft did away with 16 bit compatibility layer in the 64 bit OS, but as others have pointed out, VMs and things like DosBox make it not a big loss.

Small nit-picking : for once, Microsoft is entirely innocent in this case. The culprits are AMD (who designed AMD64) and Intel (who imported it as x86_64 once they saw that IA64 is going "(t) itanic").
There is no Virtual8086 mode available when the CPU is in 64 mode. It can only execute protected mode code.
All the methods that Microsoft relied on to execute legacy real-mode code (i.e.: using virtual86 mode to handle most of the hardwork) suddenly doesn't work anymore if the CPU is in 64bits mode.

So basically they were left with two choices :
- enable 16bits APIs only when the CPU is running in 32bits mode. And disable them when in 64bits mode (what they did)
- rewrite extensively their 16 bits support to basically handle most of the emulation themselves without any assistance from the virtual86 mode. (What basically Dosbox, VirtualBox, QEMU, etc. are all doing).

The later is quite a lot of work, just to get old deprecated stuff to still run. It hits the law of "diminishing return" hard. So Microsoft skiped it. On the other hand all the other software are emulator (with additional dynarec, JIT, etc. but still) so emulation is *their* business and thus they went that path.

Nit-picking to my nit-picking :
technically a CPU in 64 bit mode is still able to run 16bit *protected mode* code. So from a purely theoretical point of view, it should be possible to get those programs that are 16 protected-mode clean (some Win16 code in the 286 era is designed to work as-is in either real mode or protected mode) to run, *IF* you take time to re-implement the whole 16bits subsystem to run as a protected 16bit software on your CPU in 64 bits mode, *AND* you make sure that these program won't rely on any real-mode code (drivers, external dependencies to weird software, etc).
That's way too much work in the scope of Microsoft - it's basically re-developing an entire Windows 286 again, just for the sake of those 3 program which will run cleanly inside it.

Mega nit-picking:
There are complicated ways to get virtual 86 mode working from within a 64 bit OS. It's DOS' "Voodoo mode / Unreal" kind of hackish - relying on virtualisation extensions to help having virtualized CPUs running in a different mode than the main os.

So basically, it could be possible to take the architecture that normally happens if, on Windows 64 bits, you use a VT-x enabled Virtual Box to ru

Good ridance

[pezezin]

I have been using a 64-bit Linux distro since I bought my first Athlon 64 almost 14 years ago. Why some software is still distributed as 32-bit mystifyies me. I'm looking at you Steam, I hate having to install a crapton of libraries just for a single program.