* Many applications, mostly anti-cheat and anti-tamper engines, [...] Oh well.... This by itself basically only matters for actual Windows libraries (and in practice applications mostly only care about ones they expect to be tampered with, which isn't that many.) I don't know much about anti-cheat, but wouldn't the graphics stack be of importance here, which you wrote is off limits? (Thinking about
* Some of the important hosts for Wine have dropped support for 32-bit libraries or are going to drop it. Mac is the obvious example here, but many commercial Linux distributions also want to drop support. By limiting the surface through which code can transition between PE and Unix code, it becomes feasible to do 32-to-64 translation, where previously this was quite infeasible. So the Unix code lives in a different process? Couldn't that result in
Am 09.09.21 um 07:13 schrieb Zebediah Figura: things like transparency cheats in FPS games, not sure if that's still something to worry about.) performance issues with games that heavily exercise graphics, sound, input libraries?
* Making fake syscalls is, like real syscalls, not cheap. It involves a full context switch into and out of Unix code. Exactly. I'm not sure at all if that's going to be an issue, but obviously one needs to be careful when introducing a process boundary, and make sure there aren't too many context switches. So here I have to agree with Michael: loading ELF libraries into the same process but "hiding" them from Windows code sounds like something I'd be less worried about. In the end it's up to you though.
From a distribution point of view (in addition to what Jan wrote about un-bundling): right now it's hard to say if we'll want to use our own sources, but staying close to upstream would be appreciated, to keep that option open for later. We have quite a few packages that have started bundling things and let that diverge to a point where using upstream code (or our package) seems ever unlikelier. Best regards, Aaron