readme.now

增强的pterm01b.zip 终端仿真程序(63KB)<END>

   =======================

      I know, I know... Luckily, there are not many configurable options
      (yet) in PTERM, so this won't take much longer.

      Currently, I have PTERM read its configuration from the environment.
      The following environment variables are supported:


         PTPORT

            Set to the integer value of the port you wish PTERM to use. I
            have tested ports 1 and 2, but PTERM should be able to use any
            port available (please let me know if you have problems in this
            area). Example:

               set PTPORT=1


         PTWORD

            Set to the integer value of the data word size to open the port
            with. Typically 7 or 8 data bits. Example:

               set PTWORD=8


         PTPARITY

            Set to the parity to open the port with. Supported values are:

               NONE
               EVEN
               ODD

            Example:

               set PTPARITY=NONE


         PTSTOP

            Number of stop bits to open the port with. Typically 1 or 2.
            Example:

               set PTSTOP=1


         PTBAUD

            Set to the baud rate to open the port at. Supported speeds are
            300, 1200, 2400, 4800, 9600, 19200, 38400, 57600, and 115200.
            PTERM locks the baud rate of the port at the speed given, as is
            necessary with most modern modems.

            Example:

               set PTBAUD=38400


         PTDOWN

            Set to the path where downloaded files are to be placed.
            Example:

               set PTDOWN=e:\download

            If this path does not exist, the download will likely be
            aborted, so if you have problems like that, be sure this
            path is correct!


         PTAUTOZ

            If this variable is set to ANYTHING, auto Zmodem downloads and
            uploads will be enabled. To disable, make sure it is not in
            defined in the environment. Example(s):

               set PTAUTOZ=yes            Enables auto Zmodem
               set PTAUTOZ=               Disables auto Zmodem


      There you have it. Those are the available options for configuring
      PTERM.

      There is virtually no error checking done on configuration, so make
      sure you (as in your brain) go into debug mode if you have problems.

      Included in the archive with this document and PTERM.EXE, you should
      find a batch file called PT.CMD. This is the recommended method of
      starting PTERM.

      Place PT.CMD and PTERM.EXE in your path. Edit PT.CMD to set the
      environment variables appropriate to your system. To run PTERM, type
      PT from a command prompt. The batch file will set the environment
      variables, and start PTERM in its own console window. You can easily
      create multiple batch files to run multiple copies of PTERM each on a
      different port. This has worked for me with 2 ports simultaneously.
      The batch file approach has worked from NT's CMD.EXE as well as the
      4DOS for NT command interpreter replacement.

      PTERM can be placed in (and executed from) the program manager, and
      even has its own embedded icon (just like a real Windows program!).
      To insure that the environment is set up correctly, start the control
      panel 'System' applet, and at the bottom use the two edit boxes to
      appropriately define the variables described above. You will have to
      log off and and back on for these to take effect, and will need to
      set them for each user account.

      When using a batch enabled file transfer protocol (Zmodem), the file
      selection dialog box which pops up for an upload will allow you to
      select multiple files from any one directory, using the standard
      Windows mouse/key combinations for multi-select lists (i.e. CTRL-CLICK
      adds a file to the list, and try SHIFT-CLICK to extend the list to the
      current point).

      For batch uploading, if PTERM finds a file called FILESTO.UPL in the
      current directory (the directory you were in when you started PTERM),
      it expects this file to contain a list of files (full paths) to
      upload, and will attempt to do so. If PTERM finds this file, it will
      go straight to uploading, bypassing the file selection dialog.

      I am sure I have forgotten a whole bunch of information here, but
      this should be enough to get you off the ground.


   Can I Run it Now?
   =================

      Well... Ok...

      But, "Don't touch it, you'll break it..." (U.S. West T.V. ad)

      When you run PTERM, it will splat some information on the screen.
      First it will display the key bindings it recognizes, things like
      ALT-X to exit, PGDN to download, etc. Next, it displays the current
      settings as read in from the environment. Pressing F1 will display
      this information at anytime during the session.

      As mentioned, there is no dialer. This is too bad, I know, and will
      be one of the first things added.

      For those of you who have been spoiled all their lives by a dialer and
      do not know how to do it manually, if you have a modem which supports
      the Hayes command set (are there any which don't?) you can dial a
      number from PTERM like so:

         atdt555-5555               Tone dial 555-5555
         atdp555-5555               Pulse dial 555-5555 (yuck!)

      On my USR Sportster, the command

         a/

      executes the last command entered, and can be used to redial.


   Some Closing Thoughts
   =====================

      Its not much, but there it is. Please let me know of any problems or
      suggestions for enhancements you have.

      On my 386-33, running the March '93 beta, I have experienced excellent
      transfer speeds using the Zmodem in PTERM. On text files, at 14.4K
      with .v42bis (57.6K maximum), I have seen 3800+ cps. The same setup on
      compressed files yields 1650 cps and higher. If you have 16550's, and
      access to a FIFO enabled serial driver (I rebuilt it using the March
      DDK), install it! The serial driver for NT is absolutely solid, and
      extremely efficient. Before installing the FIFO enabled serial driver,
      during a 1650 cps download I would experience around 1700 interrupts
      per second (approx. one for each character), and during heavy
      multi-tasking characters were easily dropped.

      However, after rebuilding the serial driver (the 16550 support is in
      there, just not enabled -- The April update (and final retail build
      when it arrives) adds the ability to enable the FIFO's through the
      registry), with the same 1650 cps download I was getting around 200
      interrupts per second. This makes sense since I built the serial
      driver to enable the FIFO's to fire off an interrupt when they queued
      8 bytes, for an 8x decrease in interrupts. Subsequently, I have never
      seen PTERM drop a character in over 20 megs of file transfers.

      Another facet of the serial driver which operates well is RTS/CTS
      flow control. This is always turned on when PTERM runs, later it will
      be configurable. During heavy multi-tasking, RTS/CTS keeps the modem
      under control, holding it off when the serial buffer gets full. This
      has worked flawlessly.

      In closing, Windows NT has its problems, but all in all it is a
      solid, high performance operating system for the masses. I am
      confident in Microsofts (and mostly Dave Cutlers) ability to evolve
      NT, so much more is yet to come (MS: thanks sooo much for the console
      API, making all those UNIX utils that much easier to port!).

      Ron Cox
      Paragon Consulting Group


   Technically Speaking
   ====================

      Thought you were done, didn't you? Well, if you could care less about
      some of the technical details of PTERM, you are, else read on.

      As mentioned, PTERM makes full use of multi-threading. This stuff is a
      trip. It can make programming much more interesting (and in many cases
      greatly simplifies things!).

      There are 6 threads of execution, 5 secondary and the 1 main thread
      which all Win32 applications start with.

      The first two threads of interest are in Williams communications
      library. One is responsible for taking characters in from the serial
      port (actually, the serial driver) and placing them in a queue created
      by the library (the input queue) which is made visible to the user
      code. The second takes characters from another queue and writes them
      to the serial port (driver). The user code is responsible for placing
      characters to be sent out the port into this output queue, and does so
      through a set of 'Send' member functions.