How to re-enable 32-Bit support on MacBook Air when upgrading to MacOS Monterey

mrmagnetoman88 wrote:

Yes, you're right. It does seem a little risky and shouldn't be recommended. On a side note, if only, if only 32-bit support wasn't ended for newer operating systems......sigh.

Have you ever worked inside an operating system kernel?

maintaining 32-bit and 64-bit operating system API’s is a lot of work, and worrying about converting 32-bit addresses passed into the kernel to their 64-bit equivalent, and all kinds of other stuff is non-trivial.

Plus it has to be tested, which adds to the QA budget.

And fewer and fewer 32-bit apps get created.

There comes a point where it is time to move on.

Apple started telegraphing its intent to go 64-bit at least 10 years before they did.

Then they switched the iPhone and iPad to 64-bit.

But some developers did not get the message, and still compiled for 32-bits. And I’m not talking about small independent developers. Microsoft Office got caught when the switch happened.

Apple tried to get developers to switch early, apparently 10 years was not enough time.

You are getting confused here by 32 bit support. The 32bit app support (or library support) you are referencing in regards to macOS 10.15+ refers only to macOS apps, not Windows' apps. Codeweavers' CrossOver software and the other WINE based apps you are using or referring are 64bit macOS apps. 32 bit macOS library support is not needed in these cases.

CrossOver does indeed support 32 bit Windows apps even on Apple Silicon M-series Macs, however, they are likely to have performance issues. From a quick search, CrossOver and WINE must utilize wine32on64 to allow it.

https://www.codeweavers.com/blog/jschmid/2023/2/14/presenting-crossover-221-the-hallmark-of-this-holiday

https://www.theregister.com/2020/11/19/crossover_apple_m1/

A lot of things can impact Windows app compatibility when using WINE. A new WINE version may easily break something that has worked previously (perhaps even years). A macOS update can change the behavior of the system which could greatly impact WINE. A different version of the Windows app may greatly affect compatibility & performance as well. This is why some WINE based apps allow you to install other older versions of WINE. If you find a version of WINE which allows a particular Windows app to run, then you should note that exact version of WINE and any tricks/options you had to enable or configure to make it work. Then do not update that version of WINE since a later version could break something.

Getting Windows software running using WINE in any of its forms is complex, challenging, and always changing. It is great when it works for a particular app, but many times the Windows software will have issues or not work at all.

Here is a good thread on the Codeweavers' CrossOver forum which explains some of the compatibility issues and performance differences for Windows software using various systems (Intel Mac running macOS 10.14 or earlier, Intel Macs running macOS 10.15+, and Apple Silicon M-Series Macs).

https://www.codeweavers.com/support/forums/general/?t=27;mhl=248755;msg=248533#c2

Here is another post later in that same thread which I found interesting since it discusses compatibility:

https://www.codeweavers.com/support/forums/general/?t=27;mhl=248755;msg=248533#c6

AFAIK, there is no option to allow running macOS 32bit software on any Mac running macOS 10.15+. WINE is not meant or able to run macOS apps. If you want to run older macOS 32 bit apps, then you need to run an older version of macOS 10.14 or earlier as the others have already mentioned.

You need to clarify clearly which 32 bit libraries you are referring.....macOS or Windows?

If it is just Windows apps running on a Mac, then you should just stick with what has worked in the past. Trying to run Windows 32 bit apps on macOS 10.15+ is different since another layer had to be added to WINE for it to work, and Apple Silicon M-series Macs changes things even more. Each of these major system change makes it more likely that some Windows apps may have issues on a later system or OS when you may have had it working perfectly fine on Mojave. This is far from a simple process. People have been struggling with Windows software using WINE from the beginning even on a non-Apple PC. WINE has come a long way, but it is far from perfect. Like I said before, it is great when a Windows app works using WINE, but it is far from being guaranteed.

I hope this helps.

Some versions of WINE may support running 32 bit Windows apps on macOS 10.15+ at least on an Intel Mac although I don't know how well they perform....I know people have reported 32 bit Windows apps are too slow when using an Apple Silicon Mac due to the secret magic the WINE code must use to allow it. I saw this mentioned in a forum post on the Code Weaver's site which makes the CrossOver app which tends to have some extra magic bits before it makes it into the mainstream WINE project.

The transition to 64bit software was mostly due to memory limitations. 32bits limits memory access to just 3G/4GB. There were ways to allow a 32bit CPU to access more than 4GB of RAM, but they were clunky hacks. Plus some CPU features are only available with 64bit software support. Performance also plays a part as well.

https://www.techtarget.com/searchdatacenter/definition/64-bit-processor

https://en.wikipedia.org/wiki/64-bit_computing

32bit CPU was allowed in order for people to have a much easier transition to 64bit systems since all of the existing software at the time was 32bits and people want to run their existing apps. Much the same reason Apple includes Rosetta when changing CPU architectures. Just like 32bit support, even Rosetta2 will most likely disappear at some point (Rosetta 1 did after just a few years).

BobHarris wrote:

mrmagnetoman88 wrote:

Yes, you're right. It does seem a little risky and shouldn't be recommended. On a side note, if only, if only 32-bit support wasn't ended for newer operating systems......sigh.

Have you ever worked inside an operating system kernel?

Yes, I have.

