Catalina Wine Killer. Is 64-bit FCEUX for Windows possible?

"Catalina Wine Mixer"? More like Catalina Wine Killer.

About a week ago, macOS 10.15 Catalina was demonstrated and made available as a beta test version. General availability is expected this September or October. The biggest change in macOS that affects retro game development is that 32-bit (i386/i686) executables no longer run. This affects few macOS native applications, as anything maintained will have been recompiled for x86-64. The greatest impact is on Win32 applications run in Wine, as well as Mono Winforms, which is still 32-bit.

The following will cease to function:

- FCEUX (NES debugger)
- Mesen (NES debugger) and all other programs using Mono
- FamiTracker (chiptune sequencer)
- All NO$ emulators

The following have experimental 64-bit builds with reduced functionality or stability:

- bgb (Game Boy debugger) isn't fully stable yet*
- OpenMPT doesn't run VSTs

As of today, the AppVeyor build of FCEUX for Windows is still 32-bit. Is a 64-bit build of FCEUX planned? Or will NES game developers using Catalina end up having to resort to step-debugging FCEUX SDL as an indirect means of step-debugging a ROM? Or buying a copy of Windows to run in a VM, provided the Mac even has enough RAM to run a VM? Or using Wine in Linux in a VM?

(In the process of looking for whether this was already requested, I discovered that download.html was still linking to SourceForge instead of GitHub. I have reported this as issue #57.)


* As for bgb in particular, Game Boy debugging on Mac is covered by SameBoy anyway.

Hmm. Is there really reason to believe 32 bit Wine will stop running as long as Wine itself is 64 bit? AFAIK, OS X isn't somehow preventing 32 bit instructions from running, they are just removing the 32 bit system libraries that native 32 bit code relies on. Wine itself is a regular 64 bit executable right?

I've opened Mesen's debugger out of curiosity, but never needed to actually use it... Must be lucky I guess? I use GDB/LLDB all the time for desktop dev, so I'm definitely not "just that good". Hehe.

Honestly the loss of 32-bit is a problem for Wine to solve. Its whole purpose is providing compatibility like that. Recompiling specific apps is not very effective in the larger scale of things. Perhaps it won't be able to in the long run, and a VM will be the only real option, though...

As far as FCEUX, its source is 64-bit compatible. The VS project already has a 64-bit configuration, and it builds just fine with a standard VS community installation. I expect its default binaries to remain 32-bit for a while yet though, just because Apple hates backward compatibility doesn't mean everyone else has the means to accommodate them. A significant number of people do still run FCEUX on 32-bit machines. (Maybe it's reasonable to have 2 builds in the appveyor step, I dunno.) Edit: there is no existing 64-bit configuration. It was just a mislabeled 32-bit configuration, apparently.


Also, it's not necessarily a given that a 64-bit build of FCEUX will run on 64 bit Wine on Mac. Some stuff is intractably incompatible. Though FCEUX probably would work, I would suggest a test is necessary before you can even consider this a viable solution to the "problem".


Ultimately it's not at all fair to put the burden of Apple's forced obsolescence march on unpaid open source developers, though. TBQH I don't think there's much incentive for any open source developer to keep up with Apple in this respect. Anything that works today isn't going to work in a few years anyway.

Maybe I'm missing something, because I'm wondering why MacOS ever would have offered 32bit application support. I thought Apple switched to Intel in 2006, in which case all of their processors would have been x86-64?

It's more complicated than you think, given all the nuances of what Apple provides and what they do. Their OS is kind of a mess and the kernel is a bit weird (see: Mach), and they don't even use commonplace ELF for binaries on *IX, they use their own Mach-O stuff. It is not a "rebuild everything with a 64-bit compiler and YOU'RE DONE!!!" situation. If it was, you'd think they'd have done that. Almost everything at Apple is custom built in-house at this point; even common FreeBSD utilities that share the same name/syntax/some of the code (permitted due to BSD license) do not behave even remotely similar. OS X is truly its own thing.

The company's first introduction into the 64-bit world was actually with their server junk -- the Xserve stuff -- during sometime in early 2008 I think (need to check on that). Desktop is a whole different matter. Let's not forget they continued to have to support PowerPC (where the platform supported 64-bit but they opted 32-bit early on) until I think 5 years later?

I think if you were to work at a larger corporation and see how this stuff happens internally -- that is to say, "how" major progress comes about and how slowly things move due to the nature of it all -- you might, respectfully, have more understanding as to why it isn't just something done at the flip of a switch, even when changing CPU architectures. Given your age, I'd suggest applying for an internship at Microsoft, Intel, or Apple and see if you're accepted. The few people I know who did that (ended up at Intel) found the exposure to be super enlightening -- a lot of "oh, okay, so that's why it takes so long!"

I never thought about that; it would have been nice if they had held off making the switch until x86-64 support had widened to the point they could forgo 32bit support altogether rather than supporting it temporally and dropping it later, but this isn't at all a good reason for them.


