Hi,
The comment in winedevice.exe says "Service process to load a kernel driver".
But will winedevice.exe in the (far ?) future be the vehicle to load file system drivers as well.
Hi Paul,
2008/5/7 Paul Vriens paul.vriens.wine@gmail.com:
Hi,
The comment in winedevice.exe says "Service process to load a kernel driver".
But will winedevice.exe in the (far ?) future be the vehicle to load file system drivers as well.
I think the idea of loading filesystem drivers is insane at best, unless you plan to add a whole vfs layer, or modify the captive driver (NTFS binary driver loader for the linux kernel) to work on wine. And even that probably depends on the vfs layer. Feel free to correct me if I'm wrong.
Cheers, Maarten.
Maarten Lankhorst wrote:
Hi Paul,
2008/5/7 Paul Vriens paul.vriens.wine@gmail.com:
Hi,
The comment in winedevice.exe says "Service process to load a kernel driver".
But will winedevice.exe in the (far ?) future be the vehicle to load file system drivers as well.
I think the idea of loading filesystem drivers is insane at best, unless you plan to add a whole vfs layer, or modify the captive driver (NTFS binary driver loader for the linux kernel) to work on wine. And even that probably depends on the vfs layer. Feel free to correct me if I'm wrong.
Cheers, Maarten.
It's not so much that I want the driver to actually work :-).
I was experimenting with Mozy backup (http://mozy.com/) with respect to bug 12030 (http://bugs.winehq.org/show_bug.cgi?id=12030).
Installation stalls when the file system driver is installed. Changing services.exe to route this driver via winedevice makes the installer work "normal" but crashes (of course?) the driver.
When I then remove the patch from services.exe and try to start anything I see a 1 minute delay in execution. This is due to us trying to launch the driver (without winedevice) and sending a start control to it. It looks like this introduces a timeout.
So again, I'm not trying to get this driver running but want to get rid of that timeout.