ETA on MacOS Catalina 64 bit fix?

Jan, I love Pro Motion and am on a Mac. I also have a nice Windows pc that I game on. I just don’t want to have to work on pixel art on Windows, then get the files to my Mac for dev work. I find it sort of unacceptable for Pro Motion to be down for months with no Catalina fix, when it was announced for a year that 64bit was coming, and no apparent timeline for a speedy update. I can certainly appreciate how much work it can be but …

So please, any ETA on an update for Catalina? Is it even a high priority concern at this point?

Jan, others…

FWIW, I found that updating to CrossOver v19 ($40) on the Mac worked. CrossOver v18.x did not work and I had to upgrade to 19. You can install the latest Pro Motion Windows version and so far it seems to work pretty well.

So, this is a possible solution for people, but comes with the cost of buying CrossOver to run Windows apps on their Mac, which is ok with me. Long as it works.

@georgeb, I’m glad to read that CrossOver solved the issue for you.
I was about to buy a Mac this year, but when I read of 32-bits support being dropped I changed my mind, because I was going to work with/on many legacy application that are only available as 32-bit apps.

In the Downloads » Mac OS and Linux page it states:

Currently the software does not run under the new Mac OSX Catalina because it does not allow 32Bit software anymore! Two things are to be solved, Pro Motion must become a 64Bit application which is planned to be done with 2020. The Wine authors must create a compatible 64Bit version. They are already working hard on it.

So it looks like the real problem right now is the lack of a 64-bit version of Wine, not so much the lack of a 64-bit version of PM NG.

If my understanding is correct, when Wine x64 will be released it should also support running 32-bit apps (just like CrossOver) for it should re-introduce 32-bit drivers implemented in x64 — I’m asking confirmation for this, for when this happens I might consider again buying a Mac myself, but not before.

So, any feedback on the various ways that PM NG can be run on Catalina is much appreciated.

Question: does Catalina natively support mounting virtual machines (like VMWare Workstation Player and VirtualBox)? If a full Win OS could be mounted on the hypervisor, PMNG should be usable since Win x64 editions always support running 32-bit apps natively — after all, the x86-64 architecure is designed to support 32-bit under “legacy mode/protected” and “long mode/compatiblity”, it’s just Apple that arbitrarily decided to deny macOS users from using the full power of their hardware.

Using a VM with Win OS could be an alternative solution, although it would still require a full license for Windows (and the VM hypervisor, if macOS doesn’t provide/have a free one).

I think you could run Pro Motion / Windows apps via something like BootCamp (with Windows 10 install) or Parallels (same thing on Windows 10 install). I used to run Parallels but got tired of the bloat and how slow it was. I’ve opted for CrossOver for running random Windows apps like WinAmp or whatever.

Good luck. A Mac is a great pc, but there will be compromises if you really need lots of Windows software. If you are a heavy Windows app user it may not be worth it.

Even running Pro Motion on Crossover I’m sure it’s many times slower than on a Windows PC. I’m going to test that soon just to see, but I can feel lag in things, vs something native on a Mac. It’s just how it is. Compromises. The only thing that isn’t a lot of compromise is BootCamp.

Hi @georgeb

it’s good to hear that Crossover for Catalina also runs 32Bit Windows apps. But yet there is no ETA of 64Bit Wine for Mac, so I have to wait until this is available. I will update the information on my site to point Catalina users to CrossOver.


Unfortunately, memory bloat, performance loss and occasional lags are inevitable with any emulation solution.

My guess is that the best solution would be to target a Win NT virtual machine, instead of Win 10, due to the smaller memory requirements of the former. I’m not sure if PM could run on Win NT, but if it does it would be worth looking into it, especially since many parts of Win NT are now freely reusable, and there are some open source Windows alternatives that are based on NT (none complete yet, as far as I can remember).

Emulating a Win 10 x64 OS and then run a 32-bit would mean emulating an x86_64 machine, which in turn has to switch to 32-bit mode to run the 32-bit app, all of which adds layers of emulation to emulation itself (so no wonder that it ends up in a huge bloat and performance lag).

I remember that during the XP days I would use nLite to customize the ISO image of the Win XP installation CD, to remove unwanted services and components in order to create a lighter version of Windows, so I could create a slim installer for netbooks that had serious memory and processor limitations. While it seems that nLite has now been updated to support later Win version (including Win 10), when it comes to virtual machines it’s always best to use the lightest (i.e. older) OS version that work, and to strip it from all unnecessary services.

From what I can remember, via nLite I managed to reduce the XP CD down to a third of its size, and the resulting Win installation was much faster that the standard installation (there are so many services that ship with Windows which one could do without).

@jan.cosmigo, since nLite is legal to use (on one’s own licensed Windows installer), it should be possible to share nLite configurations to reduce the size of the various Win editions. Legitimate owners of Windows could then apply those configurations on their ISO images, using the nLite tool (used to be free, but it seems newer versions are not), and be able to create lightweight versions of the Win OS to mount as virtual machines on macOS and Linux.

Since Windows licenses also cover previous Windows versions (at least, this is what I remember), it should be possible to create a dedicate ISO image of the older Win OS version that supports running PM NG — if possible, using the 32-bit version of Windows, if available, so that the performance loss from switching from x64 to 32-bit emulation mode is avoided entirely. Also, older version of nLite (e.g. for XP) are completely free to use.

Hi @tajmone

