3 ms·
64-bit WINE exists on macOS now, I have it installed on my MacBook Air. But 64-bit WINE can't run 32-bit Windows apps because it's not an emulator, it's a binar
by TazeTSchnitzel 7y ago
64-bit WINE exists on macOS now, I have it installed on my MacBook Air. But 64-bit WINE can't run 32-bit Windows apps because it's not an emulator, it's a binary loader and a set of system libraries.
- donatj 7y agoThis is really frustrating to me because I am dependant on a small handful of 32 bit Windows Apps, and happily run them in Wine on my Mac currently. I've been wondering what the solution would be after Catilina dropped 32 bit support and I guess the answer is I'll probably have to start launching an entire VM.
- fastball 7y agoDo you mind if I ask what apps these are which you can't find modern replacements for?
- blihp 7y agoIt's not that you can't find modern replacements for them, it's not wanting/needing to if you've got something that already works for you. Some of that crusty stuff from the 1990's and earlier works just fine and the 'modern' replacements bring nothing new to to table for many use cases. So why bother upgrading to a version that phones home and/or is tied to a subscription to accomplish performing the same task in a less streamlined way? Do I do this with most of my software? Absolutely not... generally, but not always, the newer stuff does the job better for me. You wanted an example, so I'll provide one: I have an ancient version of MathCAD (from 1994 or so) that I still fire up once or twice a year for some computer algebra tasks. Could I upgrade or switch to another application? Sure, but why bother when what I have does the job? (I've even got a 'modern' version of Mathematica but prefer the MathCAD UI from the 1990s... ah, progress!)
- coldpie 7y agoWe're working on running 32-bit Wine applications on 64-bit-only macOS for CrossOver, but it's a huge and difficult problem.
- tzs 7y ago> But 64-bit WINE can't run 32-bit Windows apps because it's not an emulator, it's a binary loader and a set of system libraries The history of the "wine is not an emulator" thing is interesting, since the name originally in fact meant "WINdows Emulator". As far as I have been able to dig up, the first suggestion to change the meaning to "Wine Is Not an Emulator" came up on Usenet in 1993 [1], when there was some concern that "Windows Emulator" might run into trademark problems. Bob Amstadt responded to that [2] telling how the name "wine" came about: > My orignal line of thinking was "winemu", but I didn't like that. Then I thought of shortening it to "wine". This led me to think of "whine" and "whinny". I liked "whine", but felt that it was too long. As far as I have been able to tell, nothing further came of the "not an emulator" suggestion at that time. Sometime over the next four years, it did become an alternative meaning of the name, but I'm not sure exactly when or why. From the FAQ in late 1997 [3] > 1.2: Why call it 'Wine'? > The word Wine stands for one of two things: WINdows Emulator, or Wine Is Not an Emulator. Both are right. Use whichever one you like best. They didn't stop calling it an emulator until the end of 1998. The release notes for 981108 [4] described at thusly: > This is release 981108 of Wine, the MS Windows emulator The release notes for 981211 said [5]: > This is release 981211 of Wine, a free implementation of Windows on Unix I've not been able to find for sure why they stopped calling it an emulator, but it looks like there were two things. I don't have cites for these because I didn't save links. I apparently though they were somewhere I'd be able to easily find again, and was evidently wrong. One of the reasons is that Wine can be used for more than just taking a Windows binary and running it on Unix. It could also be linked with native Unix code to make it easier to produce native Unix ports of Windows programs. The other reason is that computers were getting fast enough that emulators of older hardware were starting to get useful enough for people to be aware of them, but were slow. Most users of Macs and DOS or Windows PCs only ever heard of emulation in that context. Tell them that they can run Unix and keep using their old Windows programs via the "WINdows Emulator" on Unix, and they were going to think that would be very slow. It was a lot easier to simply stop calling Wine an emulator than try to explain to people that it was just emulators that had to emulate a CPU that were inherently slow at that time, and that since Wine just has to emulate Windows interfaces, which for most programs most of the time will map in a fairly straightforward way to Unix interfaces, it is very low overhead. [1] https://groups.google.com/forum/#!original/comp.os.linux.misc/_g3F2H4ieDc/UkqtYMP6d-sJ https://groups.google.com/forum/#!original/comp.os.linux.mis... [2] https://groups.google.com/forum/#!original/comp.os.linux.misc/_g3F2H4ieDc/1tN3XZODaYwJ https://groups.google.com/forum/#!original/comp.os.linux.mis... [3] https://groups.google.com/forum/#!msg/comp.emulators.ms-windows.wine/GOg6NAoNkg8/_jOvbogsh70J https://groups.google.com/forum/#!msg/comp.emulators.ms-wind... [4] https://groups.google.com/forum/#!msg/comp.emulators.ms-windows.wine/yYfTNV3Z2J0/fu4dtf_A2RcJ https://groups.google.com/forum/#!msg/comp.emulators.ms-wind... [5] https://groups.google.com/forum/#!msg/comp.emulators.ms-windows.wine/tbMAhTg6GEs/tbBxEO4OtmEJ https://groups.google.com/forum/#!msg/comp.emulators.ms-wind...