I was only around at Codeweavers for a part of this huge undertaking, and only contributed a small part of the 32-on-64 MacOS patchset, but I must say this was one of the most impressive feats I've seen coordinated using mainly nothing but email and IRC for communication.
Everything from thunking layers to calling conventions to inline assembly in the Wine codebase had to be redesigned for this release of Wine; an absolutely massive proposition. Ideas such as dynamic binary translation and running Win32 executables in the MacOS hypervisor framework were considered, and some ideas I tried while hacking Wine gave me insight into other projects I hack on such as Qemu and LLVM.
In short; props to everyone who worked on this! It was a long time in the process!
The Codeweaver folks are really great. I worked with one of their engineer's brother, which is how I can to discover this local (for me) company. The Linux version of WINE really shines too. They track, fix, and give back to the open source project while taking care of all the setup, etc. Ironically, a Win95 Garmin GPS simulator (airplane instrument) worked lovely on their kit... while it would not work on the 'run as' on Windows 7.
I've got their OSX version as well. There was a day where I needed Visio at work, and that would let me launch a Windows bottle. Funny enough, it also ran quite a few steam games... back before there were solid OSX ports for what I'd play.
I find it marvelous you can reliably use software 24 years later. And we talk about binaries, not sources. And we talk about software still with business uses.
The original storage media may be corrupted but the software lives!
My personal belief is Wine will stand next and maybe above the GNU project, the Linux kernel, the QEMU emulator and the GIT version management as the best things ever made by free software.
Did you see this from previous Christmases? https://www.qemu-advent-calendar.org/2018/ (change the last digit to 6 or 4 to see previous Advent calendars) I think we have to wait 'til next year for the next one.
They're pretty great, and do a great job showing off the many platforms it can emulate, in a way that feels and rewards like a treasure hunt.
The oldest programs I can use reliably are win32 inside wine.
It may not be what you think is technically the best, but office 2007 works well and many games and other specialized too. The office license is cheap and does most of what I need.
Someone mentionned below, a perpetual license of Mathematica for MacOSX will be useless in a year, because of the deprecation. Their mistake was not buying the Windows version.
That's why I still buy win32 software to this day. Their binaries will work on anything for a long time.
Wine opens many new usecases. You realize the software rot myth was created by bad API deprecation pratices.
Think how different the market becomes when consumers can keep using a 12 years old license. You need to introduce fantastic new features to get my money. Changing the font, the menu and the colors won't do.
Even if it is free - why should I bother to learn this new software? The old license did cost me $5. If I misplace it, I can buy another for the same amount instead of paying year to year. And to this day it works reliably on every operating system I use.
> Speaking of code segments, the big thing that Catalina provides that enables this all to work is the ability to create 32-bit code segments in a 64-bit process. For that, they enabled the use of i386_set_ldt() in 64-bit processes. The big caveat though, is that this functionality is restricted by System Integrity Protection (SIP). For now, your best bet to get this working for yourself is to disable SIP. (CrossOver doesn't require that, but the mechanism by which we accomplish that is in flux internally to Apple. When it settles down, I'll update this thread.)
This is quite curious. Apple inconvenienced so many users by "removing" 32-bit support on Catalina, and then they added support for local descriptor tables? I'm not aware of any use of LDTs on modern systems (except perhaps Chrome for additional sandboxing).
> This is quite curious. Apple inconvenienced so many users by "removing" 32-bit support on Catalina, and then they added support for local descriptor tables? I'm not aware of any use of LDTs on modern systems (except perhaps Chrome for additional sandboxing).
For the specific purpose of enabling CrossOver's 32-on-64 support and things like it.
It's not too hard for the kernel to support user code merely entering the processor's 32-bit mode. CrossOver's processes don't even use 32-bit system calls or 32-bit Mach-O binaries, so support for those could hypothetically be removed, except that most of it is needed for watchOS anyway. But the most significant cost of i386 support was in userland, not the kernel: building separate x86_64 and i386 copies of every system library, and supporting the legacy i386 ABI, including an older version of the Objective-C runtime ABI. That's all gone now.
I am not privy to internal discussions, but it seems to me if there is really lots of ongoing maintenance needed at every release, and not simply exaggerating the need for occasional patches and bug fixes, then it is worth some consideration of re-architecting the way the compatibility mode works.
eg. Maybe draw the boundary of where you thunk at a different place. Maybe do more translation in user mode as this wine project did. Or focus on binary compatibility with old, frozen-in-time frameworks instead of rebuilding them with every OS build. Obviously the specifics will vary with actual details of breakage. But from outside, it seems like these type of questions weren't pursued to their maximum extent, resulting in pain for the end user.
Apple has some weird history with doing crazy things with 32b/64b stuff just because they can - back in the Intel 64 early days they ran a 64-bit kernel that loaded 32-bit device drivers. I don't know if anyone has still figured out the how and why of it!
You may be right but I remember both of those things - supporting 64-bit apps on 32-bit kernel and loading kexts that didn't bit-match the kernel. Long time ago so not sure.
When the first 64 bit Macs shipped none of the software was 64 bit clean. Even if the kernel source code had been 64 bit clean, it would have broken support for all the the 3rd party 32 bit drivers that existed.
So the kernel switched itself in 32 bit virtual mode, though some parts of the pmap layer understood 64 bit page tables in order to manage the 64 bit physical address space. While the kernel could not see all of memory, it did not need to, it could map any apertures it needed in by manipulating its own page tables.
At that point it is pretty trivial to setup a 64 bit address space for a process. The kernel could not directly map all of virtual address range of the process at once, but it already had the pmap and aperture management code to deal with that. That decoupled 64 bit user space bringup from the 64 bit kernel port. The first release that supported 64 bit processes did not have 64 bit UI frameworks, just the C library and some low level posix functionality, but it allowed scientific code that benefited from more memory to run.
Apple started working on 64-bit application support back when they were still on PowerPC, where they only had 64-bit for desktop processors, not laptops. Then the first round of Intel Macs had 32-bit Core Duo processors. Less than a year later the second round introduced 64-bit Core 2 Duo processors that were pretty much a drop-in replacement, and at the time it certainly didn't make sense for Apple to overhaul their EFI, kernel and drivers with a 64-bit transition only 9 months after switching from PPC to x86.
Support for 64-bit GUI applications on OS X didn't arrive until 2007, a year after Intel Macs started using 64-bit processors. Support for running a 64-bit kernel arrived in 2009, and only for machines that had 64-bit EFI firmware. In 2012, Apple dropped support for the machines that had 64-bit processors but used 32-bit EFI, so from that point on they were handling the 64/32-bit mix the same as other operating systems.
The obvious development reason is to simplify and unify the code base, tools, and build process across all of their platforms. 32-bit bugs can also be ignored/deleted for future versions.
The obvious hardware reason on iOS is that Apple can remove support for ARM32.
The obvious business reason is to encourage subscriptions to Apple Arcade.
And just to fully complete the thought, I believe the GGP is implying "Break existing Mac games, so that people who want to play games on their Mac have to subscribe to Apple Arcade."
Killing it in the way they did? Not a dire technical one. In the past they managed to keep compatibility while switching operating systems ("Classic") and CPU architectures (68k -> PPC, PPC -> Intel). And that while being a much smaller company.
This is business, nothing else. Just like all the increased "security" restrictions. Corralling everyone towards the App Store. I think they've got too much legacy to ever totally cut off "regular" applications, but apart from that they're doing everything they can to move everything in the direction of iOS (or iPadOS now).
Not sure how long the days of the last commercial Unix will last.
Your point notwithstanding, the big difference to me is this: Classic and Rosetta were hacks with sucky UX. In particular, performance was terrible, in Rosetta because it was a full on CPU emulator, and Classic because it was booting Mac OS 9 in a Virtual Machine. Apps that used Classic also looked visually out of place.
Running 32 bit apps in Mac OS X Mojave is 100% seamless to the user—if it wasn't for Apple's warning dialogues that 32bit was going to be deprecated, most users—even advanced users—would never even know the app was 32 bit.
And that's because 32 bit support is a key feature of the amd64 architecture—it's the main reason most computers today use amd64 instead of the alternate standard proposed by Intel.
Killing it in the way they did? Not a dire technical one. In the past they managed to keep compatibility
Killing it in what way? They kept compatibility for years and eventually ended it, just like the transitions you mention.
This is business, nothing else
Both the security changes and dropping 32 bits are technically reasonable things to do. You might not like them and that's perhaps not entirely unreasonable either but the notion that they were done for business, nothing else makes little sense. What business do you have in mind? Apple makes money selling iPhones.
I'd guess a translation layer would require much more effort to develop and maintain than just keeping 32 bit support. It wouldn't make much sense in this case because dropping support is the sole objective, not some side effect caused by architectural/OS changes.
I was just mentioning those layers as something Apple was able to do if they wanted to keep being compatible. They could, but they don't want. How sinister that purpose is, is up to the reader...
Apple has a long history of sunsetting various technologies, so I don't know how this is different. Their solution to tech debt is often to just deprecate the edge cases -- which is probably the right decision.
Yeah, Apple tried to take the Microsoft approach with the Mac Clones in the late 90s and it failed spectacularly because it's just not in their DNA to be a tech company. They're a product company that hates managing technology longer than is absolutely necessary.
That's entirely the case. Apple has to weigh the cost of maintaining compatibility against the value it brings.
And it's hard to see how if the developer can't make a business case for updating their software that Apple can make a business case for maintaining compatibility.
That's the business reality of Apple's primarily consumer market: consumers are generally willing to let old software go and buy new stuff.
Microsoft is simply in a different market: they have many large enterprise customers who are willing to pay top dollar for extensive backwards compatibility.
I remember using some Connectix gadget on a IIcx to make it able to address 32 bits. I spent some time in macsbug figuring out how it worked. It was really interesting. It essentially patched the memory manager early in the boot process then forced it to reinitialize itself.
I'm pretty sure Apple licensed that for some version of System 7 (maybe 7.5.something?) so that they could assume all post-boot 32-bit macs were 32-bit clean.
The Classic environment was retired in 2007 with the release of 10.5 Leopard, and was never available for x86 Macs. With 10.7 Lion (2011), they dropped support for 32-bit x86 Macs, and running PowerPC software via emulation (Rosetta). Eight years of support for 32-bit apps is quite long by these standards.
This is a great feat and it creates a somewhat ironic situation: When I want to run an app on Catalina that happens to be 32-bit only, I'm practically forced to use the Windows version. I can't see how that was a smart move on Apple's side.
As I understand it, this would only be possible if you recompiled the software with the modified Clang they use for the Windows apps (and the underlying tech is in a state of flux). I'm not sure that would be more expedient than rebuilding your app as 64-bit.
The system frameworks you’d depend on don’t have a 32-bit slice anymore, unfortunately. You’d need to wrap every function in a think to make things work.
The writing that 32bit apps are going away was on the wall for a long time. If you still rely on that (maybe for some enterprise application) then you are probably not going to upgrade to the newest version right away anyway.
It’s like removing the floppy drive, there will be a bunch of people complaining (probably the 1%) who still use it but in the end everyone is better of without it and it will be replaced by something better.
Almost nobody of the general users would know a difference between 32 / 64 bit as they just use new apps or use web apps. It’s a very small group that’s affected by this change.
The writing has been on the wall for a long time but some big name software companies are slow to adapt, and even if they adapted you'll probably have to pay good money for a new license.
Take Mathematica for example. The first 64-bit version is 12.0, released April 2019. So a year-old permanent v11 license is useless on Catalina now. It would have cost me a couple hundred bucks to upgrade my v9 permanent license if I didn't happen to have an institutional license.
Sounds like you ought to get mad at Mathematica for selling 32bit MacOS software in 2019, which it's been well known for over a decade that support will eventually be dropped.
Hardly been "well known for over a decade". A decade ago, Rosetta was well-supported. The dropping of Rosetta support in Lion was quasi-abrupt, but understandable (it arose from a licensing concern after the tech was acquired). The 32/64 transition was announced a few years ago, but it was hardly something known a decade ago.
The history of Apple suggests that when they come out with a new development environment, it is well advised to just go ahead an make that switch as soon as possible. Even if they make a bandaid type of stepping stone like Rosetta, don't lean on it permanently. Adobe had to skip an entire version of their software suite because they didn't believe Apple was serious.
In the grand scheme of things, how many companies do you think wrote software for the Intel based Mac between the beginning of 2006 when the first Intel based Macs were introduced and 2009 when Apple dropped support for 32 bit Macs and then went out of business?
Every piece of code in an operating system means a larger surface area for vulnerabilities, more support cost, more maintenance for both developers and the operating system maintainers, etc.
If you want to see how badly this can go wrong - look at Windows. Over a decade ago there were over a half a dozen different ways to represent a string in Windows and depending on which API you called, you had to translate between them.
Also, one of the earliest widespread vulnerabilities was caused by IIS not checking all of the different types of string encodings. You could literally pass DOS commands via the url bar just by encoding them and they would run on the server.
Find me a perpetual license for a version of Adobe Lightroom that has a 64-bit installer and I'll pay for it. But I'm not going to upgrade to a leased tool. Luckily the perpetual Lightroom licenses work on Windows too, so when Mavericks loses support I'll probably migrate at least the photography workflows to wine (on not-macOS though).
What perpetual license? If you buy a copy of something like CC suite, it was for that current version. If Adobe updates a major upgrade (not point releases), they charged you again for the upgrade. That was usually 12-18 months. That was also $999 for those upgrades. Sure, you could stay on that version, but as the OS upgrades, that code becomes unusable forcing the upgrade. The "lease" licenses is $50/month or $600/yr (usually comes with a discount for the 12month purchase). You get access to the upgrades as they come so you're always current. Where's the evil? Oh, and with that $50/month, I can run it on 2 separate computers simultaneously. The original license was for one computer.
The perpetual license to use the software in the version you bought. Few people truly needed every single version, but instead only upgraded when it became necessary or there was a killer feature they wanted.
You're simply forgetting the fact that as the OS upgrades, the software that is not upgraded cannot be used without also upgrading. What's the last OS that CS6 could be installed?
Also, anyone using Adobe software in a professional setting (meaning actually getting paid for using the software) can easily pay the monthly fees. Staying on an antiquated version of software means they can no longer open files that are created on recent versions of software (thinking Premiere). I have not met one professional that is still holding on to the perpetual license fallacy. The maths just don't add up.
Also, anyone using Adobe software in a professional setting (meaning actually getting paid for using the software) can easily pay the monthly fees.
Even if I were getting paid for my photography, why would I want to pay extra fees?
Staying on an antiquated version of software means they can no longer open files that are created on recent versions of software (thinking Premiere).
In the case of Lightroom the only thing that's going to "upgrade" your file format is a new camera body, and that's not something I do all that much. I don't need to open files from people with newer cameras. And, let's face it, if I really need to open newer raw files I can use Adobe's DNG converter.
Lightroom 6 is a 64-bit app with a 32-bit installer. Newer versions of LR offer up a ton of cloud shit I don't want, bundled with more seamless integration for newer cameras I don't own. What am I getting out of monthly payments to Adobe?
The past few upgrades to Lightroom that I've bought were around $80. Well less than a year of the cheapest CC subscription.
I’d love to see professional licenses switch to a “maximally fair to the user subscription model”.
If you use the thing in a given month, you autopay the monthly subscription fee — if you don’t use it at all in a given month — you pay nothing.
people who use the software regularly pay basically the current subscription pricing model — but if you only use it very occasionally — you pay much less.
I think this kind of pricing model could really help drive adoption of subscription pricing for professional tools ... I’d be willing to maintain a subscription to several expensive infrequently used by me tools with this kind of pricing model — and I might occasionally use those tools which would be better for the developer than me never using their tool at all ...
I'd like that too, although the pricing steps are an interesting challenge: You want to make the full amount of regular users, but don't want the casual users to think "if I click this icon now to touch one file, it's gonna cost me 20 bucks", so you might need even more granular steps. E.g. a month costs the same as 1/10th of a year, a day costs the same as 1/8th of a month -> if you use it >8 days in a month it caps to the month, if you use it >10 months it caps to the year. Kind of like some public transport network cards work.
at least Photoshop CS6 runs perfectly fine on a current Windows 10 (I suspect it wouldn't do good with a high-DPI screen though), but I agree that going all the way back to that today is not really something you'd do for regular professional use. Of course, not everyone is a professional user.
That said, freelancers I know using Adobe software have to keep old versions around because clients don't upgrade. People are even now skipping or lagging versions, because they'd rather stay with a version they know works than invite new bugs by upgrading.
I think it goes without saying that not everyone that buys software is a professional, and instead wish to use it a few times per year for job adjacent functions or as a hobbyist. For the "few times a year" folks, maybe "one month at a time is annoying but reasonable enough."
Apple has been offering solutions to run Windows apps for over two decades. First they bundled SoftWindows with early PPC Macs, then they offered hardware Intel daughtercards and they have been bundling Boot Camp since shortly after the Intel Macs were introduced.
There is very little important software outside of iOS development software that is Mac only. People who care about backwards compatibility would never buy Macs.
> It also relies on a new feature of macOS Catalina to allow the creation of 32-bit code segments in a 64-bit process.
How was this never brought up during all the "Catalina killed 32-bit" pitchforkings? Seems like a very important point, that has enabled the ability to emulate 32-bit apps.
AFAICT, this won't let people run existing 32 bit apps out of the box. Instead, it enables the creation of 32 bit stub libraries that can call their 64 bit counterparts in behalf of the application. Although it's possible in theory to run existing 32 bit apps by creating stub libraries for 32 bit APIs, it's likely to require so much effort that I doubt this is going to happen.
> the big thing that Catalina provides that enables this all to work is the ability to create 32-bit code segments in a 64-bit process. For that, they enabled the use of i386_set_ldt() in 64-bit processes. The big caveat though, is that this functionality is restricted by System Integrity Protection (SIP). For now, your best bet to get this working for yourself is to disable SIP. (CrossOver doesn't require that, but the mechanism by which we accomplish that is in flux internally to Apple. When it settles down, I'll update this thread.)
"entitlements" are OSX Catalina's new(ish?) permission grants that applications need in order to access certain features like JIT or specific syscalls.
The entitlement needed for this feature to work is undocumented.
Catalina makes them all-but-required, though, even for non-store apps, between SIP (System Integrity Protection) and the on-by-default enforcement of notarization.
On previous versions of macOS, regular developers could mostly avoid needing to touch them by just not being a store app.
iOS developers have had to think about them since the early days.
Jayflux, most open source IRC channels are logged on webservers. Those logs are usually also searchable on Google, and you don't need to sign in to view them. Unlike Slack etc
Seeing that both slack and discord save logs from the beginning (which irc doesn’t), isn’t communication less hidden if anything? It’s far easier for someone new to play catch up.
There’s a reason large open source projects moved to these (React, Rust, etc).
All of the replies to your comment seem to be pointing out that IRC can be logged, but they're missing the point. You shouldn't play catch-up on IRC. Any useful information to persist should flow into the docs or onto the mailing list. On IRC, no one is expected to stay abreast of discussions they were absent for.
Long-term documentation is not the reason logs are useful. Asynchronous communication is the reason logs are useful.
That is, you can ping people who are offline, or with a flaky network connection (e.g. mobile, where you can't keep a consistent TCP stream open), and they can still see your message and a bit of context when they get back.
Long term documentation should be not be in any emails or IRC logs. It should be properly documented as a formal documentation. But that is different to coordinating a team.
Open source projects typically cannot afford to pay for slack, which makes all but the most recent logs unsearchable. I've found this in quite a few open source groups and it means the same questions get asked over and over again and its incredibly wasteful and irritating IMHO.
These open source groups could surely use a chatbot to log the chats to some place for archival and make the archive searchable, can't they?
By the way, I find IRC/Slack good for real-time support. By nature of being real-time support, some questions get repeated over and over again. The repeition is typically mitigated by adding trivia bots to the channel that can provide answers to frequently asked questions.
The best solution I have seen for archived solutions and to avoid repetition are Stack Overflow (encourage users to post questions on SO with relevant tag) and mailing list with a mailing list archive.
Are there any Slack chatbots that do that kind of logging and archiving? When I searched a couple years ago, I found several projects... and none of them worked except one (SlackArchive.io, I think), which worked for another couple months after I found it then died with, IIRC, communication from its operators that suggested Slack was cracking down on bots that were being used for this purpose. (Which is not unexpected.)
As jononor already said they are usually logged to a public location. And even if they are not they are logged in plain text on each client usually.
In Slack the logs are also not searchable if you above a certain threshold (10k lines or something) if you don’t pay. Slack is prohibitively expensive if you have a lot of users and not really made for such a non-company use case.
No Rust did actually move (its 'official') channel off IRC.
I believe it was sort of catalysed by Mozilla shutting down its IRC servers, but presumably it was already an issue being discussed, and that was just the final nail.
And since that happened, I've stopped engaging with the community at large. There are people who disagree, but I personally do not want to waste stupid amounts of memory to do ephemeral messaging. And their gatekeeping bot is stupid.
Slack and Discord may have logs but you have to download a massive blob of proprietary software, register and agree to some ToS to access them. Those logs are everything but public.
I'd argue it works for devs at the same company quite well, but having asynchronous communication is counter to your average business persons desire to lock you in a room for an hour and make you make a decision.
the cancer wine is coming to macOS... they don't need that, they have a healthly platform and eco-system, stop trying to make macOS a linux distribution, it is not a crapware hackerWanabeOS
Everything from thunking layers to calling conventions to inline assembly in the Wine codebase had to be redesigned for this release of Wine; an absolutely massive proposition. Ideas such as dynamic binary translation and running Win32 executables in the MacOS hypervisor framework were considered, and some ideas I tried while hacking Wine gave me insight into other projects I hack on such as Qemu and LLVM.
In short; props to everyone who worked on this! It was a long time in the process!
I've got their OSX version as well. There was a day where I needed Visio at work, and that would let me launch a Windows bottle. Funny enough, it also ran quite a few steam games... back before there were solid OSX ports for what I'd play.
The original storage media may be corrupted but the software lives!
My personal belief is Wine will stand next and maybe above the GNU project, the Linux kernel, the QEMU emulator and the GIT version management as the best things ever made by free software.
They're pretty great, and do a great job showing off the many platforms it can emulate, in a way that feels and rewards like a treasure hunt.
Interesting, why was this discarded? Performance reasons? Or the API not being satisfactory?
The oldest programs I can use reliably are win32 inside wine.
It may not be what you think is technically the best, but office 2007 works well and many games and other specialized too. The office license is cheap and does most of what I need.
Someone mentionned below, a perpetual license of Mathematica for MacOSX will be useless in a year, because of the deprecation. Their mistake was not buying the Windows version.
That's why I still buy win32 software to this day. Their binaries will work on anything for a long time.
> How long will [the MacOS hypervisor framework] exist?
Think how different the market becomes when consumers can keep using a 12 years old license. You need to introduce fantastic new features to get my money. Changing the font, the menu and the colors won't do.
Even if it is free - why should I bother to learn this new software? The old license did cost me $5. If I misplace it, I can buy another for the same amount instead of paying year to year. And to this day it works reliably on every operating system I use.
Dethroning MS Office is going to be a long, hard battle, and it seems like not very many people are interested in fighting it.
But? Those are both extremely capable communication mechanisms.
Although coding over voice/video chat isn’t fun.
This is quite curious. Apple inconvenienced so many users by "removing" 32-bit support on Catalina, and then they added support for local descriptor tables? I'm not aware of any use of LDTs on modern systems (except perhaps Chrome for additional sandboxing).
For the specific purpose of enabling CrossOver's 32-on-64 support and things like it.
It's not too hard for the kernel to support user code merely entering the processor's 32-bit mode. CrossOver's processes don't even use 32-bit system calls or 32-bit Mach-O binaries, so support for those could hypothetically be removed, except that most of it is needed for watchOS anyway. But the most significant cost of i386 support was in userland, not the kernel: building separate x86_64 and i386 copies of every system library, and supporting the legacy i386 ABI, including an older version of the Objective-C runtime ABI. That's all gone now.
eg. Maybe draw the boundary of where you thunk at a different place. Maybe do more translation in user mode as this wine project did. Or focus on binary compatibility with old, frozen-in-time frameworks instead of rebuilding them with every OS build. Obviously the specifics will vary with actual details of breakage. But from outside, it seems like these type of questions weren't pursued to their maximum extent, resulting in pain for the end user.
So the kernel switched itself in 32 bit virtual mode, though some parts of the pmap layer understood 64 bit page tables in order to manage the 64 bit physical address space. While the kernel could not see all of memory, it did not need to, it could map any apertures it needed in by manipulating its own page tables.
At that point it is pretty trivial to setup a 64 bit address space for a process. The kernel could not directly map all of virtual address range of the process at once, but it already had the pmap and aperture management code to deal with that. That decoupled 64 bit user space bringup from the 64 bit kernel port. The first release that supported 64 bit processes did not have 64 bit UI frameworks, just the C library and some low level posix functionality, but it allowed scientific code that benefited from more memory to run.
Support for 64-bit GUI applications on OS X didn't arrive until 2007, a year after Intel Macs started using 64-bit processors. Support for running a 64-bit kernel arrived in 2009, and only for machines that had 64-bit EFI firmware. In 2012, Apple dropped support for the machines that had 64-bit processors but used 32-bit EFI, so from that point on they were handling the 64/32-bit mix the same as other operating systems.
The obvious hardware reason on iOS is that Apple can remove support for ARM32.
The obvious business reason is to encourage subscriptions to Apple Arcade.
Section "Why Drop 32 Bit?" (last quarter of the article).
This is business, nothing else. Just like all the increased "security" restrictions. Corralling everyone towards the App Store. I think they've got too much legacy to ever totally cut off "regular" applications, but apart from that they're doing everything they can to move everything in the direction of iOS (or iPadOS now).
Not sure how long the days of the last commercial Unix will last.
The Classic Environment (OS 9 -> OS X) was dropped after 6 years.
Rosetta (PPC -> i386) was dropped after 5 years.
i386 -> x86_64 is now being dropped after 12 years.
Running 32 bit apps in Mac OS X Mojave is 100% seamless to the user—if it wasn't for Apple's warning dialogues that 32bit was going to be deprecated, most users—even advanced users—would never even know the app was 32 bit.
And that's because 32 bit support is a key feature of the amd64 architecture—it's the main reason most computers today use amd64 instead of the alternate standard proposed by Intel.
Killing it in what way? They kept compatibility for years and eventually ended it, just like the transitions you mention.
This is business, nothing else
Both the security changes and dropping 32 bits are technically reasonable things to do. You might not like them and that's perhaps not entirely unreasonable either but the notion that they were done for business, nothing else makes little sense. What business do you have in mind? Apple makes money selling iPhones.
That's entirely the case. Apple has to weigh the cost of maintaining compatibility against the value it brings.
And it's hard to see how if the developer can't make a business case for updating their software that Apple can make a business case for maintaining compatibility.
That's the business reality of Apple's primarily consumer market: consumers are generally willing to let old software go and buy new stuff.
Microsoft is simply in a different market: they have many large enterprise customers who are willing to pay top dollar for extensive backwards compatibility.
I'm pretty sure Apple licensed that for some version of System 7 (maybe 7.5.something?) so that they could assume all post-boot 32-bit macs were 32-bit clean.
I think you meant “thunk”.
It's apparently straightforward to install - an old - macOS in a VM. This can then be used to obtain the dylibs
It’s like removing the floppy drive, there will be a bunch of people complaining (probably the 1%) who still use it but in the end everyone is better of without it and it will be replaced by something better.
Almost nobody of the general users would know a difference between 32 / 64 bit as they just use new apps or use web apps. It’s a very small group that’s affected by this change.
Take Mathematica for example. The first 64-bit version is 12.0, released April 2019. So a year-old permanent v11 license is useless on Catalina now. It would have cost me a couple hundred bucks to upgrade my v9 permanent license if I didn't happen to have an institutional license.
You seem to think that would be a bad thing. Why?
The operating system is there to support applications.
If you want to see how badly this can go wrong - look at Windows. Over a decade ago there were over a half a dozen different ways to represent a string in Windows and depending on which API you called, you had to translate between them.
Also, one of the earliest widespread vulnerabilities was caused by IIS not checking all of the different types of string encodings. You could literally pass DOS commands via the url bar just by encoding them and they would run on the server.
Sorry I meant Mojave or whatever 10.14 is called.
Also, anyone using Adobe software in a professional setting (meaning actually getting paid for using the software) can easily pay the monthly fees. Staying on an antiquated version of software means they can no longer open files that are created on recent versions of software (thinking Premiere). I have not met one professional that is still holding on to the perpetual license fallacy. The maths just don't add up.
Even if I were getting paid for my photography, why would I want to pay extra fees?
Staying on an antiquated version of software means they can no longer open files that are created on recent versions of software (thinking Premiere).
In the case of Lightroom the only thing that's going to "upgrade" your file format is a new camera body, and that's not something I do all that much. I don't need to open files from people with newer cameras. And, let's face it, if I really need to open newer raw files I can use Adobe's DNG converter.
Lightroom 6 is a 64-bit app with a 32-bit installer. Newer versions of LR offer up a ton of cloud shit I don't want, bundled with more seamless integration for newer cameras I don't own. What am I getting out of monthly payments to Adobe?
The past few upgrades to Lightroom that I've bought were around $80. Well less than a year of the cheapest CC subscription.
If you use the thing in a given month, you autopay the monthly subscription fee — if you don’t use it at all in a given month — you pay nothing.
people who use the software regularly pay basically the current subscription pricing model — but if you only use it very occasionally — you pay much less.
I think this kind of pricing model could really help drive adoption of subscription pricing for professional tools ... I’d be willing to maintain a subscription to several expensive infrequently used by me tools with this kind of pricing model — and I might occasionally use those tools which would be better for the developer than me never using their tool at all ...
That said, freelancers I know using Adobe software have to keep old versions around because clients don't upgrade. People are even now skipping or lagging versions, because they'd rather stay with a version they know works than invite new bugs by upgrading.
And on Mojave, by the way. It's only this stupid 32 bit thing that's killing it in Catalina.
> but I agree that going all the way back to that today is not really something you'd do for regular professional use.
Why? Adobe hasn't added anything particularly significant since CS6.
(And I don't think it's a coincidence that they moved to a subscription model around the same time they stopped making significant improvements.)
Hobbyists, though, are in a bad spot.
There is very little important software outside of iOS development software that is Mac only. People who care about backwards compatibility would never buy Macs.
So true; it feels like every Mac app is Electron these days.
How was this never brought up during all the "Catalina killed 32-bit" pitchforkings? Seems like a very important point, that has enabled the ability to emulate 32-bit apps.
> the big thing that Catalina provides that enables this all to work is the ability to create 32-bit code segments in a 64-bit process. For that, they enabled the use of i386_set_ldt() in 64-bit processes. The big caveat though, is that this functionality is restricted by System Integrity Protection (SIP). For now, your best bet to get this working for yourself is to disable SIP. (CrossOver doesn't require that, but the mechanism by which we accomplish that is in flux internally to Apple. When it settles down, I'll update this thread.)
The entitlement needed for this feature to work is undocumented.
See here: https://developer.apple.com/documentation/bundleresources/en...
On previous versions of macOS, regular developers could mostly avoid needing to touch them by just not being a store app.
iOS developers have had to think about them since the early days.
Is this roughly equivalent to MAP_32BIT on Linux?
http://man7.org/linux/man-pages/man2/mmap.2.html
http://man7.org/linux/man-pages/man2/modify_ldt.2.html
https://marc.info/?l=openbsd-misc&m=148926149318522
I wonder what other projects (on a scale larger than your typical side hustle projects) are coordinated via IM chat or email?
On the surface, the Linux kernel coordination seems to be coordinated like this, but I am not 100% sure.
Seeing that both slack and discord save logs from the beginning (which irc doesn’t), isn’t communication less hidden if anything? It’s far easier for someone new to play catch up.
There’s a reason large open source projects moved to these (React, Rust, etc).
That is, you can ping people who are offline, or with a flaky network connection (e.g. mobile, where you can't keep a consistent TCP stream open), and they can still see your message and a bit of context when they get back.
By the way, I find IRC/Slack good for real-time support. By nature of being real-time support, some questions get repeated over and over again. The repeition is typically mitigated by adding trivia bots to the channel that can provide answers to frequently asked questions.
The best solution I have seen for archived solutions and to avoid repetition are Stack Overflow (encourage users to post questions on SO with relevant tag) and mailing list with a mailing list archive.
In Slack the logs are also not searchable if you above a certain threshold (10k lines or something) if you don’t pay. Slack is prohibitively expensive if you have a lot of users and not really made for such a non-company use case.
Not everyone uses IRC (but it has archives). Email (and its archives) are a thing, too.
Given you can read all the development of the Linux kernel since almost the beginning (and they don't use chat IIRC), I don't think you are correct.
> There’s a reason large open source projects moved to these (React, Rust, etc).
No, there is no reason. They are newer projects with younger people and they just picked something more modern, based on a web browser.
If there was truly a reason, the kernel and other projects would have moved, too.
You can argue, of course, the pros and cons of each alternative.
I believe it was sort of catalysed by Mozilla shutting down its IRC servers, but presumably it was already an issue being discussed, and that was just the final nail.
Open source projects are likely the largest user of mailing lists.