On Thu, Feb 28, 2008 at 8:26 AM, bussuser wineforum-user@winehq.org wrote:
http://www.reactos.org/forum/viewtopic.php?t=5240
It is based on WINE and ReactOS .
It's not a wine replacement; it uses wine. Better description at http://www.reactos.org/forum/viewtopic.php?t=5240
It looks like they added hooks to the linux kernel to accept windows nt syscalls. Maybe they even allow using the system's normal shared library loader instead of Wine's special one. This is something I've often wanted to do, but it was way lower priority than getting wine working. I haven't looked at their project at all, no idea if it was done well. - Dan
However, it's a great, great project IMO. It was about time something like that should've been made. Redirecting calls is simply acting as a proxy, instead of emulating. However, it makes it only to be usable in Linux... but hey, this is genius.
On Thu, Feb 28, 2008 at 12:07 PM, Dan Kegel dank@kegel.com wrote:
On Thu, Feb 28, 2008 at 8:26 AM, bussuser wineforum-user@winehq.org wrote:
http://www.reactos.org/forum/viewtopic.php?t=5240
It is based on WINE and ReactOS .
It's not a wine replacement; it uses wine. Better description at http://www.reactos.org/forum/viewtopic.php?t=5240
It looks like they added hooks to the linux kernel to accept windows nt syscalls. Maybe they even allow using the system's normal shared library loader instead of Wine's special one. This is something I've often wanted to do, but it was way lower priority than getting wine working. I haven't looked at their project at all, no idea if it was done well.
- Dan
On Thu, Feb 28, 2008 at 8:47 AM, DARKGuy . dark.guy.2008@gmail.com wrote:
However, it's a great, great project IMO. It was about time something like that should've been made. Redirecting calls is simply acting as a proxy, instead of emulating.
Wine is not an emulator. No emulation is going on anyway.
We would, I think, like to move wineserver into the kernel sometime. It's been discussed before. Linus is not opposed to having native support for win32 system calls. A fellow at Redhat wrote a kernel module for wine a number of years ago, but it just wasn't time yet.
For a related BSD thingy, see http://www.kernel-traffic.org/wine/wn20010313_87.html#1 That project was still going as of 2006, I think, but didn't get terribly far.
- Dan
On 28/02/2008, Dan Kegel dank@kegel.com wrote:
We would, I think, like to move wineserver into the kernel sometime. It's been discussed before. Linus is not opposed to having native support for win32 system calls. A fellow at Redhat wrote a kernel module for wine a number of years ago, but it just wasn't time yet.
If Wine works, what would you gain by moving it out of userspace?
- d.
On Thu, Feb 28, 2008 at 9:22 AM, David Gerard dgerard@gmail.com wrote:
If Wine works, what would you gain by moving it out of userspace?
Performance, mostly. Maybe also more of a notion of a whole system (right now, wine is kind of per-user).
It's pretty low priority.
On Thu, Feb 28, 2008 at 11:37 AM, Dan Kegel dank@kegel.com wrote:
It's not a wine replacement; it uses wine. Better description at http://www.reactos.org/forum/viewtopic.php?t=5240
It looks like they added hooks to the linux kernel to accept windows nt syscalls. Maybe they even allow using the system's normal shared library loader instead of Wine's special one. This is something I've often wanted to do, but it was way lower priority than getting wine working. I haven't looked at their project at all, no idea if it was done well.
A long long time ago there was a project called Captive NTFS that was mostly the same idea but in userspace, They tool the ReactOS kernel, combined it with FUSE, and used that to load the native ntfs.sys. It actually took a little more work because ReactOS Cache Manager was so broken (another sign there is no way in hell the code was stolen from Microsoft) that the author had to profile the native ntfs.sys and rewrite the entire Cache Manger in glib. It would not have been much of a stretch to add support for Win32 applications on top using Wine. This might end up being a better solution for certain device drivers like the copyprotection systems.
-
Dan Kegel -
DARKGuy . -
David Gerard -
Steven Edwards