thanks for this information. It’s always interesting how many win-like systems are around. You also pointed to ReactOS. I checked it but ran into different errors. ntlite looks promising and I’ll check that out.
Generally CrossOver/Wine should not lead to much performance loss because Wine Is Not an Emulator :wink:
It’s an implementation of the Windows API for the respective systems.

But it’s really a pain in the ass that 32Bit-support was removed with Catalina. There is a 64Bit Wine that should work for Catalina but it requires me to first port PM to 64Bit. This is of course possible, but just don’t have the time at the moment.
CrossOver also runs 32Bit applications on Catalina so this is a good way to go. It’s not too expensive I think and you can run lots of Windows Apps with it. Everyone that can afford Apples high price tag, can afford CrossOver and as a side effect this cross finances the development of Wine which is the Open Source brother of CrossOver or the engine under the hood to say so.


Interesting. Does this mean that it’s either the 32-bit OR the 64-bit API, or does Wine x64 also support running 32-bits application?

Everyone that can afford Apples high price tag, can afford CrossOver


and as a side effect this cross finances the development of Wine

that’s nice.

But it’s really a pain in the ass that 32Bit-support was removed with Catalina.

I fail to understand the logic in that. I wonder if it’s only due to maintenance work or if the goal is to improve the OS performance by stripping it of all the 32-bit components.

I can understand that Linux distros might drop official support for 32-bit, since it’s open source and third parties could still develop the 32-bit drivers and components independently. But macOS is closed source and proprietary, so it’s really a bad choice to drop 32-bit.

First of all, there is a huge heritage of legacy 32-bit apps that become unusable (or hard to use, especially if one need to interface them with x64 apps). The worst impact is for Assembly programmer, which can no longer work on 32-bit code, and more so on ASM students, who are now forced to start learning using x64 Assembly (which is harder than 32-bit to learn).

I just don’t see the point in using the x86_64 architecture if you’re going to prevent access to 32-bit mode — I mean, the whole philosophy of x86 processors is build around backward compatibility, which is why these processors consume so much power in comparison to other processors (e.g. RISC) and the rationale that justifies the over-bloated ISA of x86_64 processors. Why did Apple switch to x86 at all? Why not switch to RISC processors if they don’t care about 32-bit support? by moving to ARM processors they’d gain speed and produce notebooks that consume less power. It doesn’t make sense to me.

it requires me to first port PM to 64Bit. This is of course possible, but just don’t have the time at the moment.

Not only a pain, but an unnecessary one too. I can see little benefits in having a 64-bit version of PM. It would only bloat memory consumption by using double-sized pointers, and have little positive impact on its performance (I doubt any pixel artists works on huge images).

I guess that once you port PM to x64 it won’t make sense to keep the 32-bit version anymore (I mean, only really old machine would be 32-bit only, and probably they would run older version of Windows, which don’t support modern features like DPI awareness, or new tablet drivers).

I really hope that a solution can be found that doesn’t require porting PM to 64-bit. It seems just an unnecessary step.

I guess you can have just two different Wine libs in a single application like CrossOver. It will then create a “prefix” matching to the app you want to execute. A “prefix” is a Wine term and it is something like a sandbox your Windows app is running in, IIRC. So you need a 32Bit sandbox for 32Bit apps and a 64Bit sandbox for a 64Bit app.
But I have no idea what they did to run a 32Bit app in a 64Bit sandbox which is obviously working on Catalina.

Porting PM to 64Bit can also be seen as a natural step. Don’t know if it will improve or downgrade performance. It will increase the memory footprint, this should be for sure.
PM contains some assembly routines. This is hard to understand from the today’s view but this roots back to 1997 when the first version was created. At that time it helped to improve speed, although I never compared it to when using high level implementations of that functions which I will do so when porting to 64Bit. I might keep some assembly routines when it makes sense and port them, too. It’s only a handful.
But of course it makes it all more complicated…DLLs need to have two versions… even need to check if the installer has a 64Bit version etc. .
So, yes, I might drop the 32Bit version. Not sure at the moment, though. Time will show.

That probably depends on how smart the compiler is at optimizing. But as a general rule, the x64 version should be faster thanks to the higher number of available registers, which can prevent memory accesses. Whether this gain would be perceivable by humans in another matter altogether, since we’re speaking of micro-seconds, but probably when processing big images it might feel faster.

Very cool! :sunglasses:

Converting those to x64 is going to be a pain, unless you merely change prefixes (e.g. EAX to RAX) and use the x64 version of the same instructions. I guess that in order to optimize performance these would have to bee rewritten using the x64 instructions set. Since these routines are so hold, chances are that the Delphi compiler might actually turn out faster since it might exploit the new x8086 ISA extensions that have become common standard in motherboards in the meantime.

I was recently reading Michael Abrash’s classic Graphics Programming Black Book (1997) on Assembly optimization for graphics application (such a wonderful book). The problem is that most of these gems no longer apply to modern processors and motherboards due to how Out-Of-Order Execution plays out nowadays, as well as the improvements in motherboards components and peripherals — but, of course, the general principles and Abrash’s method still holds true.

The problem with keeping the 32-bit version along with the new x64 version is that, at any time, a new coding necessity might enter the scene which might work only for the x64 version (or require a lot of work to function also with 32-bit). With so many major OSs moving away from 32-bit support, chances are that relying on the availability of 32-bit versions of third party components will become increasingly hazardous as time passes (IMO).

I also think that I will be moving away from the assembly code. With today’s machines it should be useless. I rather include multi core usage. Already experimenting with it, but will use it for some few operations only, e.g. layer rendering which, by it’s nature can be separated into several pixel areas that can be rendered in parallel using multiple threads on different cores.