64-bit (x64) builds for 64-bit Wine about fceux

[bbbradsmith]

There's an x64 configuration in the Visual Studio project. It builds and runs just fine, as far as I can tell, at least on Windows, though I don't normally work with this build, so my testing is not extensive. You'll have to test it on Wine 64-bit on a Mac for yourself, though.

EDIT: this configuration is just an improperly named 32 bit configuration, so nevermind.

[pinobatch]

If you can slip me a test build, I'll test what I can in 64-bit Wine on Xubuntu. And if that works, I'll keep an eye out for Mac users who might be interested. (I myself don't use a Mac, but I'm in Discord servers with people who do.)

[movsb]

And if that works, I'll keep an eye out for Mac users who might be interested.

How I'd love to run FCEUX on macOS, but I find it so hard to make it. And its SDL2 branch is behind master for hundreds of commits.

Once upon a time, I was thinking about rewriting its UI the HTML way. 🤣

[bbbradsmith]

VC x64 build from current master: EDIT removed the build, it wasn't actually 64 bit, see below.

If you want continual builds, you might want to just fork the project and set up an appveyor for it.

[pinobatch]

I don't think that build is actually 64-bit

$ file /path/to/fceux.exe
/path/to/fceux.exe: PE32 executable (GUI) Intel 80386, for MS Windows
$ file /path/to/mptrack.exe 
/path/to/mptrack.exe: PE32+ executable (GUI) x86-64, for MS Windows

I'll read the AppVeyor docs as I get time.

[movsb]

Yes, it's a 32bit executable.

[bbbradsmith]

My apologies. I assumed the configuration labelled "x64" was a 64 bit build, but apparently the actual setting for that configuration was still Win32. Switching its platform setting to actually be x64, it no longer compiles.

[pinobatch]

Ubuntu will soon drop support for 32-bit libraries as well according to "I386 architecture will be dropped starting with eoan (Ubuntu 19.10)" by willcooke and "Ubuntu 19.10 will be 64 bit only" by Rosanne DiMesio, via "Wine Developers Concerned With Ubuntu Dropping 32-bit Support With Ubuntu 19.10" by Logix, via Slashdot. This means that one of five things will end up happening:

• A. Somebody figures out what causes FCEUX debugger to fail to compile under x64.
• B. Somebody creates, publishes, and maintains a snap that contains FCEUX debugger, Wine, and the 32-bit "core18" runtime.
• C. Following "Running Steam in a LXD system container" by Simos Xenitellis, somebody experiments with LXD containers to figure out what is and isn't needed to run FCEUX debugger in Wine in Ubuntu 18.04 LTS in a container in a more recent version of Ubuntu and then publishes a guide to doing so.
• D. Somebody prepares and publishes a guide on how to debug NES programs in FCEUX by debugging FCEUX SDL itself using GDB.
• E. FCEUX debugger users switch en masse to Mesen, and macOS users end up installing Xubuntu in a VM to run Mesen.

[bbbradsmith]

I started a branch on my fork to see how far I could get with setting up a 64 bit build.

With #62 to update a bunch of incompatible 32-bit Windows API usage I can get it to completely compile. I can't quite link because of #63 luaperks.lib, which I don't yet know the source of, but I think once a 64-bit version of that library can be found, it should link?

There's a lot of compiler warnings that should be investigated for 32-bit truncation. I'm definitely not expecting it to run without a bunch more work.

Also a lot of "windows" stuff is predicated on the WIN32 define, so I have it defining WIN32 on the WIN64 build as well. That should eventually be sorted out, but for this first pass the "WIN32" define basically has to mean both Win32 and x64.

There's also a reliance on very old DirectX 8 libraries. These are actually included in the github source tree. I managed to track down the last published version of the relevant libraries (dinput was the bottleneck), and luckily they did have 64 bit libs for them at the time (2007). That's another thing that should probably just be discarded eventually, but my focus right now is to find a minimal set of changes that will get it going.