maintaining 32-bit and 64-bit operating system API’s is a lot of work, and worrying about converting 32-bit addresses passed into the kernel to their 64-bit equivalent, and all kinds of other stuff is non-trivial.

Doing a hybrid 32- and 64-bit kernel design and implementation is non-trivial, limits what you can fix and what you can enhance, and the results inevitably turn into a dog’s breakfast.

APIs have to figure out how to copy into or to remap stuff into 32-bit address space, to start with. This because you can’t pass a 64-bit pointer to some data in 64-bit address space to a 32-bit app. You can’t use big arrays or big data caches in 32-bit land, either. And whatever you do all still has to fit everything you need into 32-bit address space, for that matter.

The hybrid 32- and 64-bit design is more than twice the work of 32- and 64-bit APIs, for worse results, and there’s still the expectation that the old 32-bit APIs are going to eventually fall away and be removed.

Apple started migrating to 64-bit at OS X 10.4 in 2005, and migration in earnest with OS X 10.5 (2007) and OS X 10.6. (2009). This 64-bit transition has been happening for a long time.

Best options here can be a guest in a virtual machine on a Mac x86-64 configuration, or keeping the old hardware and old software around. And I’d not suggest trying to boot a macOS x86-64 operating system through emulation and virtualization on Apple silicon, as that probably lacks performance.

mrmagnetoman88 wrote:

PS I believe I'm referring to the 32 bit libraries of Windows. It's clear from what you and the others have said here that the 32 bit MacOS libraries are no longer available. Sorry to ask again, but regarding the 32 bit Windows libraries, are those retrievable after upgrading to MacOS 10.15+? Sorry, I don't mean to be difficult, I'm just trying to get as clear a picture as I can.

There are no Microsoft Windows libraries in macOS, whether on macOS 32-bit or 64-bit, or whether those libraries are Windows 32-bit or 64-bit.

There might be third-party Windows compatibility layers available fir macOS via third-party apps, and you’ll best discuss the features and requirements of those apps with the folks that know those apps best; with the folks that support those.

Or for Windows apps, go get yourself a Windows system and preserve what apps you want over there. Microsoft started moving away from 32-bit back around 1999, but can still run your 32-bit apps on 64-bit Windows via their confusingly named WOW64. Maybe boot that as a guest on an Intel Mac. Might also run on Windows on Arm booted as a guest on an Apple silicon Mac, but probably not at speed.

Apple retired the 32-bit Apple macOS libraries and frameworks and APIs at macOS 10.15.

The Apple APIs and frameworks and APIs are unrelated to what Microsoft Windows 32- or 64-bit offers.

mrmagnetoman88 wrote:

PS I believe I'm referring to the 32 bit libraries of Windows. It's clear from what you and the others have said here that the 32 bit MacOS libraries are no longer available. Sorry to ask again, but regarding the 32 bit Windows libraries, are those retrievable after upgrading to MacOS 10.15+? Sorry, I don't mean to be difficult, I'm just trying to get as clear a picture as I can.

Maybe this Wiki article can help understand the WINE project:

https://en.wikipedia.org/wiki/Wine_(software)

wine32on64 is the necessary component in order to get WINE working on 64bit only versions of macOS 10.15+ since it takes advantage of a feature in macOS 10.15+ which allows 32bit code segments to work. Here is a snippet from a Codeweavers' developer on the WINE mailing list explaining it:

Our [Codeweavers] solution involves a custom version of the Clang compiler as well as modifications to Wine. It also relies on a new feature of macOS Catalina to allow the creation of 32-bit code segments in a 64-bit process. Our modified versions of Wine and Clang/LLVM are included in our source tarball at <https://www.codeweavers.com/products/more-information/source>. We hope to have a more convenient approach to sharing and collaborating on this in the future.

From a bit more very quick research, it appears Codeweavers' CrossOver Mac may be the only WINE implementation that will currently work on macOS 10.15+ because they had to create some special code within their toolchain to make it work as well as some modifications to the WINE code as well. The code is too complex and too much of a hack for them to bring it into the mainstream WINE project although they are trying to do so at some point. For those interested in the technical details, here are two of the relevant links I found from a footnote (#81) in the Wikipedia article I linked referencing a WINE mailing list (first link is very technical directed at programmers):

https://web.archive.org/web/20201111190220/https://www.winehq.org/pipermail/wine-devel/2019-December/156602.html

followed by another reply about how they get "wine32on64" to compile:

https://web.archive.org/web/20200806141408/https://www.winehq.org/pipermail/wine-devel/2019-December/157027.html

TLDR: If you want to use WINE on macOS 10.15+, then WINE must be used with "wine32on64" along with some special modifications to the WINE code....this is not something most users will do. For the average user, it seems the only choice at this time to run Windows apps on macOS 10.15+ using WINE is to use Codeweavers' CrossOver for Mac app.....at least until some other third party compiles a version of WINE to work on macOS 10.15+. This appears to work on Apple Silicon M-series Macs, but usually with performance issues due to the differing CPU architectures. I did not do an in-depth search for other options so there is a possibility they exist, but just didn't make it into the search results.

FWIW, I've never heard that and I don't believe it's possible.

FWIW, you may be able to run Mojave as a virtual machine in Parallels Desktop or VMWare Fusion on Monterey.