|
|
1.1 root 1: Build & Run Instructions:
2: -------------------------
3:
4:
5: The MONO sample is composed of a simple monolithic export driver
6: and a Win32 test application. The Win32 app retrieves a handle to
7: the driver/device by calling CreateFile("\\.\MONO", ...), where MONO
8: is a Win32 alias (or "symbolic link") for \Device\Mono, and
9: subsequently sends it I/O requests (IOCTLs) to have it perform I/O
10: on it's behalf.
11:
12:
13: NOTE: MONO is intended to be a generic monolithic driver sample;
14: it just happens that it was coded to support a monochrome
15: video adapter.
16:
17: Microsoft does not recommend the use this sample as a
18: template for video driver development. We encourage developers
19: to code within the stated video model; doing so will insure
20: compatibility & portability, lessen development time,
21: and produce smaller and more supportable code.
22:
23:
24: As mentioned above, MONO is an export driver; it provides a
25: MonoDbgPrint() API which may be called by other kernel mode drivers
26: that include a prototype & link with MONO.LIB, e.g. by adding
27: "TARGETLIBS=$(BASEDIR)\lib\*\mono.lib" to the sources file.
28: (This can make single machine driver debugging a little more bearable.
29: Note that the load order of the driver can be varied by changing
30: the Start value in the registry, 0 being the earliest starting
31: value. See Chapter 16 of the Kernel-mode Driver Design Guide for
32: mode information on driver load ordering.)
33:
34: There are currently three export drivers that ship with NT (i.e.
35: VIDEOPRT.SYS and SCSIPORT.SYS); these represent the port side of
36: the port/miniport driver model. The idea of this model is to split
37: the OS-specific functionality into a common port driver, while the
38: H/W specific functionality resides in the miniport driver. This
39: way, miniports remain portable across various platforms & systems,
40: and a single port driver can service several miniports on a particular
41: platform.
42:
43: The Win32 portion contains a file, MONOTEST.C, which attempts to
44: obtain a handle to MONO & send it IOCTLs. The executable is built
45: using the Windows NT SDK. First update the environment and path
46: by running <mstools>\setenv.bat. Then change to the directory
47: where you have the C source code and the makefile. Type
48: "nmake /f monotest.mak" to compile the Win32 program, MONOTEST.EXE.
49:
50: The kernel driver portion contains the driver source code, MONO.C
51: and a text file used to configure your registry so that the driver
52: can be loaded. The driver is built using the Windows NT DDK.
53:
54: To build the driver:
55:
56:
57: 1. Assuming you have run <sdk_root>\setenv.bat and
58: <ddk_root>\setenv.bat, build the driver by typing:
59:
60: build -cef
61:
62: (If there are any errors have a look at the build.log, build.err,
63: and build.wrn files to get an idea of what went wrong.)
64:
65:
66: 2. Copy the newly built driver, <ddk_root>\lib\*\MONO.SYS to the
67: <nt_root>\system32\drivers\ directory, i.e.:
68:
69: copy \ntddk\lib\i386\free\mono.sys c:\winnt\system32\drivers\
70:
71:
72: 3. Update the registry by running regini.exe on the mapmem.ini
73: file, i.e.:
74:
75: regini mono.ini
76:
77: This adds a MONO driver key under the HKEY_LOCAL_MACHINE\
78: SYSTEM\CurrentControlSet\Services tree in the registry. You
79: can verify this by starting REGEDIT.EXE and looking in the
80: appropriate place.
81:
82:
83: 4. Reboot.
84:
85:
86: 5. Type:
87:
88: net start mono
89:
90: ...and then execute MONOTEST.EXE.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.