Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!caen!uflorida!haven!umd5!terminus.umd.edu!dzoey From: dzoey@terminus.umd.edu (Joe Herman) Newsgroups: comp.windows.ms.programmer Subject: Re: Accessing devices with port I/O in Windows? (LONG) Message-ID: <7690@umd5.umd.edu> Date: 8 Dec 90 19:39:31 GMT References: <16648@brahms.udel.edu> Sender: news@umd5.umd.edu Organization: University of Maryland DOSIP-CSC Lines: 80 In article <16648@brahms.udel.edu> garrett@brahms.udel.edu (Joel Garrett) writes: > >If we already have source code for a driver in C under the regular MS-DOS >environment, can this be easily adapted to work in the Windows Environment? > >Will we need to get the Windows DDK? We've already got MS C 6.0 and the SDK >for 3.0 Will we need anything else, like MASM? Will the existing MSC >libraries for things like software interrupts and such suffice so that we >wouldn't need to code in MASM? Warning note: I think what I am saying is correct. I have a DDK, but am only just starting to get familiar with the concepts. Please let me know if I flub this. This article makes the assumption you are running on a 386 in protected mode. First, some terminology: V86 is a virtual 8086 mode. The 80386 supports multiple logical 8086 environments. Any part of DOS that was loaded before windows is run is global (visible) to all V86 sessions. Each V86 session has an ID which identifies. You can use DPMI to fetch this ID if you care. All windows apps execute in VM 1. Each DOS session has its own VMID under WIN3 /E. Protected Mode: Win 3 operates in protected mode which allows it to make full use of the 80386 memory protection and 32 bit address space. You can do this in four ways. One is to take your existing device driver (the section of the code that talks to the device) and make it a TSR that communicates via an interrupt. Load the TSR before you go into windows so that it is global to all of windows. Have your windows program communicate with the device via a user defined interrupt. The Windows VMM contains code that reflects any interrupts from protected mode apps down into real mode if a protected mode handler doesn't handle them. This is approximately what WINQVT/NET does with NCSA telnet and packet drivers. For the above you do not need the DDK or MASM, though I strongly suggest using MASM to keep down on code size. This method is restricted in that only one instance of a windows APP can use the device (unless you provide serialization methods in your APP. This method is the easiest for to write, but is the slowest. Two is write a DPMI aware handler for the device. This is similar to the above regular DOS TSR except that it is DPMI aware and will remember which VMID made which request. This allows the device to be shared by your windows program and any DOS program running in one of the DOS session boxes. You don't need the DDK for this, though the DPMI spec (available from Intel, Order # 240743-001) is required. You don't need MASM, but it'd make life easier. Three is write a windows device driver that talks to the device in V86 mode. This will allow multiple instances of your app to be run and may also allow access to the device from within a V86 machine. It would could communicate with Windows APPS using any of the various windows IPC mechanisms and could communicate with V86 machines via an interrupt handler. You need the DDK and MASM for this. There are DDK functions to hook port i/o. Four is to write a protected mode only device driver that communicates with the card in protected mode. This is much faster than the other methods since the processor doesn't have to switch states to handle the communication. I don't know alot about this mode. You need the DDK and MASM. It only works from within windows. I would think a combination of methods three and four would give you a fast, robust implementation, but it may be difficult to write. Hope this helps. Send me mail if you want some more details. Joe Herman U. of Maryland dzoey@terminus.umd.edu -- "Everything is wonderful until you know something about it."