|
|
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.