home *** CD-ROM | disk | FTP | other *** search
/ Mega CD-ROM 1 / megacd_rom_1.zip / megacd_rom_1 / NETWORK / DRIVERS.ZIP / DESQVIEW.DOC < prev    next >
Text File  |  1991-01-25  |  13KB  |  275 lines
  1.  
  2.  
  3.             Clarkson TCP/IP Packet Drivers under DESQview
  4.               A. Pirard - University of Liege - Belgium
  5.  
  6.      This text explains technical details to be understood in order to
  7. use the packet drivers under DESQview. I lists tested examples and
  8. expresses hopes for even better TCP/IP usability under multitasking.
  9.  
  10.      DESQview is a system that I've been using for some years and that
  11. I find terribly useful. It does true multitasking and windowing of
  12. normal DOS applications and adds keyboard macros and cut & paste
  13. beautifully. The setup of some applications may require technical
  14. knowledge or assistance, but once done correctly, they perform nicely.
  15. In this text, 'application' means the set of DOS programs that are
  16. executed in one window.
  17.  
  18.  
  19. 1 Theory
  20. --------
  21.  
  22.      When each DESQview application is installed, its maximum memory
  23. size is indicated. DESQview itself can be installed in two flavors.
  24. Either each application takes its size out of what DESQview does not
  25. use of the 640 Kb the PC allows, and they must be swapped to disk to
  26. make room for more. Or, with an EEMS or (true) LIM 4.0 board and
  27. driver (expensive) or, by far the most comfortable, with a 386
  28. processor and Quarterdeck's QEMM386 driver, much of the system
  29. extensions, including DESQview, can be loaded above the 640 Kb limit,
  30. and applications can execute simultaneously in large address spaces
  31. (typically 535 KB) that can total up to physical (extended) memory
  32. before swapping is required. The replicated address spaces are called
  33. memory banks. The banks may be compared to the floors of a department
  34. store, sharing the same ground area, but where different activities
  35. can take place. DESQview 'switches in' each memory bank in turn to
  36. give a few time slices of processor time to its application.
  37.  
  38.      One problem under DESQview and EMM is that the packet drivers
  39. execute calls to the TCP/IP applications. If they were executed before
  40. DESQview is started, they would not be loaded in banked memory and
  41. they would have to care to switch to the correct memory bank before
  42. the call, like climbing to the right floor to call for the right
  43. salesman.
  44.  
  45.      Fortunately, there is a solution for the following two reasons:
  46.      1) These calls only occur only during a hardware interrupt. I
  47. cannot swear for all packet drivers, but it cannot conceivably be
  48. otherwise.
  49.      2) DESQview supervises hardware interrupts and detects when a
  50. program grabs a vector to install a handler to service an interrupt
  51. that DESQview considers for 'communication'. When such an interrupt
  52. occurs, DESQview switches to the correct memory bank before giving
  53. control to the handler. The 'communication' interrupts are: 2, 3, 4
  54. and 7 (plus 5 on AT) and, in the latest versions (4.26), 8-15. (Note
  55. that each application has its own set of interrupt vectors, but that
  56. the handler will execute with the set of the application that was
  57. interrupted, except its own interrupt 15h; it should rely only on its
  58. private memory).
  59.      3) But when a Clarkson driver just interfaces with another
  60. driver, the latter may in turn do calls to the first. In this case,
  61. try to apply the same method as in the text about IBMTOKEN below.
  62.  
  63.      So, if a packet driver is loaded as part of an application, its
  64. initialization will grab the interrupt vector of the communication
  65. card, DESQview will notice this, and interrupts and calls will occur
  66. under the correct memory bank. Should it be loaded before DESQview is
  67. active to see which interrupt is used, DESQview will not switch memory
  68. during interrupts, and the calls it cannot control will be made to the
  69. wrong memory bank and crash the system. Note that this doesn't hold
  70. for a flat memory space (first flavor) because there is no memory
  71. bank. But packet drivers are of no use to more than one application
  72. simultaneously (as I will regret below), and it consumes less
  73. permanent memory to load drivers in the application even then.
  74.  
  75.      The application should close the device nicely by executing the
  76. packet drivers utility 'termin'. Termin makes sure no more interrupts
  77. will occur. Should termin not work (or not be given a chance to be
  78. executed, when the window is closed abnormally), things may still
  79. work. Here is why:
  80.      1) On a PC, the default interrupt handler should make sure they
  81. don't bother the system (either nullifying service (EOI+IRET) or best
  82. preventing them to occur (mask them at the controller)).
  83.      2) If the window is closed, DESQview returns the interrupts to
  84. the default handler (that was used before DESQview was started).
  85.      However, I have experienced that a Token-Ring card will crash the
  86. system when on interrupt IRQ2 but not on IRQ10 or IRQ11. Experiment if
  87. necessary.
  88.  
  89.      In any case, the application must be installed as non-swappable.
  90. Note that the rumor that DESQview moves code about in memory is false,
  91. only Windows does.
  92.  
  93.      With QEMM, make sure it knows where your communication card RAM
  94. is (QEMM parameters). Some cards hide the RAM until initialized.
  95.  
  96.  
  97.  
  98. 2 Example
  99. ---------
  100.  
  101.      A application using a packet driver can be installed by cloning
  102. 'Big DOS'. It must be non-swappable. Of course, 'Memory Size' depends
  103. on storage available and needed by the TCP/IP program. The examples
  104. below run with DESQview 2.26, QEMM 5.0 and drivers 7 on a PS/2 70:
  105.  
  106. Program Name............: CUTCP
  107.  
  108. Keys to Use on Open Menu: TR                         Memory Size (in K): 450
  109. ----------------------------------------------------------------------------
  110. Program...: C:\TCPIP\tcpip
  111.  
  112. Parameters: call command /E:1024 /C c:\tcpip\cutcp tr g vm1
  113.  
  114. Directory.: C:\TEST
  115. ----------------------------------------------------------------------------
  116.  Options:
  117.                   Writes text directly to screen.......: [Y]
  118.                   Displays graphics information........: [Y]
  119.                   Virtualize text/graphics (Y,N,T).....: [Y]
  120.                   Uses serial ports (Y,N,1,2)..........: [Y]
  121.                   Requires floppy diskette.............: [N]
  122.  
  123.  
  124. System Memory (in K).......:   4   Maximum Program Memory Size (in K)..: 640
  125.  
  126. Script Buffer Size.......:  2000   Maximum Expanded Memory Size (in K):  256
  127.  
  128. Text Pages: 4  Graphics Pages: 2   Initial Mode:        Interrupts: 00 to FF
  129. ----------------------------------------------------------------------------
  130. Window Position:
  131.    Maximum Height:  25       Starting Height:  25       Starting Row...:   0
  132.    Maximum Width.:  80       Starting Width.:  80       Starting Column:   0
  133. ----------------------------------------------------------------------------
  134.                                Shared Program
  135. Pathname..:
  136. Data......:
  137. ----------------------------------------------------------------------------
  138. Close on exit (Y,N,blank)......: [N]  Uses its own colors..............: [Y]
  139. Allow Close Window command.....: [N]  Runs in background (Y,N,blank)...: [ ]
  140. Uses math coprocessor..........: [Y]  Keyboard conflict (0-F)..........: [0]
  141. Share CPU when foreground......: [Y]  Share EGA when foreground/zoomed.: [Y]
  142. Can be swapped out (Y,N,blank).: [N]  Protection level (0-3)...........: [0]
  143.  
  144. with the procedure TCPIP:
  145.  
  146. c:\tcpip\drivers\3c523 0x60 7 0x300 0xC000
  147. %1 %2 %3 %4 %5 %6 %7 %8 %9
  148. c:\tcpip\drivers6\termin 0x60
  149. exit
  150.  
  151. and the procedure CUTCP:
  152.  
  153. set $CUTCP1=include~c:\tcpip\cutcp.c%1tr (network administrator setup)
  154. set $CUTCP2=include~c:\tcpip\cutcp.nik
  155. c:\tcpip\cutcp\tn3270 -d 0 -h c:\tcpip\cutcp.tel %2 %3 %4 %5 %6 %7 %8
  156.  
  157.      If one wishes DOS commands under packet drivers, use only the
  158. application setup 'Parameter': 'call command /E:1024'. 'EXIT' will
  159. terminate the application nicely.
  160.      Note: really, 3C523 v6.1 has (had?) a bug that can be overcome by
  161. executing the version 5 once after each machine boot.
  162.  
  163.  
  164. 3 Token-Ring driver
  165. -------------------
  166.  
  167.      IBMTOKEN uses the IBM drivers DXMA0MOD.SYS and DXMC0MOD.SYS (A
  168. and C for short). This complicates things a bit.
  169.  
  170.      C is the driver to grab the communication vector and, for the
  171. same reason as with packet drivers, must be loaded within the DESQview
  172. application. But C calls A for services via interrupt 5C. And if
  173. closing an application does not tell C to 'say good-bye' to A (if ever
  174. there is provision for that) before simply removing it from memory, A
  175. will tell C that it is already loaded when the application is started
  176. again. Consequently, A too must be loaded inside the application so
  177. that a fresh copy won't complain. But A sets flags in low core and
  178. will say that it is already active. Resetting these flags is the end
  179. of the story (almost, sorry but that's the way it is). DESQview
  180. installs a front-end to make sure that interrupt 5C is not preempted
  181. by another task. Letting things go would make A installing only its
  182. own 5C processing, and without DESQview's front end, TCP/IP will lock
  183. after a while by receiving no more IP data. Resetting the flag and
  184. preserving DESQview's front-end is the trickery behind the modules
  185. IBMTRDVx that I added to the Clarkson library.
  186.  
  187.      Using IRQ2 for the Token-Ring card will crash the system when the
  188. window is closed and C 'brutally' removed from memory. Configure it to
  189. use IRQ10 or 11 instead (on a PS/2, that's booting with the reference
  190. diskette to change the TRN card setup). Then, use the application
  191. installation above with the following procedure TCPIP:
  192.  
  193. d:\ibmpclan\ibmtrdv1
  194. device D:\IBMPCLAN\DXMA0MOD.SYS
  195. d:\ibmpclan\ibmtrdv2
  196. device D:\IBMPCLAN\DXMC0MOD.SYS ,
  197. :or device D:\IBMPCLAN\DXMC0MOD.SYS 4000010430A0
  198. c:\tcpip\drivers\ibmtoken 0x60 0
  199. %1 %2 %3 %4 %5 %6 %7 %8 %9
  200. c:\tcpip\drivers6\termin 0x60
  201. d:\ibmpclan\ibmtrdv3
  202. exit
  203.  
  204. Notes:
  205. - the command 'device' is DESQview's, to load a SYS device driver as
  206. if it were plain COM.
  207. - Without the 'Locally managed address' parameter, a comma is
  208. required. I don't know which of IBM or Quarterdeck is right about the
  209. parameter memory format.
  210. - The whole Token Ring stuff is my real best. It works fine. But I
  211. cannot guarantee it does in all versions of the products involved.
  212.  
  213.  
  214. 4 Wishes
  215. --------
  216.  
  217.      Packet driver applications will execute in only a single DESQview
  218. window, just like under monotasking DOS, but no worse. TCP/IP has been
  219. devised with a multitasking environment in mind. MSDOS did not provide
  220. multitasking, forcing people to write monotasking TCP/IP applications
  221. instead. They probably simulate multitasking internally to some
  222. extent. Now that we have DESQview and Windows 3, TCP/IP on the PC
  223. should be rethought.
  224.  
  225.      Multitasking DOS TCP/IP is making IP+TCP run in a separate window
  226. and applications (in other windows) interface with them via a socket
  227. API. This means an unloadable socket driver module that would depend
  228. on the environment, and interface the applications with the module
  229. containing IP+TCP. Under plain DOS, it would make plain calls. Under
  230. DESQview or Windows, it would be in common memory and provide task
  231. switching and synchronization (doing without loops).
  232.  
  233.      TCP Inc have (maybe a standard for) a socket API and told me they
  234. have tried but got problems to make it DESQview compatible. I guess it
  235. should be feasible and that all is to be gained by everyone if FTP Inc
  236. did cooperate with Quarterdeck and Microsoft for a tremendous
  237. improvement of this API. I wouldn't be surprised most public domain
  238. TCP/IP applications use the socket API, even if internally, and should
  239. be easily converted to use an external one, maybe on a bimodal basis
  240. to make them portable.
  241.      DESQview and Windows environments are similar enough in this
  242. respect to kill the two birds with one stone.
  243.      I hope Quarterdeck won't mind my quoting their words. I'd like
  244. them to be heard by FTP Inc. about feasibility:
  245. "One thing I can tell you:  we are working on a driver which does
  246. indeed watch for NETBIOS or IPX calls which would require that the
  247. program be "mapped" back into memory in order for the call to operate
  248. correctly."
  249.  
  250.      And now that the packet drivers have promiscuous mode, a similar
  251. enhancement would be most welcome at the data link level: recognize
  252. the environment, remember the address space of subscribers and provide
  253. task switching. Wouldn't it be lovely to have NETWATCH trace an
  254. application in another window?.
  255.  
  256.      Finally, I'll report some words about usability of TCP/IP
  257. applications to us, those 'foreign' languages speakers. We badly need
  258. an 8-bit character set. The problem is that extensions of ASCII on
  259. different computers are incompatible and, for example, that text sent
  260. from a PC to a Mac or vice versa is incorrect. Just as IBM EBCDIC has
  261. to be translated to a common line code, ASCII, those different
  262. extended codes should be translated to a common one. RFCs should state
  263. (or programs act as if they did) that 8-bit is allowed (most often, 8-
  264. bit 'works') and that the code to be used is the true international
  265. standard ISO 8859. X-Windows already does that, why not Telnet, FTP
  266. and SMTP to name the main ones? IBM shouldn't be allowed to slip in
  267. its PC and EBCDIC codes by lack of standard. Even Telnet 3270 should
  268. use ISO 8859 because no one but IBM mainframers know what EBCDIC is
  269. (or should I say 'one' EBCDIC?).
  270.      But by far the easiest is that all those systems themselves start
  271. using ISO 8859, isn't it?
  272.      Thanks for considering this point for us to enjoy TCP/IP as much
  273. as you do.
  274.  
  275.