home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / os / linux / 10744 < prev    next >
Encoding:
Text File  |  1992-09-15  |  2.5 KB  |  69 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!mcsun!fuug!mits!kennu
  3. From: kennu@mits.mdata.fi (Kenneth Falck)
  4. Subject: Re: Can you access a virtual console directly?
  5. Message-ID: <1992Sep15.164930.11353@mits.mdata.fi>
  6. Organization: Microdata Oy, Helsinki, Finland
  7. References: <1992Sep14.164729.28907@mits.mdata.fi> <1992Sep14.220800.12868@klaava.Helsinki.FI>
  8. Date: Tue, 15 Sep 1992 16:49:30 GMT
  9. Lines: 58
  10.  
  11. In article <1992Sep14.220800.12868@klaava.Helsinki.FI> wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) writes:
  12.  
  13. >kennu@mits.mdata.fi (Kenneth Falck) writes:
  14. >>It feels a bit dumb to use termcap-codes to handle the local output, if
  15. >>you know you'll be using this terminal from the virtual consoles only. 
  16.  
  17. >[stuff deleted...]
  18. >[ Does anybody else get tired of MS-DOS programmers whose first (and
  19. >often enough only) thought is: ``How do I write directly to video
  20. >memory?'' Perhaps we'll see requests for adding TSR support into Linux
  21. >next. Urgh. ]
  22.  
  23. You know, that might be one of the reasons MSDOS has made it so big;
  24. your applications can have very powerful output when you don't have
  25. to hassle with some control codes that really belong to the externally
  26. connected terminals, not to the console screen. Of course the price is
  27. the lack of multitasking, except with these 80386 memory-redirections
  28. (of which I know very little)...
  29.  
  30. How about if the kernel had some special services that would make it
  31. easy and portable (within Linuces) to use the virtual consoles without
  32. termcap? I mean something like this:
  33.  
  34. int main (void)
  35. {
  36.  int curvt;
  37.  int cols, rows;
  38.  unsigned char *vtbuf;
  39.  
  40.  cols = vt_get_columns ();
  41.  rows = vt_get_rows ();
  42.  curvt = vt_get_current ();
  43.  vtbuf = vt_get_address (curvt);
  44.  vtbuf [0] = 'L'; vtbuf [1] = 0x07;
  45.  vtbuf [2] = 'i'; vtbuf [3] = 0x07;
  46.  vtbuf [4] = 'n'; vtbuf [5] = 0x07;
  47.  vtbuf [6] = 'u'; vtbuf [7] = 0x07;
  48.  vtbuf [8] = 'x'; vtbuf [9] = 0x07;
  49.  vt_update_buffers (curvt);
  50.  return 0;
  51. }
  52.  
  53. (That code isn't probably the most effective way to do it
  54. but I just wanted to propose my idea briefly...)
  55.  
  56. Does this seem like a stupid idea (coming from an MSDOS
  57. programmer like me...) or would it bring some more power
  58. into the Linux-applications? I think it's a fact that
  59. 386 is a personal computer, and many people would like
  60. to use Linux as a multitasking OS only, and have no need
  61. to run programs remotely. Of course, if something like this
  62. is implemented, there is the potential danger of all programs
  63. becoming menu-driven and unrunnable from remote connections,
  64. and then someone has to write PC-Anywhere for Linux :-)
  65.  
  66. -- 
  67. kennu@mits.mdata.fi
  68.  
  69.