I figure that's a good idea; I don't know how many other people have gone and learned x86-64 assembly, SSE and all (not that I'll ever have to use it, however. ) I know C well enough to where I'm helping teach it at my university, so there's that.

At tepples' request I posted a current x64 build to the github issue he created:
https://github.com/TASVideos/fceux/issues/57#issuecomment-501825184
Edit: this turned out to be a mislabeled 32-bit build, unfortunately.

However, rather than relying on people to become human build machines for you, here's an alternative for someone who for whatever reason is incapable of using windows:

1. Fork the project on github
2. Set up appveyor to build your fork and create an artifact for you.

The above also goes for anyone that wants to test a small code change to FCEUX or similar project but doesn't want to set up a build environment. You can push your changes to your fork and get the resulting artifact from appveyor. It's certainly not an ideal way to iterate, and you don't get the advantage of an integrated debugger, but it works.

Appveyor is a free resource for any public project on github. (So are Travis CI, and Jenkins, among others.)


TBH, FCEUX is probably one of the easiest to set up open source projects I've seen, as least on Windows. The only real dependency is Visual Studio. VS Community is a big download, but it's not difficult to set up.

It worked, but file shows something suspicious: it's not 64-bit.

My apologies, the build configuration that was labelled "x64" was apparently mislabled, and really just a duplicate of the Win32 build, not an actual 64 bit build.

Huh, apparently not just an OS X problem.
https://www.linuxuprising.com/2019/06/w ... buntu.html

tl;dr The next major version of Ubuntu is dropping 32 bit packages as well, and the Wine devs are Concerned.

Huh... I really didn't think Wine used 32 bit libraries on a 64 bit system. Since Windows uses different ABIs it would have to translate the function calls anyway right? I figured that would just be automagically handled in the same way.

Wine has massive technical debt over assumptions that everything is 32-bit. The pcsx2 emulator is in a similar bunch, it can't even be compiled for 64-bit.

Several early Intel Macs were 32-bit only. First-generation Intel Core Solo and Core Duo processors did not have x86-64 support. In addition, several more early Intel Macs had 32-bit UEFI, so even though they had 64-bit capable CPUs, they could only boot in 32-bit mode.

Two versions of Wine are built: wine32, which runs 32-bit executables and makes 32-bit calls to the host's system libraries, and wine64, which runs 64-bit executables and makes 64-bit calls to the host's system libraries. Try to run a 32-bit executable in wine64, and it will apparently try to chainload wine32. If that's not installed, as will be the case in Ubuntu 19.10, it will display an error message:


The official workaround appears to be to install Ubuntu 18.04 LTS in an LXD container and run wine32 in that.

Yeah... I saw that... If you are going to run something in a VM to run Windows software I'm not sure why you wouldn't just run Windows. Pragmatism really has to win out over principle or even cost at some point. O_o

- No $119.99 per seat.
- No secret code that you can't in principle (at least hire someone to) audit.
- Less RAM and disk footprint and download bandwidth because it's a container, not a full-on VM, and you can strip down what's in the container to the minimum needed to run Wine32 and have the X server in the outer OS display the result.

I've said it a bunch of times but Windows 10 is effectively free to use in an un-activated state, in any sense that has real consequences. Microsoft isn't going to print you a certificate saying they are glad you're doing it, but it really doesn't require a $120 purchase if all you want is something you can test with. You can download it directly from Microsoft here.


Anyhow, after more hours than I had hoped, I seem to have FCEUX building in Windows x64. It runs games. The debugger seems to work. I don't expect everything to work just yet, but it's already at least minimally viable.

It's an ongoing project, but I've left progress notes at tepples' github issue, and I've created an AppVeyor project for my fork to produce builds as I'm working on it:

https://ci.appveyor.com/project/bbbradsmith/fceux/build/artifacts

I did specifically say pragmatism eventually winning out over cost and principle. I do get it though, especially the principle part. Despite owning several copies of Windows, I rarely use it because I simply don't like to.



Interesting, I didn't know that was possible. I've used Docker containers on a couple occasions, but didn't know containers got that fancy.

A VM running an unactivated copy of Windows 10 still uses more CPU, RAM, and disk space than Wine.

Canonical appears to have since backpedaled somewhat, pledging to maintain enough packages to keep Wine, Ubuntu Studio, and games running. (Source: "Statement on 32-bit i386 packages for Ubuntu 19.10 and 20.04 LTS" by Canonical, via "Ubuntu 19.10 drops 32-bit images, pledges to maintain some packages after user outcry" by James Sanders)

Despite this, an x64 build of the debugger remains important for macOS users and for users who want to save HDD space and Internet data quota overage fees by installing only Wine64.

My first pass on getting FCEUX to build as a Win64 app is complete. Everything I've tested so far seems to be working, but if anyone wants to give it a shake here's the appveyor build:
https://ci.appveyor.com/project/bbbradsmith/fceux/build/artifacts