There is a linker warning on dinput.lib that I am not sure about. May or may not be benign:
dinput.lib(dilib4.obj) : warning LNK4078: multiple '.text' sections found with different attributes (C0500040)

[bbbradsmith]

Alright, after Feos showed me where to find luaperks, I managed to get it to link and run! I still need to do a big pass over all the new warnings, but it looks at least minimally viable now! (See: bbbradsmith/fceux/win64_attempt)

Next step is going through all the warnings. (size_t is going to be a lot of noise here)

[bbbradsmith]

Hooked my fork up to appveyor in case anyone wants to try it. I'm still working on it, but it's already in a runnable state, it seems.

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

[vadosnaprimer]

I'd consider ability to run on 64bit Unix-like (Wine or not) a nice reason to make a new release.

[bbbradsmith]

So there are 64-bit LIB/DLL for Lua already in the repo. I needed to make a 64-bit build of the LuaPerks from tastools, which compiles and links fine, but the program just exits if I actually try to run a Lua script.

In FCEU_LoadLuaCode it gets as far as iplua_open, which goes into LuaPerks and eventually gets to iuplua_register_cb where it calls lua_call (which now goes into the Lua DLL) and the program exists with error code 1. That's as far as I got in debugging.

I tried a few different permutations of build settings for luaperks, different versions of lua 5.1.x, etc., but so far haven't come up with anything that works. I think the next step is to build lua from source to get a version with debug symbols (building the corresponding lua51.dll proxy is a little strange...) and keep drilling into this with the debugger but probably this is the point where I just put Lua on a to-do list and forget about it indefinitely.

Otherwise I still haven't found any other problems in testing yet. Games run. The debugger works, I think. I gotta try out more of the tools. I'm also still in the process of reviewing the enormous warning log from the build to see if there is anything suspicious.

[bbbradsmith]

Lua now seems to be working, I just had to produce some missing generated 64-bit precompiled lua stuff for LuaPerks.

[bbbradsmith]

The first pass on that seems to be fully functional at this point. There's a build here if anyone wants to test:
(after 6 months the build has expired)

[pinobatch]

This EXE is indeed for x86-64, and it's working in wine-3.6 (Ubuntu 3.6-1). I'll pass this one to Mac-using friends.

[pinobatch]

I had kmck from the NESdev and FamiTracker Discord servers try an AppVeyor build on Wine 4.0.1 under macOS 10.14.5 "Mojave". At first, with a 32-bit prefix, this error happened:

$ WINEPREFIX=~/.wine-fceux-32 wine ~/Wine/fceux_x64/fceux.exe 
wine: Bad EXE format for Z:\Users\keith\Wine\fceux_x64\fceux.exe.

Minutes later: "Runs fine with a 64-bit prefix. Cursory poking at debug tools seems normal. All in all, my verdict is working as expected in Wine."

[bbbradsmith]

The changes in #66 have now been merged into the main branch. I will be deleting the fork branch I tested it in, but I will leave its appveyor artifact up until it expires.

If someone wants to create their own 64-bit build with appveyor, the settings I used are attached in this appveyor.yml file.

appveyor.yml.txt

[agg23]

Why was the 64-bit build not added to the main Appveyor artifact drop?

[bbbradsmith]

Why wasn't it added? You're the first person who's actually asked for it.

zeromus' appveyor just does the win32 build, not any of the other targets. I dunno if he'd want to add x64 (or SDL/linux etc.) to it, but it's actually pretty easy to set up your own:

Just fork FCEUX to your own user-space, and set up an appveyor project on that. That's what I did when testing this build.

The setup for that is pretty simple. You can look at the YML above, which is very minimal. Other than selecting the configuration it's just a matter of including the 64-bit lua DLLs in the archive step.

[bbbradsmith]

Okay with #122 there is now a 64-bit build available in the appveyor.