home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v7 / text0039.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  2.9 KB
  1. From: cbosgd!cbosgd.ATT.COM!mark@seismo.css.gov (Mark Horton)
  2. Date: Thu, 9 Oct 86 01:30:59 edt
  3. Organization: AT&T Bell Laboratories, Columbus
  4.  
  5. I've made significant use of four different sorts of systems
  6. for multiplexing, so hopefully I can provide some feedback on
  7. their relative merits, from a user's point of view.
  8.  
  9. (1) True windows, such as a 5620, Sun, UNIX PC, etc.  Each window
  10. acts like a terminal.  This is unquestionably the best, but it
  11. requires special hardware, and is an area that needs to be
  12. standardized.
  13.  
  14. (2) A dumb-terminal window manager as Henry describes.  I've written
  15. such a window manager; on a system that has ptys, select, and a smart
  16. curses package, it's easy (my code is only 700 lines.)  It runs on both
  17. 4.2BSD and System V, provided that all three ingredients are present.
  18. This package runs about as well as you could hope for, (the buffering
  19. and ioctl problems Henry mentions are solved using ptys, and it doesn't
  20. eat up much CPU time, and all my windows are the full 80 cols wide)
  21. and I have a 60 line terminal so there's really room for two or three
  22. windows.  I use this rarely, because I dont' like the "mushy" feeling I
  23. get from the screen management layer.
  24.  
  25. (3) Berkeley job control.  Henry may think this is ugly, but from a user's
  26. point of view, if you can't have a real bitmapped display, this is the
  27. next best thing.  I strongly prefer it to (2).
  28.  
  29. (4) System V shell layers.  I don't use this very often, it's just not
  30. very powerful and awfully inconvenient.  It can't pop you out from any
  31. program that runs in raw mode, such as cu or rlogin, because there's
  32. no way for a program to suspend itself.  rlogin really NEEDS to suspend
  33. output in a non-window environment, otherwise your screen will be a mess.
  34.  
  35. I should mention that my major use of multiplexing is to switch between
  36. rlogins to various other systems on our LAN, and a few local applications
  37. such as vi, mail, and news.  For situations where I really need two windows
  38. (e.g. developing a network client and server) I strongly prefer to do it
  39. on a true window system.  It is possible that others, running other mixes
  40. of applications, will feel differently.
  41.  
  42. My recommendation is, however, similar to Henry's, for the standard.
  43. I don't think the dumb terminal window manager is the answer, but I
  44. think it's clear we don't have the best answer yet, in general.  I do
  45. think that certain things should be standardized:
  46.  
  47. (a) termio, or at least the subset that's commonly used.  You could always
  48.     put in a few high level subroutines like the cbreak/nocbreak echo/noecho
  49.     erasechar/killchar/baudrate routines in curses, just to provide a
  50.     portable interface.
  51. (b) an ioctl to find out the current window size, in chars and pixels.
  52. (c) a pty-like mechanism.  (Streams may be a viable candidate here, or
  53.     Illinois/Berkeley ptys might be expedient.)
  54. (d) a software-multiplexing mechanism, like select.
  55.  
  56.     Mark
  57.  
  58. Volume-Number: Volume 7, Number 40
  59.  
  60.