E-Maculation

Not sure; I think the Wineskin author has 64-bit-ized all their own code, and the main WINE engines are 64-bit now... so any 32-bit processes are likely spun up by the WINE engine itself :\ That could be trickier to resolve. Do you have a list of what processes you get that are 32-bit? We may be able to chase down the appropriate group based on who owns them. If it's just PE code that's 32-bit, then there's not much we can do, as WINE is not an emulator.

adespoton wrote:Do you have a list of what processes you get that are 32-bit? We may be able to chase down the appropriate group based on who owns them. If it's just PE code that's 32-bit, then there's not much we can do, as WINE is not an emulator.

Here are samples of the X86 processes I found when Wine was running in 64-bit mode with my Windows-based SheepShaver. I don't know if they're any use. As you can see, there were four processes, but only two names. Its beyond me to make any sense of this, I'm afraid, but I hope it may help someone else:

https://www.dropbox.com/s/v1ustzurmzr6h ... s.zip?dl=1

Please let me know when you've downloaded so that I can delete the file.

Downloaded

[edit] Yeah; so what WINE is doing here is creating equivalents to all of the libraries you would normally expect to find under Windows 95 and Windows XP -- which includes libraries like kernel32.dll. On modern Windows, you'll find kernel64.dll, which 64-bit Windows apps will call. Kernel32.dll (and a number of those other DLLs) are 32-bit, so will run as 32-bit processes in memory.

In order to get around this, not only WINE and Wineskin need to be 64-bit, but all the support libraries have to be 64-bit, and the software that's running has to be 64-bit and attempting to call the newer 64-bit libraries.

Modern Windows has both a "Program Files" and a "Program Files (x86)" folder -- the second is for 32-bit software. Likewise, in the Windows directory, there is a System32 directory and a SysWOW64 directory; the contents of those are the system executables for 32 and 54-bit mode. Any old software will be targeting the 32-bit libraries only, and these will run as 32-bit processes.

OK - I think I understand the general idea, but I suppose we don't know what this means for the future of macOS...

That about sums it up.

If Apple is intending to move from IA64 to an Apple chip, they'll llikely drop 32-bit support in the long-run. The Intel chipset has built-in 32-bit mode, so Apple doesn't really lose anything by enabling it there. But if they're streamlining the OS core so that iOS and OS X are using the same components, they might not present the 32 bit architecture via their own libraries.

As a result, 32-bit code *may* still run as long as it isn't relying on any 32-bit Apple libraries. Until Apple switches CPUs again. But if Apple switches CPUs, we're going to need to emulate, not just virtualize, so it would all break anyways.

I don't think there's much danger of Apple switching architectures any time soon, since ARM can't match Intel's performance at the moment, and in order to pull off the transition in the way Apple's done it in the past, ARM would have to greatly exceed Intel's performance in order to run any kind of decent Rosetta-like emulation for backward compatibility. So you think Apple will just suddenly cut off 100% of their existing software library, I wouldn't be too worried about that.

The likely reason that they're dropping 32-bit support, in my estimation, is that they want to get rid of the 32-bit libraries and frameworks. Keeping 32-bit support means that every one of them has to include two binaries, doubling the size of every library on the system. And since both Swift and Objective-C ARC require the 64-bit runtime on macOS, keeping the libraries 32-bit compatible means that the frameworks devs have to write everything in manually refcounted Objective-C, which I have to imagine would be getting old by now.

I agree completely... which is why I think 32-bit in the processor isn't going anywhere any time soon, but anything that touches Apple libraries or frameworks will be expected to talk 64-bit.

Since WINE acts as a glue between the raw instructions and the OS frameworks and libraries, as long as this interface is 64-bit, everything should function as expected. Unless, of course, Intel stops including the 32-bit instruction set in its pipelines to simplify things on it's end....

My backup was to create a Snow Leopard Server VM in Parallels and run it from there. It actually seems to run better than Sheepshaver in Sierra.

Heh... so to play Lode Runner Online, you install it in Mac OS under SheepShaver, which is installed in a SLS VM.

The extremes we go to to play old games....

But that said, I just realized I haven't tried playing that game under Classic on my 10.4.11 G4 Mini yet :D

Old games? Heck, I need it to run Frame-Mac which is the backbone of my Structural Engineering Business.
I have not found a better program and it is over 20 years old.