Mostly we code...sometimes we write. Every once in a while, we podcast.

Introduction
By: Jana Schmid

We just finished stuffing our mouths with tacos (Tuesday + Apple Event = Taco Tuesday Event at CodeWeavers) as we watched in anticipation the Apple Event 2019. Our fingers were crossed while clenching our good luck charm(s) of choice (four leaf clovers, horseshoe charms, fuzzy dice, rabbit foot keychains and dreamcatchers) hoping that there would be a clue as to when Catalina, the latest macOS would be released.

We got nothing. Except an update to their website after the Apple Event mentioning a vague  October release. Welp. At least that buys us a little bit more time than say any Tuesday in September.

So no, we don’t have anything for Catalina yet, but we do have is an explanation of the technical curveballs we’ve been thrown, the progress we have made, the time we see fit for us to release a CrossOver compatible Catalina, guidance for you from our support team and a gesture of goodwill if our product happens not work on Catalina when it is released.

>>> Join our 'macOS Catalina Update' mailing list

The Technical Curveballs
By: Ken Thomases

With the release of macOS 10.15 (Catalina), Apple has dropped support for running 32-bit executables and removed the 32-bit versions of system frameworks and libraries.  Most Windows applications our users run with CrossOver are 32-bit and CrossOver uses a 32-bit Mac executable, system frameworks, and libraries to run them.  This will break with Catalina.  (Even 64-bit Windows applications usually have 32-bit installers.)

Mind Your Bitness
-----------------

What's with this 32-bit and 64-bit business, anyway?  "Bitness" is an element of CPU architecture.  It indicates what size numbers the CPU can "naturally" and efficiently work with.  Software can work with arbitrarily large numbers by building on the capability of the hardware, but the hardware itself can only directly handle numbers of the specified bitness or smaller.

