1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
|
The entire archive was pulled from here:
Dr. Dobb's Journal, http://www.ddj.com/ftp/1996/1996.05/directio.zip
It contained some other snippets too, but as they are not useful here
I don't include them here.
chris
Following is the original readme of the archive:
-----------------------------------------------------------------------------
Author: Dale Roberts, Direct I/O and Windows NT
Here are two helpful hints to get you going with GIVEIO. The first
section below mentions the INSTDRV utility that is provided with the
Microsoft DDK. If you do not have access to the DDK, you can use Paula
Tomlinson's program LOADDRV instead. She describes it in her May 1995
article in Windows/DOS Developer's Journal (now Windows Developer's
Journal). You can get the program from their FTP site at:
ftp://ftp.mfi.com/pub/windev/1995/may95.zip.
------------------------------------------------------------------
Device Driver Installation Made Easy
The Microsoft NT Device Driver Kit documentation implies in several
places that there are several steps involved in installing a device driver
and making it accessible to a Win32 application. It explains that you
should edit the registry manually and then reboot the system. But
device drivers are dynamically loadable and unloadable in NT, and the
DDK comes with a very handy utility called INSTDRV that
demonstrates this facility in a very practical manner.
INSTDRV is a console application that will register, load, and start a
kernel mode device driver. It does not require you to edit the registry
manually or reboot the computer. On the command line you simply
give the name of your device driver and the complete path to the .SYS
file (which does not need to be in the system's DRIVERS directory).
After this command is executed, you will find that the driver has been
registered with the system and appears in the Devices applet in the
control panel. If you give the word remove instead of the path, the
driver is removed from the system and taken out of the driver database.
Once the driver is loaded and started, you can use the control panel's
Devices applet to start and stop it, or you can use the net start and net
stop commands (these are much faster) from a console window. When
a kernel mode device is stopped, it is in also unloaded from memory.
The next time you start the device, a fresh copy of the driver is read
from the hard drive, if it has been modified. This makes it very
convenient to develop device drivers, since you can go through the
modify, stop, start cycle repeatedly without ever needing to reboot. If
you need your driver to load at boot time, you can go into the Devices
applet and change its startup mode to boot.
The other component that is needed to make the driver visible to user
mode applications, so they can use CreateFile() calls to access the
driver, is registering the name in the DOS Devices name space. This
can be done, as documented in the DDK, by editing the registry
manually and rebooting. Or, much more simply, the kernel mode
driver can call the IoCreateSymbolicLink() function to register the
name itself. The GIVEIO driver shown in Listing Four uses the later
technique. Once the name is registered, user mode applications can get
a file handle to the device driver by calling CreateFile() with the driver
name as the file parameter, but preceding the driver name with the
special cookie \\.\. The TESTIO application in Listing Five uses this
technique.
------------------------------------------------------------------
Quick Trick: Using DEBUG With Port I/O
Sometimes you just need to do a quick I/O operation to a port. In DOS,
you could use the DEBUG program to accomplish this. In NT, once
you have the GIVEIO device driver up and running, you can once
again use DEBUG for port I/O. If you look at the source code for the
test application, you'll see that all it does is open and close the GIVEIO
device driver. It uses the special cookie \\.\ before the driver name in
order to access it. Without modifying DEBUG, you can have it open
this device driver by simply typing debug \\.\giveio in an NT console
window. You will get an error message complaining that the file
\\.\giveio is not found, but it will give DEBUG I/O access anyway.
Subsequent DOS applications that are run from this console window
will also have I/O access.
WIN32 applications executed from this console window will still cause
exceptions. This is because DEBUG (and any other DOS application)
runs in the context of the VDM (Virtual DOS Machine) process of the
console box, whereas each WIN32 application gets its own process.
The VDM process stays active as long as the console window is open,
but each WIN32 application creates a brand new process with the
IOPM offset initialized to point beyond the end of the TSS.
|
