Hi,
I am solving problem how to get one Win32 app (for which I have source code) running under Wine. The biggest issue is drivers and ioctls. Linux has driver support for what we need and provides similar ioctls for some stuff, but it differs from Windows.
The difference is *so big* that I would prefer to modify our source code to use different pieces of code when it detects Wine. I understand, that this is *against* Wine policy and generally should not be used. But writing built-in replacement for some DLLs (hack Linux-style drivers into Windows-style) would be a nightmare, so having small mods to Win code would be much easier. I am not talking about "generic" functions, but about specific drivers/etc.
Imagine this: Under windows you get usb driver with some ioctl-based interface, sometimes with DLL or without it (vendor provides only .lib file that gets statically linked). Under Linux there is libusb used. Difference between these two ways of driver implementation is *huge* and making libusb driver compatible with Win32 driver is almost impossible (in Win you have a real file handle, under libusb only pointer, etc.).
It would greatly help for this case to be able to:
- detect wine and platform from Win32 app (.exe) - load native Linux library and perform ioctls (ioctl(2), not Windows IOCTL!) on file handles - get somehow access to files in Linux filesystem (i.e. in /dev)
This would allow to easily modify our source code in a few places (i.e. hardware routines) and get it quickly running under Linux.
I can do all above by writing some built-in dll that would work just for my case, but I think *maybe* it's worth it to provide some generic interface in Wine??
Martin
On Thu, Mar 20, 2008 at 10:26:20AM +0100, Martin Hinner wrote:
Hi,
I am solving problem how to get one Win32 app (for which I have source code) running under Wine. The biggest issue is drivers and ioctls. Linux has driver support for what we need and provides similar ioctls for some stuff, but it differs from Windows.
The difference is *so big* that I would prefer to modify our source code to use different pieces of code when it detects Wine. I understand, that this is *against* Wine policy and generally should not be used. But writing built-in replacement for some DLLs (hack Linux-style drivers into Windows-style) would be a nightmare, so having small mods to Win code would be much easier. I am not talking about "generic" functions, but about specific drivers/etc.
Imagine this: Under windows you get usb driver with some ioctl-based interface, sometimes with DLL or without it (vendor provides only .lib file that gets statically linked). Under Linux there is libusb used. Difference between these two ways of driver implementation is *huge* and making libusb driver compatible with Win32 driver is almost impossible (in Win you have a real file handle, under libusb only pointer, etc.).
It would greatly help for this case to be able to:
- detect wine and platform from Win32 app (.exe)
Best bet is to just check for the registry key HKLM\Software\Wine
- load native Linux library and perform ioctls (ioctl(2), not Windows
IOCTL!) on file handles
Needs code in your application, but is technically possible.
- get somehow access to files in Linux filesystem (i.e. in /dev)
Same as above. No need for any specific code if you map Z: to / for instance.
This would allow to easily modify our source code in a few places (i.e. hardware routines) and get it quickly running under Linux.
I can do all above by writing some built-in dll that would work just for my case, but I think *maybe* it's worth it to provide some generic interface in Wine??
Hmm. We might be able to do this via msvcrt ioctl perhaps? No idea.
Ciao, Marcus
On 3/20/08, Marcus Meissner meissner@suse.de wrote:
Best bet is to just check for the registry key HKLM\Software\Wine
I know also other methods, this is not a problem, I just wanted to ask if it's possible to get some "official wine api" for all this stuff.
- load native Linux library and perform ioctls (ioctl(2), not Windows
IOCTL!) on file handles
Needs code in your application, but is technically possible.
I know, the question is again about getting this officially into wine so as I don't have to make my own built-in .dll.so
- get somehow access to files in Linux filesystem (i.e. in /dev)
Same as above. No need for any specific code if you map Z: to / for instance.
And if user does not? It would be nice to do _wine_open("/dev/something", O_RDWR) from my app.
This would allow to easily modify our source code in a few places (i.e. hardware routines) and get it quickly running under Linux.
I can do all above by writing some built-in dll that would work just for my case, but I think *maybe* it's worth it to provide some generic interface in Wine??
Hmm. We might be able to do this via msvcrt ioctl perhaps? No idea.
IMHO it would be nice to have "standard" wineapp.dll.so that would work as a proxy between posix functions for applications that are aware about Wine. Such DLL would be a great helper! In fact I would need only dlopen() and dlsym(), maybe also uname() :-).
This library could be loaded from Win32 app using LoadModule(..) on-demand.
Martin
-
Marcus Meissner -
Martin Hinner