It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
avatar
triock: With rumours about Apple switching from Intel to ARM-based CPU in their Macs this should be the last thing you should be worried about. :p
What exactly would be gained by that?
avatar
DreamedArtist: I am happy for everything going 64bit but I am sure there is always a work around for this stuff. Software emulation has come a long way for playing old games, so that means now I need to prepare myself for what's coming to my damn macbook soon....

As many knowledgeable people are posting the dosbox is the best work around for things now. but maybe wine at some point might update to combat this change.?
Which would only work if Apple bothered to keep around 32-bit libs. Which considering how much of a headless chicken the company is without Steve or Woz, they will probably charge headlong back into the failed waters of the Legacy Free PC. They already removed the Ethernet, function keys, the 3.5 millimeter jack and more.
avatar
kbnrylaec: Many geeks write new 32-bit codes on DOSBox for convenient.
The use of the word "codes" sounds rather awkward in this context.

The word "programs" would probably work better.
avatar
triock: With rumours about Apple switching from Intel to ARM-based CPU in their Macs this should be the last thing you should be worried about. :p
avatar
Darvond: What exactly would be gained by that?
Lol, seriously? They wouldn't have to pay to Intel, so moar monies for Apple.
avatar
tinyE: FAKE NEWS

We all know there is no longer such a thing as a "Mac User". :D
you might wanna think twice 'bout it ;D
avatar
Darvond: What exactly would be gained by that?
avatar
triock: Lol, seriously? They wouldn't have to pay to Intel, so moar monies for Apple.
Apple's history is full of CPU changing.
I would not be surprised if they really switching from x86-64 to ARM-based CPU.

--
Apple ][ family:
1977 Apple ][: MOS 6502
1986 Apple IIgs: 65816

Mac family:
1984 Macintosh 128K: Motorola 68000
1994 Power Macintosh 6100: PowerPC 601
2006 iMac Core Duo: x86
2006 MacBook Pro: x86
avatar
01kipper: Source: https://www.paulthetall.com/future-wine-mac-wine-dead-mac-18-months/

Summary: MacOS will be switching entirely to 64-bit and will no longer support 32-bit. Therefore, all 32-bit windows games will no longer be playable with WINE. This will probably be coming by 10.14 if not sooner.

In addition, I believe Boxer (which runs DOS games) will no longer run because the underlying DOSBox is not 64-bit. I assume this would also apply to many native mac games too. EDIT/UPDATE: A 64-bit Boxer should be entirely possible, so DOS games will likely still be able to be played.

Therefore GOG will no longer be able to support any newer MacOS at all for all games which are not 64-bit.

It looks to me like the only solutions are to not upgrade to a new MacOS, or bootcamp.

I don't know about all this technical stuff, I'm just going by what I'm reading, but it looks like retro gaming on a Mac will be totally lost :'(.
Thank you for the update. Confirming dark suspicions Apple no longer serves its own ideals. Ofcourse, we knew it. It has been going on for years now.

Another incentive -for me personally- to consider alternatives.
avatar
kbnrylaec: If you want to use multilib, you have to enable it in OS kernel.
Otherwise it will be damn difficult to support 32/64 bit execution at the same time.
I wonder. If syscalls are made through a library (e.g. libc), then it should be easy enough to write a shim that presents the program with the old 32-bit ABI while talking 64-bit system calls to the kernel. A small emulation layer if you will.

The other main thing is avoiding 64-bit addresses. This probably means you need to relocate the stack -- pretty simple, because the kernel & cpu are rather ignorant about it (unfortunately). And then you need to make sure the binaries (including libraries) are loaded in the low 32-bit space. This might be doable with just the right magic in ELF headers; at least statically linked, non-relocatable binaries can specify fixed addresses to use. If there is no built-in support for such magic, then it's still possible to provide a custom runtime link editor (ld.so is just another program). Then all you really need is the ability to tell mmap to either give you allocations in a fixed address, or anywhere in the 32-bit space. I believe both are commonly supported features. You may have to circumvent libc malloc in a similar manner, providing a custom version that uses mmap with low addresses.

Does the kernel hand out any other buffers (e.g. for graphics, audio), or are they all allocated by the application? If such things are provided by the kernel, then you also need the shim to use some bounce buffers. Of course this all has some overhead. But we're talking about running old games on recent systems.

It sounds like a fun nut to try and crack.
avatar
kbnrylaec: If you want to use multilib, you have to enable it in OS kernel.
Otherwise it will be damn difficult to support 32/64 bit execution at the same time.
avatar
clarry: I wonder. If syscalls are made through a library (e.g. libc), then it should be easy enough to write a shim that presents the program with the old 32-bit ABI while talking 64-bit system calls to the kernel. A small emulation layer if you will.

The other main thing is avoiding 64-bit addresses. This probably means you need to relocate the stack -- pretty simple, because the kernel & cpu are rather ignorant about it (unfortunately). And then you need to make sure the binaries (including libraries) are loaded in the low 32-bit space. This might be doable with just the right magic in ELF headers; at least statically linked, non-relocatable binaries can specify fixed addresses to use. If there is no built-in support for such magic, then it's still possible to provide a custom runtime link editor (ld.so is just another program). Then all you really need is the ability to tell mmap to either give you allocations in a fixed address, or anywhere in the 32-bit space. I believe both are commonly supported features. You may have to circumvent libc malloc in a similar manner, providing a custom version that uses mmap with low addresses.

Does the kernel hand out any other buffers (e.g. for graphics, audio), or are they all allocated by the application? If such things are provided by the kernel, then you also need the shim to use some bounce buffers. Of course this all has some overhead. But we're talking about running old games on recent systems.
You can try the experiment quite easily.
Build an Linux kernel with CONFIG_IA32_EMULATION disabled, and try to run native 32-bit codes under it. :-)
I didn't know Mac users could play games at all.
Yeah. Apple does what...well, whatever Apple does. At this point I'm not too bummed out about it. I do most of my gaming on legacy Mac hardware anyway, and let's face it, Mac gamers who are into retro games or gaming using WINE are a minority of a minority in the first place. It's profoundly sad to see WINE-based gaming effectively come to an end on the Mac in the near future, though.

Between Apple dragging their feet on graphics API support and their terrible decisions regarding things like OpenGL/Metal, I'll probably see myself switching to Linux more in the future.
avatar
zeogold: I didn't know Mac users could play games at all.
How DARE you?

Escape Velocity and Marathon are great games!
avatar
zeogold: I didn't know Mac users could play games at all.
they actually can play games and make bread toast with their mac. crazy huh!
avatar
zeogold: I didn't know Mac users could play games at all.
avatar
mofofromjkt: they actually can play games and make bread toast with their mac. crazy huh!
You mean Big Mac?
avatar
rampancy: ...and let's face it, Mac gamers who are into retro games or gaming using WINE are a minority of a minority in the first place...
Ain't that the truth. Mac gamers in general have always been this niche anomaly, even if it has become more accepted and growing over the past decade or so.

As much as I'm not fan of some of the things Apple does, I don't think I'll be switching to Linux myself because I really don't want to learn my way around yet another (fragmented) OS that also may require more manual tweaking. I still very much like OS X/macOS/whatever it's called these days, and for my general purpose computing it'll remain my OS of choice with a bit of gaming on the side. For the real gaming, I have my Winbox.