It is currently Wed Jul 17, 2019 6:34 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 19 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Wed Jun 12, 2019 7:12 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21506
Location: NE Indiana, USA (NTSC)
"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.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Wed Jun 12, 2019 9:36 am 
Offline
User avatar

Joined: Fri Nov 24, 2017 2:40 pm
Posts: 168
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.


Top
 Profile  
 
PostPosted: Wed Jun 12, 2019 9:43 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7527
Location: Canada
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.


Last edited by rainwarrior on Sun Jun 16, 2019 2:43 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Wed Jun 12, 2019 8:17 pm 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3501
Location: Richmond, Virginia
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?


Top
 Profile  
 
PostPosted: Wed Jun 12, 2019 9:05 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4152
Location: A world gone mad
Drew Sebastino wrote:
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!"


Top
 Profile  
 
PostPosted: Wed Jun 12, 2019 9:59 pm 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3501
Location: Richmond, Virginia
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.

Quote:
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 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. :lol:) I know C well enough to where I'm helping teach it at my university, so there's that.


Top
 Profile  
 
PostPosted: Thu Jun 13, 2019 11:36 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7527
Location: Canada
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.


Last edited by rainwarrior on Sun Jun 16, 2019 2:43 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sat Jun 15, 2019 1:17 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21506
Location: NE Indiana, USA (NTSC)
It worked, but file shows something suspicious: it's not 64-bit.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Sun Jun 16, 2019 2:41 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7527
Location: Canada
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.


Top
 Profile  
 
PostPosted: Fri Jun 21, 2019 9:12 am 
Offline
User avatar

Joined: Fri Nov 24, 2017 2:40 pm
Posts: 168
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.


Top
 Profile  
 
PostPosted: Fri Jun 21, 2019 10:04 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 956
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.


Top
 Profile  
 
PostPosted: Fri Jun 21, 2019 10:41 am 
Offline
User avatar

Joined: Sat May 04, 2013 6:44 am
Posts: 42
Drew Sebastino wrote:
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?
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.


Top
 Profile  
 
PostPosted: Fri Jun 21, 2019 11:06 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21506
Location: NE Indiana, USA (NTSC)
slembcke wrote:
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?

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:
Code:
it looks like wine32 is missing, you should install it.
multiarch needs to be enabled first.  as root, please
execute "dpkg --add-architecture i386 && apt-get update &&
apt-get install wine32"
wine: Bad EXE format for Z:\path\to\fceux.exe.


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

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Fri Jun 21, 2019 10:01 pm 
Offline
User avatar

Joined: Fri Nov 24, 2017 2:40 pm
Posts: 168
tepples wrote:
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


Top
 Profile  
 
PostPosted: Fri Jun 21, 2019 10:05 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21506
Location: NE Indiana, USA (NTSC)
slembcke wrote:
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.

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

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 19 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group