This can actually depend on a couple things. In NT, there are miniport and
regular drivers. The reason for the miniport drivers is to get a single
codebase that compiles under Windows NT and Windows 95. Currently, there
are SCSI, network, and printer miniport drivers. These drivers call
functions that are exported by base libraries. These sorts of drivers
would probably be easier to implement since they are more limited in what
they can do. However, they still assume things like the registry are
available. It would seem that having a registry equivalent would probably
be required.
Full driver support would be a very painful process since there are a
large number of calls, and drivers can be *very* dependent on all kinds
of things in the registry. Most get things from a small subtree in the
registry, but not all.
> And it may very well end up being that the way NT does it virtual memory
> is fundamentally incompatible with how Linux's VM subsystem works, so
> compatibility at the binary level, or even source level, might be
> well-nigh impossible.
I don't think this would be too much of a problem. Some tweaks might
be required, but I don't recall seeing anything in the memory interfaces
that was completely incompatible.
In terms of licensing, the Microsoft Master End-User License Agreement
only allows a licensee of the DDK to use it "for the sole purposes of
designing, developing, and testing your software product(s) which operate
in conjunction with Microsoft Windows(R) or Windows NT(tm)." And Microsoft
Visual C++, the only compiler that can currently create a device driver
that works with Windows NT (unless this changed very recently), states
that you can only use it to develop software for Windows. I don't know if
this qualifies as anti-competitive or illegal in any jurisdictions, but at
the least it would put any effort to create a shim driver under a bit of a
legal question mark.
Gordon Chaffee
chaffee@bmrc.berkeley.edu
http://bmrc.berkeley.edu/people/chaffee