home *** CD-ROM | disk | FTP | other *** search
/ Programmer 7500 / MAX_PROGRAMMERS.iso / PROGRAMS / UTILS / COMMUNIC / MSKERM30.ZIP / KERMIT.PIF < prev    next >
Encoding:
Text File  |  1990-01-18  |  4.5 KB  |  87 lines
  1. COMMENTS ON RUNNING KERMIT 3.0 FOR THE IBM PC UNDER MICROSOFT WINDOWS
  2.  
  3. Kermit 2.32/A will successfully run in a window with Microsoft Windows and
  4. will accept cut and pasted information.  Scripts and phone dialing instructions
  5. are cases of cut and paste replacing the keyboard.  Use the PIFEDIT program to
  6. construct a .PIF file for Kermit, following the guidelines below.
  7.  
  8. Program name:           KERMIT.EXE or whatever is the name of the Kermit file.
  9. Program title:          MS-DOS Kermit 3.0
  10. Program parameters:     Leave blank since this becomes a command line
  11. Initial directory:      Directory, if any, to CD to when starting Kermit
  12. Memory Requirements:    128 KB Required, 160 KB Desired
  13. Directly Modifies:      Clear all boxes (pretend Kermit is very good)
  14. Program Switch:         Check the Text box
  15. Screen Exchange:        Check the Graphics/Text box
  16. Close Window on exit:   Check the box
  17.  
  18. Comments.  Although Kermit does direct writes to the screen it does so in a
  19. "TopView aware" manner.  One may check or leave empty the COM1 or COM2 boxes
  20. even though Kermit does directly modify the serial port.  Kermit will block
  21. (XOFF) if left running as an icon, but it will run smoothly while sharing the
  22. screen with other tasks.  Communications throughput is limited by Windows'
  23. character drawing speed.  Graphics are done as if you had a monochrome
  24. adapter.  Screen dumps ( ^] F or Control End) will be of Kermit's underlying
  25. full screen.  In summary, tell Windows that Kermit is exceptionally well
  26. behaved.
  27.  
  28. If you check the modifies memory box or some of the other boxes (or if you
  29. don't have a KERMIT.PIF file at all), then Kermit will take over the whole
  30. screen and Windows will become inactive, and Windows features will no longer
  31. work.  But Kermit will run much faster, and graphics will work normally.
  32.  
  33. ------------------------------
  34.  
  35. Date: Thu, 13 Apr 1989 23:00:26 EDT
  36. From: "Joe R. Doupnik" <jrd@watsun.cc.columbia.edu>
  37. Subject: MS Kermit and MS Windows
  38.  
  39. I just ran MS Kermit 2.32/A and the prerelease of Kermit 3.0 under Windows
  40. 2.03 and the 386 rendition of 2.03, both with no problems. I made Kermit a
  41. client talking to a remote server and launched a large file GET. Then I
  42. brought up various Windows programs such as Clock, PIFedit, Write, etc and
  43. played about. The transfer proceeded as smoothly as Windows permits (I could
  44. watch the Server's screen). Baud rate was 9600 and the throughput under
  45. regular 2.03 was around 7000 and under 386 about 2800 (more games being done
  46. and the Windows scheduler is different, 8800 with sliding windows and less
  47. mucking about).
  48.  
  49. The PIF files had these boxes checked:
  50.  
  51. Regular Windows 2.03: Memory req'd 150KB, desired 150KB
  52.         Program switch  Text
  53.         Screen switch    Text
  54.         Close window on exit
  55.         (No COM boxes checked, pretend v. good behavior)
  56.  
  57. Windows/386:    Memory req'd 150KB, desired 150KB
  58.         Screen mode Full Screen   Background  (also ok as just Backgnd)
  59.         Close window on exit
  60.  
  61.  
  62. I pushed poor Kermit into the background, plopped other windows on it, resized
  63. its window, and generally behaved obnoxously. The only time Kermit stopped was
  64. when it was forced to become an icon under regular Windows; that is normal for
  65. regular Windows. I checked the Full Screen box in 386 mode to see what happens:
  66. nothing untoward at all. Windows is a little awkward in that situation because
  67. the user has to type ALT-ESCape to regain attention of the master control
  68. program and hence invoke other tasks. Kermit ran ok even when it did not have
  69. the "input focus" (ownership of keyboard and cursor) or was invisible.
  70.  
  71. If a second program grabs the serial port then naturally Kermit will halt.
  72. Interpreted BASIC and older MS Compiled BASIC programs do such grabbing, and
  73. forget to return interrupts. Some "integrated" systems programs also have
  74. communications options which might grab the serial port. If the user has a bus
  75. mouse then all bets are off because of the well known major problems related to
  76. their high interrupt rates. If the second program has mouse support and that
  77. code attempts to find a serial mouse by probing the serial ports then the baud
  78. rate could be upset.
  79.  
  80. If people have problems running MS-Kermit under Windows, find out what
  81. "second" programs they were running, the kind of MS Windows, kind of mouse
  82. (serial, bus, mfr).  And of course watch out for Terminate-and-Stay-Resident
  83. programs that might be interfering with Kermit's interrupts, and for the old
  84. Basic programs that let the serial port interrupt point to never-never land.
  85.  
  86. End of File MSVIBM.PIF
  87.