3 ms·

It says eventual support for MacOS apps? I'm very curious about this.

prewett 5y ago
That's the part where I stopped reading... That'd be fantastic, I hope it happens. But... Wine's been going for at least 20 years, and the last time I tried, it still had major problems. Unfortunately for Wine, Microsoft keeps adding APIs. Even more unfortunately, their architectural sense leans towards "shove all the internal complexity onto the developer". I assume it is harder to re-implement a lousy architecture than an elegant one. At least Cocoa is fairly well thought out and mature. But, it's still a lot of code to write. Just wait until they get to CoreAudio, though, hahaha! Not at all clear how that's supposed to work, and good luck if you want a sample rate that's not the default. Oh, and don't ever change anything about your environment once you've got it work, like, say, the operating system version.
- treesknees 5y ago
  It depends on the application you're running. Wine works perfectly well for many applications and games. Just because it's not perfect doesn't mean you should stop trying.
- grishka 5y ago
  One thing that Apple does better than Microsoft is not caring about apps using private APIs. You can use them, but you're on your own, and expect your app to break on the next major release.
- arid_eden 5y ago
  Note that Wine runs Windows binaries, whereas what this project aims for is source compatibility. That at least means you aren't at the mercy of ABI versioning, though you wouldn't be able to 'run' a macOS app you found online.
ziggus 5y ago
From poking through the repo, it looks like it uses a FreeBSD port of Cocotron to handle Objective-C and some of the Core* APIs.
spfzero 5y ago
It seems like it would be a lot of work to keep up with the annual deluge of new APIs and OS features in MacOS that application developers will incorporate pretty quickly. To really keep the promise of source-code compatibility, it seems like you'd need to quickly absorb all of the new APIs, plus, figure out how to implement them at the lower levels, on a different OS (MacOS is mach-based.) Of course, the project has doubtless thought much more about this than I have, and maybe have an awesome plan, too.

That's the part where I stopped reading... That'd be fantastic, I hope it happens. But... Wine's been going for at least 20 years, and the last time I tried, it still had major problems. Unfortunately for Wine, Microsoft keeps adding APIs. Even more unfortunately, their architectural sense leans towards "shove all the internal complexity onto the developer". I assume it is harder to re-implement a lousy architecture than an elegant one. At least Cocoa is fairly well thought out and mature. But, it's still a lot of code to write. Just wait until they get to CoreAudio, though, hahaha! Not at all clear how that's supposed to work, and good luck if you want a sample rate that's not the default. Oh, and don't ever change anything about your environment once you've got it work, like, say, the operating system version.

treesknees 5y ago
It depends on the application you're running. Wine works perfectly well for many applications and games. Just because it's not perfect doesn't mean you should stop trying.
grishka 5y ago
One thing that Apple does better than Microsoft is not caring about apps using private APIs. You can use them, but you're on your own, and expect your app to break on the next major release.
arid_eden 5y ago
Note that Wine runs Windows binaries, whereas what this project aims for is source compatibility. That at least means you aren't at the mercy of ABI versioning, though you wouldn't be able to 'run' a macOS app you found online.

ziggus 5y ago

From poking through the repo, it looks like it uses a FreeBSD port of Cocotron to handle Objective-C and some of the Core* APIs.

spfzero 5y ago

It seems like it would be a lot of work to keep up with the annual deluge of new APIs and OS features in MacOS that application developers will incorporate pretty quickly. To really keep the promise of source-code compatibility, it seems like you'd need to quickly absorb all of the new APIs, plus, figure out how to implement them at the lower levels, on a different OS (MacOS is mach-based.) Of course, the project has doubtless thought much more about this than I have, and maybe have an awesome plan, too.