Bitness also governs how much memory the hardware can directly access.  With 32 bits, the CPU can directly access at most 4GB of memory.  With 64 bits, it can access up to 256TB (about 65,000 times as much).  (In theory, 64 bits can represent 4 billion times as much, but CPUs don't actually support that, yet.)

Over the years, personal computers have gone from being 8-bit to 16-bit, 32-bit, and now 64-bit.  Within the Intel-based CPU family used in Macs, each time the bitness increases, the hardware has maintained a degree of backward compatibility so that the existing body of software can continue to run.  However, the operating system (OS) has to manage and support the different modes of the CPU to maintain this backward compatibility.

Application software is built for a particular bitness.  So, some software is 32-bit and other software is 64-bit.  At a low level, software is just a sequence of bytes (small numbers).  The CPU interprets these bytes as instructions.  The translation from bytes to instructions is similar between 32-bit and 64-bit, but not identical.  And, in computing, close is not enough.  An attempt to interpret a byte sequence which was encoded from 32-bit instructions as though it were 64-bit instructions, or vice versa, will fail.  The program would crash almost immediately.

When a 64-bit CPU needs to run 32-bit software, the OS switches it to a 32-bit-compatibility mode so it knows to interpret the bytes of that software as 32-bit instructions.  More than that, the CPU has to behave in the same manner as a 32-bit CPU would behave, so the instructions produce the intended results.

When the CPU needs to run 64-bit software, the OS switches it to its 64-bit mode.  In this mode it interprets instruction bytes as 64-bit instructions and enables the greater functionality that 64-bit provides.

Application software has to interact with more than just the CPU.  A lot of the functionality of modern OSes is provided to applications in the form of system frameworks and libraries.  This includes the ability to present windows and graphics on the screen, accept user input from the keyboard and mouse, play sound, etc.  A 32-bit application needs 32-bit system frameworks and libraries; a 64-bit application needs 64-bit system frameworks and libraries.

Therein Lies the Problem
------------------------

Catalina won't run 32-bit executables.  It doesn't support 32-bit processes.  It doesn't provide 32-bit system frameworks and libraries.  In short, it won't run the 32-bit components that CrossOver has traditionally used to run 32-bit Windows applications.

So, we needed to find another way.  We need to run 32-bit code within a 64-bit process which uses 64-bit system libraries to access OS functionality.

The CPUs in Macs still support the 32-bit-compatibility mode.  Catalina does still provide a way for us to run certain specific code in this 32-bit mode in an otherwise 64-bit process.  One challenge is to find a way to switch modes back and forth as needed when switching between the two types of code.

Another challenge is to maintain an environment in a 64-bit process that a 32-bit process can cope with.  For example, all code and data that the 32-bit code needs to interact with must be within the bottom 4GB of memory.  Recall that 32-bit code can only access up to 4GB of memory.

Relatedly, memory addresses ("pointers") are used frequently in the interface between Windows applications and the Windows OS.  Since CrossOver is substituting for the Windows OS, it needs to have the same interface with the Windows application as Windows does.  For 32-bit software, pointers are 32 bits in size.  For 64-bit software, pointers are 64 bits in size.  We needed to find a way to write software that understands both 32-bit pointers (for interfacing with Windows apps) and 64-bit pointers (for interfacing with system libraries).

The Progress
By: Ken Thomases

Working on a Solution
---------------------

The technology that CrossOver uses to run Windows apps on macOS is called Wine.  It is a large, complex piece of software.  The changes required to overcome these challenges would entail changing behavior throughout Wine.  That would be an exceedingly large job if we attempted to do it manually.

To pare that down by a lot, we rely on a tool that's already central to governing Wine's behavior: the compiler.  A compiler is a tool used by software developers to translate source code into the instruction byte sequences that CPUs can directly execute.  We have built a modified version of the standard C language compiler for macOS, Clang, to automate many of the changes we need to make to Wine's behavior without pervasive changes to Wine's source code.

First, our version of Clang understands both 32- and 64-bit pointers.  We are able to control from a broad level down to a detailed level which pointers in Wine's source code need to be 32-bit and which 64-bit.  Any code which substitutes for Windows at the interface with the Windows app has to use 32-bit pointers.  On the other hand, the interfaces to the system libraries are always 64-bit.

There are places in Wine where it receives pointers to data from the system libraries and needs to pass that data along to Windows code. 

This is a problem.  The Windows code won't be able to handle the 64-bit pointers returned from the system libraries.  If we tried to just pass the pointer through as-is, the top 32 bits of the 64-bit pointer would be lopped off, resulting in a pointer that points to the wrong place.

So, we have to manually address such cases.  But first, we need to find them!  Doing so by poring over the code and considering each place where one pointer is copied to another would take way too long and be too prone to errors.  To that end, our version of Clang will flag such places in the code as errors during compilation, forcing us to fix them, but allowing us to be confident that the remaining code is correct.

Next, our Clang needs to recognize places in our code where 64-bit Wine code may need to call 32-bit Windows code, and vice versa.  It needs to compile our code in such a way that smooths that transition.  "Normal" Wine already had to do some of that, but this is much more extensive.  Our Clang generates "thunks", small pieces of code which mediate a transition between two other pieces of code.  Where Wine's 64-bit code needs to call 32-bit code from a Windows app, Clang generates a 64-bit-to-32-bit thunk.  Where Wine needs to provide an entry point for 32-bit Windows code to call what it thinks is a 32-bit Windows function, but which is actually implemented as a 64-bit function in Wine, Clang generates a 32-bit-to-64-bit thunk.  Those thunks manage switching between the two modes of the CPU.

With these tools (and some others), we have been able to make good progress!  But, unfortunately, not enough to be ready to release when Catalina is released.  Work continues!

The Timeline
By: Ulrich Czekalla and James Ramey

2017 The Beginning of the End
-----------------

In mid-2017, Apple first hinted that it was ending / dropping 32-bit support at some time in an upcoming macOS release.  At first glance, it would appear that software developers were given ample warning that their 32-bit software applications would cease to work and that action would be required.  While this is largely true, it does not paint an accurate picture of the actual timeline.  While Apple did make this announcement in 2017, it wasn’t until the release of Mojave (macOS 10.14) on September 24, 2018 that the clock started ticking.  With the release of Mojave (actually the initial betas of Mojave earlier in June), it became more clearer to our development team how 32-bit support would be phased out and how 64-bit support would be fully implemented and the basic requirements CodeWeavers was going to have to implement in CrossOver 19 to remain compatible.  Keep in mind that updating CrossOver itself to 64bit isn’t the problem. The challenge is to continue executing 32-bit Windows applications on an operating system that no longer supports 32-bit code and do it in a way that maintains the existing seemless execution of Windows applications on macOS. From that moment, we assembled a team to design and implement a solution for CrossOver (roughly 14 months ago).

2018 The Middle of the End
-----------------

Without any build of Catalina (macOS 10.15), our development team was left to somewhat speculate as to how 32-bit functionality could be sustained.  There was considerable brain power spent on defining the best available solutions based on the most probable constraints.  Theoretically, the work ahead all seemed rather possible; however, the team could only assume how virtualizing 32-bit support on a 64-bit OS would impact application performance OR how a single type of solution could account for 64-bit applications that used 32-bit launchers.  And with more questions than answers, the team could only speculate as to other possible issues.

2019 The End?
-----------------

Fast forward to June 24, 2019 and Apple’s announcement and 1st public beta release of Catalina (macOS 10.15).  With the release of the first public beta of Catalina, our development team was finally able to test theories and assess the state of the CrossOver 19 software.  As expected, CrossOver 19 was severely broken on Catalina.  From that moment and through today, our team has gone about implementing the ‘plumbing’ required for baseline compatibility.  Over the course of this time, they made significant progress in getting a 32-bit test application (NotePad) to work in CrossOver 19.  They have also identified other critical issues that need to be resolved in order to provide broader support to 32-bit applications.  And (most importantly) the team has gotten CrossOver 19 to a stage where it can be installed and run on other Apple computers with similar (if not same) results.  All of which is critical to most rapidly finding and fixing bugs and getting CrossOver 19 to an alpha / beta release.

Our current goal is to provide an alpha build of CrossOver 19 to customers within the next 30 – 60 days.  Ideally with our expedited efforts, we can deliver a usable software sooner; however, supporting 32-bit applications on a 64-bit OS is a daunting challenge (one that only CodeWeavers is even attempting).  Our team of developers is exceptionally talented and incredibly persistent; but again, this is the type of technical challenge that few other companies could resolve.  And while two years (on paper) to resolve such an issue seems plausible, the reality is that our development team has really only one year to develop a solution and only a couple of months with Catalina to develop and implement a solution.  

The Guidance
By: Ryan Abhiram and Brian Mathieu

Until CrossOver 19 is released, Windows applications will not be able to run on macOS 10.15. If you see a notification prompting you to update to macOS Catalina, you can simply dismiss the message and everything will continue running as it currently does.

If already have updated to macOS Catalina or do so accidentally, you have two options. The first options is to wait for CrossOver 19 to be released, and to go without any Windows applications you have in CrossOver. This will not be the preferred option for most users.

The second option is to revert back to a point before you upgraded macOS. If you already had a Time Machine backup before installing Catalina, you can reinstall the system and restore from your backup. Note that this will erase any data or changes made to the system after the macOS update. Detailed instructions from Apple for this can be found at https://support.apple.com/guid...

If you do not already have a backup, there is still hope. You can attach an external hard drive and create your first Time Machine backup. After the backup is complete, contact Apple for help installing a previous version of macOS and manually migrating your information. There are not tools to do this automatically for you, so you will want to make sure you have the guidance of the Genius Bar or Apple Phone Support (1-800-275-2273).

The Goodwill
By: Jana Schmid

So here’s the deal. We’re good people. And if our product temporarily cannot work, we believe that you shouldn’t have to pay for it. Anyone with an active CrossOver macOS license as of September 10, 2019 will automatically get a free three month support extension until we can get CrossOver 19 working on Catalina. If we need to add more, we will add more. If we get CrossOver 19 up and running in two months, you still will get your three months of additional support.

Example: Bruce’s one year CrossOver license expires on September 30, 2019. Because CrossOver 19 for Catalina is not quite ready, CodeWeavers added three months to his subscription. Now Bruce’s license doesn’t expire until December 30, 2019. Bruce is happy and sleeps well at night knowing that he is supporting the open-source community with his patronage.  

>>> Stay up to date on our progress with Catalina, join our 'macOS Catalina Update' mailing list

>>> CrossOver for Catalina Progress — October 3, 2019

About Jana Schmid
Jana has been working in the marketing profession for over 15 years. She joined the CodeWeavers marketing department in 2010 and has earned oddities such as the Margaritaville Tahiti Frozen Concoction Maker and a lifetime supply of sparkling water for her performance as Marketing Director. Contact Jana at jana@codeweavers.com and learn more about her professional accomplishments on LinkedIn.

About James B. Ramey
James B. Ramey is the CEO of CodeWeavers. His life long love of video gaming started at the tender age of six with an Atari 2600 and evolved over time to include Nintendo, Super Nintendo, Apple Mac IIc, Windows PC, and MacBook Pro. When not fiddling with technology, James enjoys cooking, travel, debating politics in the office, and spending time with his wife, daughter, and their two rescue dogs. For the past 20 years, James has worked with clients around the world in best implementing technology to maximize a return on their investment. He is a graduate of Moorhead State University and earned his MBA from the University of Phoenix. You can find James on Twitter at @jbramey.

About Brian
Brian joined CodeWeavers in 2017 after working undercover at Apple for seven years. He currently holds a degree in satire but doesn’t like to brag about it. He is a member of the CodeWeavers Support team, so if you have a problem getting your application to run, there’s a good chance you’ll be hearing from him.

About Ryan
I was born and raised in the Caribbean, moved to Minnesota over 20 years ago — don’t ask why, it’s a story to be told over beer. I love movies, music - metal, blues, 80's and reggae. Didn't have a firm idea what i wanted to be when i grew up, just went with the flow of things. I entered the world of Apple while I was in college and worked for the company for 6 years. Now I bring my prowess and experience to CodeWeavers!