Wine and Drivers
Vitamin [wineusr 09] summarised drivers and Wine:
- Pseudo drivers Copy protection drivers [and wine] depends how nasty they are. Things like root-kits (GameGuard), highly invasive (StarForce) or DRM like which verify "authenticity" of the system (parts of WMP) won't ever work on Wine. Some properly written ones might and do work (older versions of SafeDisk).
- Hight level HW drivers usb, printer, scanner.. (in terms of driver stack) might eventually work as they don't talk directly to the hardware but to the lower level drivers. It's possible to create those [lower] level "drivers" that talk to the hardware via Linux drivers. Example is experimental support for USB drivers.
- Low level HW drivers (network cards, video drivers, specific hardware, etc). won't ever work as they talk directly to the hardware which Wine can't do. And emulating this won't by feasible. Besides you'll have better chances getting Linux driver instead.
There is continued discussion about drivers and Wine. Here are some of the developer's thoughts as posted in the mailing lists. Feel free to add more.
In general terms, M. McCormack: Drivers belong in the kernel. If there's no Linux driver for a device, then Wine cannot support it. In that case, the first step is to write a Linux device driver for it, which has the added advantage that other native linux applications can use the hardware.
When discussing the implementation of a Driver E. Pouch summarised [May 05]: drivers should be written as follows:
- since it's wine specific, its name should start with wine (so winevfw or whatever)
- the driver shall be a driver for both avicap and qcap DLL
- interfaces to the driver should be the regular windows' ones (fetch information on avicap driver interface, as well as DShow driver interface - DDK info on the Web is your friend)
- a single driver shall be provided for all possible unix interfaces (you can start with v4l of course)
Item 2/ has the following benefits:
- it centralizes access to a given kernel resource in a single DLL
- some information between the two types of interfaces may have to be shared
Item 3/ has the following benefits:
- you can test the qcap, avicap... DLLs under windows with *real* drivers and see if it works
- we can share all the qcap, avicap... DLLs with the folks from ReactOS
- some braindead programs may look at some (real driver) interfaces for their own use
Item 4/ has the following benefits:
- it's up to the driver, at runtime, to find out and setup the existing physical devices
- you don't need to have fancy settings (configuration...), which most users won't understand
BTW this is was / has to be done for the audio/midi drivers (where 1, 2, 3 are already done, and 4 is missing)
Drivers do not belong in the wineserver
A programmer asked[Sept 05]: Why dont we have these drivers in the Wineserver?
A. Julliard [Sept 05]: Stability is the obvious reason. And also of course the fact that we have most of the code we need in ntdll already and none of it in wineserver.
R. Shearman: Windows doesn't have missing functions or functions that aren't quite completely implemented. As Alexandre says, there is a ton of stuff that would have to be duplicated in order to be able to load Windows drivers in the wineserver. For example, PE loader, virtual memory, exceptions / signal handling and threading. Also note that the wineserver is single threaded (and it would be a big task to make it thread-safe) and that whenever you are calling driver code then all Wine apps are blocked.
M.McCormack: [...]It looks like Alexandre has made the design decision to live with a file handle mapping to a single Unix file descriptor a while back. That makes things difficult for people who want to write code to load and use device drivers in any consistent fashion.
A. Julliard: The problem is that our I/O performance sucks, and we need to improve it by having a faster mechanism to map from handle to file descriptor. That doesn't mean we cannot have a special case for drivers, but it needs to be done in a way that doesn't impact normal I/O. This means that for instance doing a system call to retrieve the handle type is not an option. There are other possible ways though, for example by having the mapping return some sort of magic file descriptor that can somehow be identified as belonging to a device (details left as an exercise for the reader ;-)
Then we could imagine a generic mechanism to redirect I/O calls for specific devices to the wineserver, which could then either handle them directly or forward them to ntoskrnl for the case of a native driver. If done right, such a mechanism could probably also be used to fix the async I/O support, which is currently in pretty bad shape. Wine Archive
V. Margolen: [Sept 05]Summary of all the ideas and requirements:
- wineserver should not be used to run drivers (absence of requiredb functionality, single threaded, stability issues)
- ntoskrnl should be used to run drivers only and link to ntdll and not the other way around. Unless we implement int 0x2e handling and replace wineserver with ntoskrnl. (this is wine not reactos, ntdll already has all the required functionality)
- Drivers can not be ran in a process that requires them (drivers we concerned about keep information that is shared between different processes, drivers require their own environment that is different from a user process environment, ntdll has no means nor should it have them to run a driver)
Wine and Copy Protection
There appears considerable interest in running Software and Games in Wine that use copy protection. While those who purchase games to run on Wine have found that for a few games, only a cracked version can be run on Wine, this is not the desired goal of Wine. Wine developers want copy protection such as Macrovision, to successfully run and yes some development is progressing for these gamers who are interested in playing the games they have legally purchased. It would appear that the companies who supply copy protection software are merely ignorant about Linux and lack any real understanding or insight about the goals of Wine. For them, open development is something hard to grasp. Since Wine is LGPL a developer cannot sign a full non disclosure agreement because the code contributed for wine will be published. However, Wine is not seeking to document their particular concept, but rather to implement Windows behaviour, and have shown themselves to be discreet with issues in the past. It is unknown whether they would consider providing confidential details about their software to a sole developer, but they may better understand the concept of dealing with a company. You could help educate them by writing a polite email or preferrably a letter asking a game company or even copy protection providers to support Codeweavers in allowing copy protection to succeed under Wine. Numerous polite but persuasive letters from their paying customers will be read and may help in their education.
V. Margolen: Those that use kernel drivers do not work on Wine because ... Wine has no kernel to load those drivers into. We will need at least ntoskrnl.exe implemented because it's more of a "dll" then exe and all drivers import number of functions from it. Of course we can only emulate "kernel" to some point. But even that would be enough for drivers that only check for debugger presence and nothing else.
D. Navea: bug 2895 [a bug involving EA's copy protection] got me thinkin.. If we only support a handful of games that use copy protection, shouldnt we file a bug in Bugzilla and append that to 1434 (Get games working perfectly)? That way we can attach any copy protection related bugs to this metabug?
Ivan Leo Puoti: Yes I think it's a good idea.Wine Archive Link
D.Navea then filed Bug 2896 - Implement Copy Protection Support for newer games (legally) (Metabug)
J. Wilson: [Jun 05] From what I understand, there are 3 ways to do copy protection in WINE (at least for copy protection that needs a kernel driver to work):
- .Implement a WINE implementation of that kernel driver (in the same way various stock windows kernel drivers have been implemented). Problem with this is that there is a big DMCA risk (which is why AFAIK its been rejected)
- .Implement a fake NTOSKRNL that has just the entrypoints for accessing and loading copy protection drivers (the set of kernel calls needed by the copy protection drivers is only a very small subset of the total set of kernel calls and AFAIK none of them are hardware related)or
- .Implement a proper kernel driver loader (i.e. one that would sit in the windows kernel and do the same sort of thing as that ndiswrapper and that ntfs.sys loader do)
What is the current state of copy protection work for WINE? Which of these 3 options do the developers intend to follow? (I remember someone posted some actual code for option 2 but I dont remember if anything happened with it)
Ivan Leo Puti:Wine Archives
 This will never be done, apart from the DMCA it would require a new driver for each new build of every copy protection system in the world
 This is what I'm doing, the safedisc 1 driver works quite well with it, some ring 0 emulation is needed but that also works quite well and isn't much of an issue.
This would be a real pain as it would mean implementing the windows binary driver interface in the kernel, it would also not be very portable.
Writing to the MBR W. Sippel [Oct 06] thought: the Flex copy protection scheme used by, for example, Photoshop and ZBrush also writes a key somewhere on the harddisk.
M. Owen: the fact that we allow the copy protection to work at all proves we have no malicious intent. It would clearly be dangerous to write to the MBR and I would not recommend us doing so.
C. Robbins:[Oct 06 [...] Only root would be able to do that, and running Wine as root is far from encouraged. Plus, fooling around with the MBR like that is quite dangerous.
Current Status of Copy Protection
Since the work in 2005, a number of Copy Protection systems now work on Wine and this continues to improve.
Ivan Leo Pouti: I've been working on copy protection (safedisk 1) with an ntoskrnl interface that allows .sys files to be loaded and run in wine, however you need to run real drivers in ring 0.
Ivan Leo Pouti [Aug 2005]:here's a little update Safedisc1 now successfully passes all anti debugger check, and recognises the CD correctly. It then attempts to start the game, but this doesn't work yet because of the nested exception on signal stack bug. Hopefully we aren't too far from getting it to run. Wine Archive
[Update Sept05] Ivan Leo Pouti and Vitaliy Margolen posted to the list their success with safedisk 1. Thanks go to Laurent Pinchart, Vitaliy Margolen, Brad DeMorrow, Marcus Meissner, and Alexandre for contributing time/code/ideas. Additionally thanks for pointers and suggestions from the ReactOS team.
A programmer asked about performance. Ivan Leo Pouti: Actually performance isn't' bad, we can load the game splash screen at least as fast as windows does. Drivers expect to be able to talk to each other, and processes expect to be able to interact with drivers/devices regardless of which process loaded the driver, so driver must have their own process to run in.
He was asked: Will this support versions 1.6.0 through version 1.50.20 ? 1.6.0 was the first version of safedisk, version 1.11.0 introduced secdrv.sys and NT support. And do you know if it supports "dplayerx.dll" and the second layer of encryption that is applied on the ICD that is in 1.50.20?
Ivan Leo Pouti: 1.50.20 is the version we used to implement support in wine, so yes it supports secdrv.sys and dplayerx.dll and the encryption applied to the ICD.Wine Archive
May 07. Progress has continued apace. When Wine 0.9.37 was released it noted an improvement: Support for a few more exe protection schemes.
Winehq Bugzilla entry 18918 [Jun 09] make sure you don't have additional software in WINEPREFIX that might interfere (installing hooks, patching memory), e.g. use a separate one for Themida protected apps.
Wine will not support every type of Copy Protection
Vitamin wine user 2008: Some copy protection systems check for bytecode entry of lots of functions. That means that Wine's code have to look _exactly_ the same as windows and be compiled with _exactly_ the same tool chain. Neither of this is possible. Oh and btw most of those copy-protection thingies don't work on vista as-is. Especially the older ones.
Vitamin: Wine does not and will not run root-kits (which GG is). And you must be really crazy install that on real Windows.
Vitamin: highly invasive (StarForce) [..] won't ever work on Wine.
DRM [..] which verify "authenticity" of the system (parts of WMP) won't ever work on Wine.
Wine doesnt assist working around game protection
A strange user asked wouldn't WINE [...] make a great cracking tool for [exeCypter]? [...] It supposedly detects and resists attempts to debug encrypted applications to break the code, but can it do so with WINE's virtualized environment?
M. Hearn [May 05]: They generally work pretty well (assuming they run correctly). It's quite hard to figure out what they're doing even when run within Wine.Wine Archive
(Rough guess at translation: No, and besides - that is NOT the goal of Wine)
- http://www.winehq.org/?issue=272 Wine WWN 272 - 2005 Wine Conf Summary (Ivan Leo Puoti is Working on Copy Protection)
- http://www.winehq.org/?issue=208 Wine WWN 208 - 2004 Wine Conf Summary (small discussion regarding Safe Disk)
What is the status with Wine and USB?
J. von Thadden [May 05]: USB is [currently] not working with Wine. You may have luck with a serial device or wth a linux kernel serial device emulation.
Hiji [May 05]: At this time, aside from basic kernel USB support (basically, mouse & keyboard), there isn't support for other devices in Wine. Ok, there is some headway made from webcams, and you can use your USB drive, but that's about it.
A Programmer noted for his joystick [Oct 05]: The bug is WONTFIX. It needs a Linux driver and we should interface Wine to it (in the scanner case via TWAIN and SANE). So this should be handled on case by case basis then?
F. Gouget replied: Wine has (at least some) linuxinput support. There was even work to add force feedback support this summer. So the way to go is to make the joystick work with the Linux kernel's linuxinput subsystem and then Wine should be able to just use it.
That's the standard pattern: a kernel driver interfaces with the hardware (e.g. a specific joystick make/model), the kernel provides a standard interface for interacting with a class of hardware (input devices, e.g. joysticks), and applications (e.g. Wine) use that interface to access any device in that class, without having to worry about their make or model. This is a much superior approach to the old 'each application must provide its own driver for each device' that was required in the old DOS times.
P. Troller: It's fine that wine can use USB scanners/cameras/printers etc, which can be interfaced though native Linux drivers/libraries, but these are almost always usable directly from Linux, while those proprietary devices aren't. Is there any chance that wine will progress in this area ? I'm ready to supply a bounty for a volunteer making some progress here.
V. Lipatov: We (Etersoft) are realized USB support in wine via libusb and do many fixes in ntoskrnl.exe to load and run proprietary drivers for protection keys (like HASP). AS I know, this improvements is not acceptable by Alexandre. If anyone is interested to consult us to do our code more acceptable, you are welcome. [Their work is accessible as a git branch] http://git.etersoft.ru/people/lav/packages/wine.git branch eterhack [and some information about why Alexandre is not accepting the improvements] Some summarize is available on http://wiki.winehq.org/USB
Is it possible to add USB functionality to WiNE?
In short: apparently yes, but this has yet to be done. If you need it, you could consider gathering a group of users to pay a developer to implement this. A few alternatives were mentioned by A. English: [to get USB supported] Submit it to the Linux driver project. Hopefully they can add support for it in Linux. As far as alternatives, you could run windows in vmware/virtualbox. They support USB.
[Update jan 09]. A developer has added some support in patches that have not been accepted by Wine. With some more work they may be accepted but this would need careful reading of the thread where they were discussed. link Also patches have been posted in Winehq Bugzilla entry 8783
I made big changes in the design since previous version. Now there are no new wine-specific modules and wineserver is not used for calling AddDevice. All drivers are running in a single winedevice process.
ftp://ftp.etersoft.ru/pub/people/amorozov/0001-Add-support-of-native-Windows-drivers-for-USB-tokens.txt ftp://ftp.etersoft.ru/pub/people/amorozov/0002-Re-generate-some-files.txt Second patch was generated with tools/make_requests && autoheader
After applying these patches should run tools/make_makefiles. For using native USB driver should copy HKLM\System\CurrentControlSet\Enum\USB\Vid_<vid>&Pid_<pid> and HKLM\System\CurrentControlSet\Services\<driver_name> from Windows registry. The driver should be put in the directory specified by HKLM\System\CurrentControlSet\Services\<driver_name>\ImagePath. Also you need to have permissions to read/write to USB device.
D. Jovanovic April 2005: Briefly, Windows apps never use USB directly (there is no equivalent of libusb on Windows; well there is libusb-win32, but no closed-source projects use it). They open a "device file" of the form \\Device\Options; so for instance my scanner driver opens \\MiiScan0 and \\MiiScan0\0\0\2. This opening is done using CreateFile(), which returns a handle.
Three other important functions are then used:
- WriteFile() - USB bulk writes
- ReadFile() - USB bulk reads
- DeviceIoControl() - USB control messages
Windows 2000 and XP have a set interface for using scanners, for example, so the parameters to these functions would be well known. For most other hardware it is trivial to reverse engineer it if necessary.
The problem is, Wine does all I/O (ie. ReadFile(), WriteFile(), DeviceIoControl()) using the wineserver, by querying the wineserver for a file descriptor (int obtained by the POSIX open() function in Linux), and then doing read() or write(), while DeviceIoControl() in wine delegates to CDROM_DeviceIoControl() or fails.
CreateFile() is reasonably easy to hack - but the problem is that you need ways to:
- Associate particular file descriptors to a dynamically linked library that would be identified by the CreateFile() argument (eg. for \\MiiScan0\, maybe the library would be MiiScan0.so).
- Load up the library on CreateFile() with a reference count of 1 and unload it when CloseHandle()decrements the reference count to 0.
- Use the library's functions for reading, writing, and ioctl's.
- (This is the hardest part) Make ReadFile(), WriteFile() and DeviceIoControl() aware of which file descriptor identifies which library, and call the right libraries functions. This probably requires changes to the wineserver.Wine Archive Link
M.cCormack: Drivers that are loaded in the kernel in Windows also belong in the kernel in Linux, not in Wine. Wine cannot present a driver interface to the rest of the system, nor to other programs. If you want to get a scanner going, the best way would be to make it work with SANE or V4L, and then get SANE or V4L to work with Wine's still imaging interface. That is much better than getting it to only work in Wine, as other applications will be able to use it via SANE, etc.
Have a look at the work that Maarten Lankhorst is doing on Web cameras ... he's doing things the right way.
You can continue trying to modify CreateFile, ReadFile, WriteFile etc. to make it work, but you'll realize sooner or later that a handle is tied to a unix fd. This is by design. Alexandre has said time and time again that he considers Wine to be just like any other application on the system; it reads file through the 'nix FS, and through unix file descriptors. [Though] if you still want to load the Windows driver, go and have a look at ndis wrapper. http://ndiswrapper.sourceforge.net/
Hiji: Conceptually, I think a combination of two solutions would be the best solution.
- The first is obvious: bridge the gap between Wine and the existing support (SANE, V4L, ALSA, etc.) This way, you don't reinvent the wheel and use what's in existence.
- The second is not-so-obvious, but crucial: load the Windows driver in a way that is similar to NdisWrapper or DriverLoader (where those items are modules that wrap around the Windows driver [I think!]). Why is this important? Because the reality is that beyond the generic USB hardware (scanner, webcam, mouse, etc.), there won't be a Linux equivalent driver for a specialized piece of hardware (Guitarport, DVC100, MP3 Player, etc.)
D. Jovanovic clarified: 'I don't care about Windows kernel drivers, just replicating the interface to them from user space software so that user-space drivers (which are abundant in Windows) can work. [While Wine cannot present a driver interface to the rest of the system, nor to other programs] Winelibs can. [The problem with making it work with SANE or V4L is that not] every hardware manufacturer in the world to releases all the documentation for all their hardware so we can make Linux drivers. There is a reason SANE and V4L only support _some_ (read: few) hardware. [The difficulty in using CreateFile, ReadFile, WriteFile etc. to make it work, is not that a handle is tied to a unix fd] In fact, it's tied to an "object" in wineserver: what fd would HWINDOW and HICON represent? [this post has been edited for clarity]
McCormack: I assume you mean HWND and HICON. They are not wineserver (kernel32) objects. A HWND is a user32 handle, and an HICON in Wine is a process local pointer. A HKEY is more interesting for the purposes of this discussion, as it is a wineserver object, and it is not tied to a unix fd. That's because you can't use ReadFile and WriteFile on it...
R. Kalbermatter: In the case of video capturing through avicap32 and most probably quartz too, we would be talking about "installable" drivers (loaded with winmm.OpenDriver) which reside in user space. It's the same driver interface used for audio drivers (alsa, oss, etc) and image companders (IC). I think it would be a good idea to add a winev4l driver into winmm so that quartz and avicap/vfw could make use through a standard interface and adding new capture interfaces would be possible without the need to hack into avicap or quartz at all.
Mike was refering to handles [tied to a unix fd] returned by CreateFile only. It is the interface to create kernel device driver instances under Windows and consequently wineserver would need to be involved somehow. HWINDOW and such while handles too, are completely different objects and managed by independent object managers both in Windows and Wine. A clean implementation for kernel driver support would need to support all kernel driver API interfaces through wineserver somehow, a nightmare both for performance and implementation reasons.
I. Leo Pouti: I've already got a (somewhat hacky) partial implementation for kernel mode drivers for copy protection drivers, so if you're interested let's try and not duplicate work, I can send what I have ATM to whoever's interested.
D. Jovanovaic posted some of his workings on a kernel module to the list [Oct 05]: The kernel module behaves just like USBSCAN.SYS, reading and writing do raw USB bulk pipe reads and writes, and the ioctl's mostly do USB control pipe operations. At present, I changed CreateFile() to open /dev/USBSCAN... on a "\\.\USBSCAN..." device, where /dev/USBSCAN... comes from [the] Linux kernel module that does the equivalent of Window's USBSCAN.SYS. And NtDeviceIoControl() checks whether the i/o control code is 0x8000.... (USB scanner ioctl) and if so, calls ioctl(). It all works (but most is hardcoded for my scanner [Microtek ScanMaker 3800] at the moment) [ and uses] a thin little STI.DLL [he wrote, which contained] just the bare minimum. [He then] had a brief look at the Windows 2000 STI.DLL import table: most of the SetupAPI functions it uses are stubs on wine :-(. It seems a lot of work to implement them too: there are handles to various structures etc. Wine Archive
Ge van Geldorp kindly pointed to some recent progress in ReactOS [Oct 05]: A lot of stuff was added on the ReactOS side [for setupapi]. Usually, we try to merge changes back to Wine, but for various reasons this sometimes fails. For example, some of our developers don't run Linux and therefore do not have the possibility to test their changes under Wine too. There's also the feeling that Wine should be responsible for their own codebase so it would be more logical if a Wine developer was to take on the task of the backmerge. Anyway, we effectively forked setupapi at Wine-20050524, the codebases became too different to keep in sync easily. (We forked another component, widl, at Wine-20050628). Of course, our changes are available to Wine, I'd be happy to work with one of you guys to get the Wine/ReactOS versions back in sync.
USB naming convention
A programmer noted [Aug 05]: I am doing now a dll which should load scanner microdriver and implement all the surrounding API's. Can anybody tell, what naming convention Windows uses for USB devices ("\\.\????")?
D. Jovanovic: I don't know for sure, but I think there is no convention. The device names are dependant on the hardware / system. What "microdriver" are you talking about? Are you working on STI? For STI, there is a convention for Windows 2000 and onwards, something like \\.\USBSCAN\... (check the STI documentation on MSDN). If it's STI, I have some code; do you want it? [The discussion then considered some implementaion considerations]. Wine Archive
How do I make a driver such as for my USB development board
U. Bonnes, April 2005: Not much has been done, in my understanding. The first step needed, in my opinion, is to put much work into the SETUPAPI DLL to let USB Devices at least enumerate. Talking the the devices then is another big step. Not many windows programs will talk to the devices by using something like libusb. So either something like ndiswrapper for USB would be needed in the kernel to load windows drivers, with infrastructure in wine to to talk to the driver, or the windows driver need to be be reengineered to exposed a API to the user program like with windows driver, but internally use Linux means (libusb, etc).
How do I make a driver such as for my USB scanner
F. Gouget: Well I think the right solution would be to add support for your scanner to SANE. Then Wine should be able to use it using the twain dll (see dlls/twain) which acts as a bridge to SANE.
Interfacing directly with the scanner might work using Wine's brand new and very incomplete USB interface (I believe part of it is in setupapi) but that would probably be more code and you would still end up writing what is essentially a driver. In other words in either case you will probably need the hardware specifications.
M.McCormack: Drivers belong in the kernel. If there's no Linux driver for a device, then Wine cannot support it. In that case, the first step is to write a Linux device driver for it, which has the added advantage that other native linux applications can use the hardware. The interface from user space to kernel space should be done via standard Linux mechanisms, such as ioctl. The Video4Linux API already offers such an interface. You can't load a Windows driver that accesses hardware in Wine, as Wine is a user-space application with no I/O privileges.
K.Ober disagreed: Not necessarily. In fact, only the part that directly touches the hardware really belongs there. There's nothing wrong with doing rest of the processing (i.e. the non time-critical parts) in the userspace. In fact, that likely makes the kernel a safer place.
M.Meissner: For still imaging devices the Linux side uses libgphoto2, which is in userspace and uses libusb to access the kernel.I would really suggest to implement STI on top of libgphoto2 and try loading kernel drivers
- 2005 Wine Archive Link - Writing a Scanner Driver
- Safedisk Driver difficulties
- 2004 Wine Archive Link - ODBC
- 2005 Wine Archive Link - Printer Drivers
There has lately [May 2005] been significant progress with some webcams and MSN messenger.
A programmer asked [Aug 05]: Can anyone point me to documentation/help or tools for disassembling Windows 95 drv and vxd files and/or porting them to wine?? Ideally I'd like to decode the windows drivers to help with developing a pure linux driver.
J. Lang: No. Wine doesn't provide support for device drivers. We have some fake VxDs in there, just for some old apps that called them to do non-device driver type things. [...you'll want to develop a pure linux driver], Disassembly may help. People around here seem to like IDA Pro. Search the wine-devel archives for more suggestions for disassemblers.
A. Mohr: [decoding the windows drivers to develop a linux driver is] the only really useful solution anyway... Oh, and I'd like to especially encourage you to *not* throw that card away and buy a new one, since Linux *does* need more sound drivers in order to be able to finally support *all* cards on the market. I've written an ALSA driver for the entirely undocumented Aztech PCI168 card (a low-end, crap card), by spending some weeks reverse-engineering Windows drivers using IDA (Interactive DisAssembler). (you might want to search the wine-devel archive for recent discussions of IDA, since someone asked about a nice selection of good disassemblers) [...] Another idea would be to try and see whether virtual machines such as VMWare can give an insight what the hardware interface looks like. But, most importantly, you should ask [The company] whether they will give you (parts of) the card specs required to be able to write a driver (without laborous reverse-engineering, that is). And of course you should read all relevant ALSA pages about supporting an undocumented sound card. And maybe the [card is similar to another supported card] That could be a start...
Feel free to ask me about further ALSA driver specifics, I may be able to help.
K. Ober: I'd start by politely asking [...] for the specs. Only if they openly refuse it's time to start working on a linux driver. As far as using wine for the task, I bet you might be better off instead by looking how the ndiswrapper folks have done it for NDIS drivers. Probably there's some wine code that you could snatch to implement something special that the driver needs, but presumably it'll be all rudimentary low-level stuff related to interfacing with the PCMCIA stack and so on, which is not present in wine anyway IIRC. Disclaimer: I'd start by extending ndiswrapper, but there of course are other ways :)
F. Nawothnig: FYI, the Win98 DDK is available online (for free) at MSDN somewhere.
D. Jovanovic: if you had a .sys file, it would be easy to reverse engineer, since Windows WDM drivers are nicely stacked and it is easy to insert "filter" drivers into the stack, to monitor IRP flow. Tools like usbsnoopy do this for USB drivers, I believe there are similar ones that work for other drivers in general. I never had a look at how you write VxD's, but there is stuff in the MSDN library (it should be accessible online, look for VDDs in the Windows DDK documentation). And have a look at whether the ReactOS project supports VxD's. Good luck, such device drivers are very ugly :-). Wine Archive