On 9/9/21 6:54 PM, Aaron Puchert wrote:
* 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
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.)
Honestly we'd like to be able to cut the unix boundary for the graphics stack lower. The problem is that it's really hard when your graphics stack is Mesa, and impossible when it's proprietary.
* 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 performance issues with games that heavily exercise graphics, sound, input libraries?
It lives in the same process; we use an ljmp (far jump) to cross segment boundaries. Obviously it requires support from the host OS to still give us a 32-bit segment.
* 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