garrett@brahms.udel.edu (Joel Garrett) (12/08/90)
Hello fellow cwmp readers! I am working on a project that has controlled a set of stepper motors through a controller/interface card that has been operated via IN and OUT statements in either MS C or QuickBasic in real mode under MS-DOS. We want to develop a newer version of this application that would make use of Windows 3.0 for its user interface. The manufacturer of the stepper motor controller already has device drivers for their boards for MS C under MS-DOS, but based on what I've read in this newsgroup and in the Petzold book, I have a feeling that this approach will either not work under Windows or force a lot of restrictions on how the application would run (i.e. not a very Windows-friendly application would result - the program would essentially have to hog the system while running) 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? Thank you very much for any advice you might be able to give us in this endeavour... Joel Garrett garrett@brahms.udel.edu
dzoey@terminus.umd.edu (Joe Herman) (12/09/90)
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."
spolsky-joel@cs.yale.edu (Joel Spolsky) (12/09/90)
In article <7690@umd5.umd.edu> dzoey@terminus.umd.edu (Joe Herman) writes: >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? > >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. You are making this all much more complicated than necessary. You can just take the old library, change the function calls to PASCAL, and recompile it as a DLL. That's all. A DLL can use in and out from the C library. (So can a Windows program). Joel Spolsky spolsky@cs.yale.edu