Synopsis
IO.DLL allows seamless port I/O operations for Windows 95/98/NT/2000/XP using the same library.
Introduction
In the pre-Windows days, it was a relatively simple matter to access I/O ports on a typical PC. Indeed, nearly every language sported a special command for doing so. As Windows emerged and gradually evolved, this flapping in the wind behaviour could no longer be tolerated because of operating system's ability to virtualize hardware.
Virtualizing hardware means that an application (typically a DOS box in Windows) believes it is talking directly to a physical device, but in reality it is talking to a driver that emulates the hardware, passing data back and forth as appropriate. This is how you are able to open dozens of DOS boxes in your Windows session, each one with the strange notion that it has exclusive access to peripherals such as the video adapter, keyboard, sound card and printer.
If one were to rudely bang out data to an I/O port that Windows thought it was in full control of, the "official bad thing" could occur, the severity of which depending upon the exact hardware that was being accessed. Actually, with the virtualization just mentioned, it is quite improbable that Windows would permit anything too nasty from occuring.
Windows 95/98 actually does allow I/O operations be executed at the application level, although you'd be hard pressed to find a language that supports this directly. Typically the programmer will have to resort to assembly language for this kind of low-level control. If you know what you are doing, this can be a quick and easy way to access I/O ports. Of course, not everyone knows, or desires to learn 80x86 assembly programming just because they want to turn on a lamp from their computer. However, the unwillingness to learn assembly language becomes rather trivial when faced with 9x's big brother.
Windows NT/2000/XP, being the secure operating system that it is, does not permit port I/O operations at the application level at all. Period. A program with inline IN and OUT assembly instructions that runs perfectly on Windows 95/98 will fail horribly when it comes to Windows NT/2000/XP.
Windows NT/2000/XP does, however, allow I/O instructions in its kernel mode drivers. A kernel mode driver runs at the most priviledged level of the processor and can do whatever it pleases, including screwing up the system beyond repair, thus writing a kernel mode driver is not for the feint of heart.
If you were to take it upon yourself to wade through the documentation of the Windows NT/2000/XP ddk and piece together a driver that was callable by your application to do the I/O instructions on behalf of your application, you'd probably notice something not too pleasant--this sort of access is painfully slow. The call from application level to system level typically takes about one millisecond. Compare this to the one microsecond that a normal I/O access takes. To further the insult, you are at the whim of the operating system. If it has tasks which it believes are of higher priority than your lowly call to your driver, it will perform them, making precise timing nearly impossible.
Obviously, writing a driver that does acts a proxy for the I/O calls isn't the most ideal solution. There is, however, a solution for NT/2000/XP that allows the same convienience of inline assembly language that 95/98 does.
As mentioned, a kernel mode driver can do whatever it wants. The implication here is that if another kernel mode driver shut off application access to the I/O ports, it should be possible for another kernel mode driver to turn it back on. This is where IO.DLL enters the picture.
Visit Geek Hideout
No comments:
Post a Comment