Reading Anastasius Focht report on http://bugs.winehq.org/show_bug.cgi?id=24081 I saw that there should be many applications that relies on low level operations to start, mainly some games that verify the authenticity of their DVD-ROMs and some applications that use anti-cheat functions.
So I thinking in: what about we transform wine in a virtual machine?
So any device that runs on the real machine, can be abstracted on a virtual device on the windows virtual machine. In this way, even some hardware can be installed on wine.
We already have many open source virtual machine code out there and we can adapt Wine windows kernel to run on top of this virtual machine, so applications can really feel like they are running on windows.
This will be a hard work, but I think it is the only way to reach full compatibility.
However, once the lower level operations are completed, all native libraries can be installed on this.
Can wine become a virtual machine?
-
fernandocarvalho
- Level 4
- Posts: 102
- Joined: Sun Oct 11, 2009 7:03 am
-
fernandocarvalho
- Level 4
- Posts: 102
- Joined: Sun Oct 11, 2009 7:03 am
fernandocarvalho. I am sorry to say lot of the anti-cheat stuff would still fail anyhow.
You really need to look closer at what http://bugs.winehq.org/show_bug.cgi?id=24081 is doing. SSDT monitoring is a highly risky problem. Some alter SSDT calls.
Really for highly possible destructive items this even running a virtual kernel would be a issue.
Beware not all wine parts send data to wine virtual kernel instead lot go direct off to Linux. Virtual machine costs overhead. If application does not need it don't do it. So a an option to run driver virtual and let everything else go direct to Linux would be a better option. Ie trap only the data streams the driver needs to know about.
Best way is learn how to lie to the anti cheat drivers.
Yes the SSDT are all fine. Problem is we are wine we call Linux we don't really use the SSDT for functions it only there to make you happy you darn rootkit or if we are told to.
This is the better solution from the performance point of view and a secuirty one. If something does try to rootkit wine that way unless user has changed something it will fail. Virtual machine has too much overhead cost.
Besides once we are running a full kernel anyhow we might as well Kvm reactos.org. Wine is not just about full compatibility it is also about speed.
All native libs don't help with the speed goal.
You really need to look closer at what http://bugs.winehq.org/show_bug.cgi?id=24081 is doing. SSDT monitoring is a highly risky problem. Some alter SSDT calls.
Really for highly possible destructive items this even running a virtual kernel would be a issue.
Beware not all wine parts send data to wine virtual kernel instead lot go direct off to Linux. Virtual machine costs overhead. If application does not need it don't do it. So a an option to run driver virtual and let everything else go direct to Linux would be a better option. Ie trap only the data streams the driver needs to know about.
Best way is learn how to lie to the anti cheat drivers.
Yes the SSDT are all fine. Problem is we are wine we call Linux we don't really use the SSDT for functions it only there to make you happy you darn rootkit or if we are told to.
This is the better solution from the performance point of view and a secuirty one. If something does try to rootkit wine that way unless user has changed something it will fail. Virtual machine has too much overhead cost.
Besides once we are running a full kernel anyhow we might as well Kvm reactos.org. Wine is not just about full compatibility it is also about speed.
All native libs don't help with the speed goal.
By the way if you don't already know. By Linux defines. What lots anti-cheat things do are root-kits. Anything third party reaching into the kernel to alter its operation by intercepting functions or adding functions by Linux define is a rootkit.
Taking over control of the SSDT alterations does alter the way the kernel operates . So it is a rootkit.
If game developers want features like this they would have been designed into the kernel. What happens when user installs two games that do SSDT monitoring. Possibly OS death. This stuff is highly unhealthy. Rootkits allow applications to interface with more than what they normally would be able to. Yes userspace interfacing with SSDT is normally impossible by windows NT design.
We are better if users boycott games like that fernandocarvalho.
Taking over control of the SSDT alterations does alter the way the kernel operates . So it is a rootkit.
If game developers want features like this they would have been designed into the kernel. What happens when user installs two games that do SSDT monitoring. Possibly OS death. This stuff is highly unhealthy. Rootkits allow applications to interface with more than what they normally would be able to. Yes userspace interfacing with SSDT is normally impossible by windows NT design.
We are better if users boycott games like that fernandocarvalho.
