Win32 on macOS
winehq.org
winehq.org
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!
But? Those are both extremely capable communication mechanisms.
Although coding over voice/video chat isn’t fun.
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.
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.
> How long will [the MacOS hypervisor framework] exist?
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
Section "Why Drop 32 Bit?" (last quarter of the article).
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.
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.
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.
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 ...
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.
Sorry I meant Mojave or whatever 10.14 is called.
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 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.
> 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.)
Is this roughly equivalent to MAP_32BIT on Linux?
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.
Open source projects are likely the largest user of mailing lists.
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).
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.
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.
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.
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.