Hello @awsdert, you're making a request for an order of magnitude increase in maintenance and upkeep for essentially nothing because the ReactOS kernel would not have access to a GPU in the virtualized environment.
Without a proof of concept with examples of what works on (virtualized) ReactOS, but not Proton and why, this is not worth entertaining as a feature request.
That's why I said modified, as in reuse parts of the kernal to make reactos think it's in a virtualised enviroment (can make use of virtual box code for that)
and have it talk somewhat directly to steam &/or linux instead, after getting that part to work out you then go on to modify it's drivers to be talking somewhat directly as well giving it that access it needs, the rest should only need to be reactos code with a pre-installed steam client so a login event of "steam -s gameid" can be fired the right of the bat, when the steam client ends another task that shuts down reactos would then fire instead, I'm not expecting this to be easy but it should in theory be more reliable than wine etc bundled together, reactos would already have that lot done in a less error prone enviroment
That would still require too much work to begin with to be honest, And on top of that, ReactOS pulls in much of Wine's codebase on top of their own work, it would be beneficial to remain with wine since virtualization can also be expensive on one's system typically.
I did say as a fallback, as for difficulty I'm sure I've read somewhere about a kernel that implements both linux and windows APIs, perhaps you could swap out the reactos kernel with that, throw in a modification or two to make it play nicely as a semi-virtualised os and then swap throw in the dx code your using as replacement driver/library/whatever for the games and reactos to talk to (with a few added entry points for reactos). I get that there will be a performance hit for that method but as a fallback it's better than nothing
The fake dlls will be mostly the same in that scenario and merely a replacement directory structure, e.g.
proton/c_drive/reactos
proton/c_drive/steamlib (mounted)
proton/proton.elf (try 1st)
proton/kernel.elf (try last, mounts/dismounts steamlib)
Nothing extracted yet.
Feature Request
I was thinking that it might be easier to support all windows games at once (including DRM ones) if you just use modified builds of ReactOS inside shared folder acting as a ide and the booting/running game's folder shared also
I confirm:
contain this feature already.
Description
see above
Justification [optional]
wine is supposed to be user space only, whereas proton can make a virtualised reactos a fallback for games that fail to boot the first time
Risks [optional]
none that I can think of besides being fractionally slower maybe?
References [optional]
https://reactos.org/