Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

64-bit (x64) builds for 64-bit Wine #57

Closed
pinobatch opened this issue Jun 12, 2019 · 21 comments
Closed

64-bit (x64) builds for 64-bit Wine #57

pinobatch opened this issue Jun 12, 2019 · 21 comments

Comments

@pinobatch
Copy link

If you've heard of the Catalina Wine Mixer, macOS 10.15 is the Catalina Wine Killer.

macOS 10.15, due for release in September or October, will drop multiarch and instead run only 64-bit executables. As I understand it, Wine on a 64-bit-only system can run only those Windows executables that are compiled for x64 (x86-64, AMD64), not x86. How hard would it be to build FCEUX (debugging version) for 64-bit Windows? Or will it become recommended to debug games running in FCEUX SDL by debugging FCEUX SDL itself?

@bbbradsmith
Copy link
Contributor

bbbradsmith commented Jun 12, 2019

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
Copy link
Author

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
Copy link

movsb commented Jun 13, 2019

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
Copy link
Contributor

bbbradsmith commented Jun 13, 2019

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
Copy link
Author

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
Copy link

movsb commented Jun 16, 2019

QQ20190616-115735

Yes, it's a 32bit executable.

@bbbradsmith
Copy link
Contributor

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
Copy link
Author

pinobatch commented Jun 21, 2019

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
Copy link
Contributor

bbbradsmith commented Jun 21, 2019

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
Copy link
Contributor

bbbradsmith commented Jun 22, 2019

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
Copy link
Contributor

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
Copy link

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

@bbbradsmith
Copy link
Contributor

bbbradsmith commented Jun 25, 2019

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
Copy link
Contributor

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

@bbbradsmith
Copy link
Contributor

bbbradsmith commented Jun 30, 2019

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
Copy link
Author

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
Copy link
Author

pinobatch commented Jul 1, 2019

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
Copy link
Contributor

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
Copy link

agg23 commented Jan 11, 2020

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

@bbbradsmith
Copy link
Contributor

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants