Chip 1994 February

home *** CD-ROM | disk | FTP | other *** search

/ Chip 1994 February / CHIP0294.ISO / digital / magazin / trumpet / pktdrvs / desqview.doc < prev next >

Wrap

Text File | 1992-08-04 | 13.2 KB | 275 lines

Crynwr TCP/IP Packet Drivers under DESQview A. Pirard - University of Liege - Belgium This text explains technical details to be understood in order to use the packet drivers under DESQview. I lists tested examples and expresses hopes for even better TCP/IP usability under multitasking. DESQview is a system that I've been using for some years and that I find terribly useful. It does true multitasking and windowing of normal DOS applications and adds keyboard macros and cut & paste beautifully. The setup of some applications may require technical knowledge or assistance, but once done correctly, they perform nicely. In this text, 'application' means the set of DOS programs that are executed in one window. 1 Theory -------- When each DESQview application is installed, its maximum memory size is indicated. DESQview itself can be installed in two flavors. Either each application takes its size out of what DESQview does not use of the 640 Kb the PC allows, and they must be swapped to disk to make room for more. Or, with an EEMS or (true) LIM 4.0 board and driver (expensive) or, by far the most comfortable, with a 386 processor and Quarterdeck's QEMM386 driver, much of the system extensions, including DESQview, can be loaded above the 640 Kb limit, and applications can execute simultaneously in large address spaces (typically 535 KB) that can total up to physical (extended) memory before swapping is required. The replicated address spaces are called memory banks. The banks may be compared to the floors of a department store, sharing the same ground area, but where different activities can take place. DESQview 'switches in' each memory bank in turn to give a few time slices of processor time to its application. One problem under DESQview and EMM is that the packet drivers execute calls to the TCP/IP applications. If they were executed before DESQview is started, they would not be loaded in banked memory and they would have to care to switch to the correct memory bank before the call, like climbing to the right floor to call for the right salesman. Fortunately, there is a solution for the following two reasons: 1) These calls only occur only during a hardware interrupt. I cannot swear for all packet drivers, but it cannot conceivably be otherwise. 2) DESQview supervises hardware interrupts and detects when a program grabs a vector to install a handler to service an interrupt that DESQview considers for 'communication'. When such an interrupt occurs, DESQview switches to the correct memory bank before giving control to the handler. The 'communication' interrupts are: 2, 3, 4 and 7 (plus 5 on AT) and, in the latest versions (4.26), 8-15. (Note that each application has its own set of interrupt vectors, but that the handler will execute with the set of the application that was interrupted, except its own interrupt 15h; it should rely only on its private memory). 3) But when a packet driver just interfaces with another driver, the latter may in turn do calls to the first. In this case, try to apply the same method as in the text about IBMTOKEN below. So, if a packet driver is loaded as part of an application, its initialization will grab the interrupt vector of the communication card, DESQview will notice this, and interrupts and calls will occur under the correct memory bank. Should it be loaded before DESQview is active to see which interrupt is used, DESQview will not switch memory during interrupts, and the calls it cannot control will be made to the wrong memory bank and crash the system. Note that this doesn't hold for a flat memory space (first flavor) because there is no memory bank. But packet drivers are of no use to more than one application simultaneously (as I will regret below), and it consumes less permanent memory to load drivers in the application even then. The application should close the device nicely by executing the packet drivers utility 'termin'. Termin makes sure no more interrupts will occur. Should termin not work (or not be given a chance to be executed, when the window is closed abnormally), things may still work. Here is why: 1) On a PC, the default interrupt handler should make sure they don't bother the system (either nullifying service (EOI+IRET) or best preventing them to occur (mask them at the controller)). 2) If the window is closed, DESQview returns the interrupts to the default handler (that was used before DESQview was started). However, I have experienced that a Token-Ring card will crash the system when on interrupt IRQ2 but not on IRQ10 or IRQ11. Experiment if necessary. In any case, the application must be installed as non-swappable. Note that the rumor that DESQview moves code about in memory is false, only Windows does. With QEMM, make sure it knows where your communication card RAM is (QEMM parameters). Some cards hide the RAM until initialized. 2 Example --------- A application using a packet driver can be installed by cloning 'Big DOS'. It must be non-swappable. Of course, 'Memory Size' depends on storage available and needed by the TCP/IP program. The examples below run with DESQview 2.26, QEMM 5.0 and drivers 7 on a PS/2 70: Program Name............: CUTCP Keys to Use on Open Menu: TR Memory Size (in K): 450 ---------------------------------------------------------------------------- Program...: C:\TCPIP\tcpip Parameters: call command /E:1024 /C c:\tcpip\cutcp tr g vm1 Directory.: C:\TEST ---------------------------------------------------------------------------- Options: Writes text directly to screen.......: [Y] Displays graphics information........: [Y] Virtualize text/graphics (Y,N,T).....: [Y] Uses serial ports (Y,N,1,2)..........: [Y] Requires floppy diskette.............: [N] System Memory (in K).......: 4 Maximum Program Memory Size (in K)..: 640 Script Buffer Size.......: 2000 Maximum Expanded Memory Size (in K): 256 Text Pages: 4 Graphics Pages: 2 Initial Mode: Interrupts: 00 to FF ---------------------------------------------------------------------------- Window Position: Maximum Height: 25 Starting Height: 25 Starting Row...: 0 Maximum Width.: 80 Starting Width.: 80 Starting Column: 0 ---------------------------------------------------------------------------- Shared Program Pathname..: Data......: ---------------------------------------------------------------------------- Close on exit (Y,N,blank)......: [N] Uses its own colors..............: [Y] Allow Close Window command.....: [N] Runs in background (Y,N,blank)...: [ ] Uses math coprocessor..........: [Y] Keyboard conflict (0-F)..........: [0] Share CPU when foreground......: [Y] Share EGA when foreground/zoomed.: [Y] Can be swapped out (Y,N,blank).: [N] Protection level (0-3)...........: [0] with the procedure TCPIP: c:\tcpip\drivers\3c523 0x60 7 0x300 0xC000 %1 %2 %3 %4 %5 %6 %7 %8 %9 c:\tcpip\drivers6\termin 0x60 exit and the procedure CUTCP: set $CUTCP1=include~c:\tcpip\cutcp.c%1tr (network administrator setup) set $CUTCP2=include~c:\tcpip\cutcp.nik c:\tcpip\cutcp\tn3270 -d 0 -h c:\tcpip\cutcp.tel %2 %3 %4 %5 %6 %7 %8 If one wishes DOS commands under packet drivers, use only the application setup 'Parameter': 'call command /E:1024'. 'EXIT' will terminate the application nicely. Note: really, 3C523 v6.1 has (had?) a bug that can be overcome by executing the version 5 once after each machine boot. 3 Token-Ring driver ------------------- IBMTOKEN uses the IBM drivers DXMA0MOD.SYS and DXMC0MOD.SYS (A and C for short). This complicates things a bit. C is the driver to grab the communication vector and, for the same reason as with packet drivers, must be loaded within the DESQview application. But C calls A for services via interrupt 5C. And if closing an application does not tell C to 'say good-bye' to A (if ever there is provision for that) before simply removing it from memory, A will tell C that it is already loaded when the application is started again. Consequently, A too must be loaded inside the application so that a fresh copy won't complain. But A sets flags in low core and will say that it is already active. Resetting these flags is the end of the story (almost, sorry but that's the way it is). DESQview installs a front-end to make sure that interrupt 5C is not preempted by another task. Letting things go would make A installing only its own 5C processing, and without DESQview's front end, TCP/IP will lock after a while by receiving no more IP data. Resetting the flag and preserving DESQview's front-end is the trickery behind the modules IBMTRDVx that I added to the packet driver collection. Using IRQ2 for the Token-Ring card will crash the system when the window is closed and C 'brutally' removed from memory. Configure it to use IRQ10 or 11 instead (on a PS/2, that's booting with the reference diskette to change the TRN card setup). Then, use the application installation above with the following procedure TCPIP: d:\ibmpclan\ibmtrdv1 device D:\IBMPCLAN\DXMA0MOD.SYS d:\ibmpclan\ibmtrdv2 device D:\IBMPCLAN\DXMC0MOD.SYS , :or device D:\IBMPCLAN\DXMC0MOD.SYS 4000010430A0 c:\tcpip\drivers\ibmtoken 0x60 0 %1 %2 %3 %4 %5 %6 %7 %8 %9 c:\tcpip\drivers6\termin 0x60 d:\ibmpclan\ibmtrdv3 exit Notes: - the command 'device' is DESQview's, to load a SYS device driver as if it were plain COM. - Without the 'Locally managed address' parameter, a comma is required. I don't know which of IBM or Quarterdeck is right about the parameter memory format. - The whole Token Ring stuff is my real best. It works fine. But I cannot guarantee it does in all versions of the products involved. 4 Wishes -------- Packet driver applications will execute in only a single DESQview window, just like under monotasking DOS, but no worse. TCP/IP has been devised with a multitasking environment in mind. MSDOS did not provide multitasking, forcing people to write monotasking TCP/IP applications instead. They probably simulate multitasking internally to some extent. Now that we have DESQview and Windows 3, TCP/IP on the PC should be rethought. Multitasking DOS TCP/IP is making IP+TCP run in a separate window and applications (in other windows) interface with them via a socket API. This means an unloadable socket driver module that would depend on the environment, and interface the applications with the module containing IP+TCP. Under plain DOS, it would make plain calls. Under DESQview or Windows, it would be in common memory and provide task switching and synchronization (doing without loops). TCP Inc have (maybe a standard for) a socket API and told me they have tried but got problems to make it DESQview compatible. I guess it should be feasible and that all is to be gained by everyone if FTP Inc did cooperate with Quarterdeck and Microsoft for a tremendous improvement of this API. I wouldn't be surprised most public domain TCP/IP applications use the socket API, even if internally, and should be easily converted to use an external one, maybe on a bimodal basis to make them portable. DESQview and Windows environments are similar enough in this respect to kill the two birds with one stone. I hope Quarterdeck won't mind my quoting their words. I'd like them to be heard by FTP Inc. about feasibility: "One thing I can tell you: we are working on a driver which does indeed watch for NETBIOS or IPX calls which would require that the program be "mapped" back into memory in order for the call to operate correctly." And now that the packet drivers have promiscuous mode, a similar enhancement would be most welcome at the data link level: recognize the environment, remember the address space of subscribers and provide task switching. Wouldn't it be lovely to have NETWATCH trace an application in another window?. Finally, I'll report some words about usability of TCP/IP applications to us, those 'foreign' languages speakers. We badly need an 8-bit character set. The problem is that extensions of ASCII on different computers are incompatible and, for example, that text sent from a PC to a Mac or vice versa is incorrect. Just as IBM EBCDIC has to be translated to a common line code, ASCII, those different extended codes should be translated to a common one. RFCs should state (or programs act as if they did) that 8-bit is allowed (most often, 8- bit 'works') and that the code to be used is the true international standard ISO 8859. X-Windows already does that, why not Telnet, FTP and SMTP to name the main ones? IBM shouldn't be allowed to slip in its PC and EBCDIC codes by lack of standard. Even Telnet 3270 should use ISO 8859 because no one but IBM mainframers know what EBCDIC is (or should I say 'one' EBCDIC?). But by far the easiest is that all those systems themselves start using ISO 8859, isn't it? Thanks for considering this point for us to enjoy TCP/IP as much as you do.