
Win32 on macOS - yarapavan
https://www.winehq.org/pipermail/wine-devel/2019-December/156602.html
======
joshumax
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!

~~~
bonzini
> running Win32 executables in the MacOS hypervisor framework

Interesting, why was this discarded? Performance reasons? Or the API not being
satisfactory?

~~~
Spooky23
How long will it exist?

~~~
1996
IDK, a long time I'd suppose?

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.

~~~
oatmealsnap
There must be open source editors available that have feature parity with 12yo
software.

~~~
1996
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.

------
kccqzy
> 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).

~~~
throwaway884840
> 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.

~~~
asveikau
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.

------
steve19
Does apple have a good reason for killing 32bit support? I play a number of
games that will now never run without a VM.

~~~
mhd
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.

~~~
throwaway884840
> In the past they managed to keep compatibility while switching operating
> systems ("Classic") and CPU architectures (68k -> PPC, PPC -> Intel).

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.

~~~
Wowfunhappy
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.

------
tempodox
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.

~~~
andai
Could some of the wizardry described here be used to get native 32-bit
software working again?

~~~
saagarjha
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.

~~~
CodeWriter23
> You’d need to wrap every function in a think to make things work.

I think you meant “thunk”.

~~~
saagarjha
I did but AutoCorrect unfortunately thunk differently.

------
Razengan
> _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.

~~~
saagarjha
It’s gated by an undocumented entitlement.

~~~
exikyut
I don't know how to mentally parse this sentence. (Not snark; stumped.)

~~~
kevingadd
"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.

See here:
[https://developer.apple.com/documentation/bundleresources/en...](https://developer.apple.com/documentation/bundleresources/entitlements)

~~~
my123
Entitlements aren't new, they existed since ages (OS X 10.11 already used them
quite a bit).

~~~
hoistbypetard
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.

------
skunkworker
Okay that’s just impressive. I was wondering how they would adapt for 32bit
support on Catalina.

------
nly
> It also relies on a new feature of macOS Catalina to allow the creation of
> 32-bit code segments in a 64-bit process

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/mmap.2.html)

~~~
burfog
No, it is like modify_ldt on Linux.

[http://man7.org/linux/man-
pages/man2/modify_ldt.2.html](http://man7.org/linux/man-
pages/man2/modify_ldt.2.html)

------
notaplumber
Why OpenBSD/amd64 will not, and never has supported 32-bit binary
compatibility on 64-bit.

[https://marc.info/?l=openbsd-
misc&m=148926149318522](https://marc.info/?l=openbsd-misc&m=148926149318522)

------
yitchelle
>> ...coordinated using mainly nothing but email and IRC for communication.

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.

~~~
dewey
Every open source project that’s reasonable enough not to hide all their
communications in proprietary silos like Slack and Discord.

~~~
jayflux
Ok I’ll bite..

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).

~~~
ddevault
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.

~~~
Rusky
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.

~~~
yitchelle
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.

