home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / os / coherent / 5785 < prev    next >
Encoding:
Text File  |  1992-11-21  |  3.3 KB  |  73 lines
  1. Newsgroups: comp.os.coherent
  2. Subject: Re: Tcl to replacement most of /bin & /usr/bin (was: Tcl on Linux
  3. Path: sparky!uunet!think.com!unixland!rmkhome!rmk
  4. From: rmk@rmkhome.UUCP (Rick Kelly)
  5. Organization: The Man With Ten Cats
  6. Date: Sat, 21 Nov 1992 20:08:20 GMT
  7. Reply-To: rmk@rmkhome.UUCP (Rick Kelly)
  8. Message-ID: <9211211508.21@rmkhome.UUCP>
  9. References: <9211201646.AB00614@PCS.CNU.EDU> <9211202320.AA01986@PCS.CNU.EDU>
  10. Lines: 61
  11.  
  12. In article <9211202320.AA01986@PCS.CNU.EDU> "Coherent operating system" <COHERENT@indycms.bitnet> writes:
  13. >
  14. >    Building the graphics engine into the kernel doesn't require the
  15. >details of each card to be included any more than it does if the engine
  16. >is separate like X.  The only difference is that it is now a kernel
  17. >process that always gets the horsepower it needs.  I/O and system tasks
  18. >are atomic and run to completion (though disk I/O can be preempted for
  19. >obvious reasons...).  The basic UNIX scheduler is not designed to handle
  20. >something like a graphics server.  What I am talking about would still
  21. >use graphics drivers but would not run as a user process.
  22.  
  23. This is all well and good assuming that you want graphics, and that you
  24. want the kernel to have still more bloat.
  25.  
  26. It would defeat the purpose of a multitasking machine if the interface
  27. always overwhelmed other processes on the system.  Most UNIX systems
  28. come with a nice utility to control process scheduling.
  29.  
  30. >    If I'm not mistaken, the approach I'm talking about is being
  31. >used for PowerPC, some versions of Mach, the Apple Macintosh, and
  32. >Windows NT.  OS/2 2.0 has hooks in its OS for the graphics engine.  If
  33. >you design a kernel with the graphics system in mind its going to be
  34. >better.  The UNIX kernel was not so until it gets changed it won't run
  35. >graphics as well as it could.
  36.  
  37. The PowerPC is A/UX with Multifinder and a Mac emulation running on top.
  38.  
  39. Mach gives you the basic core of a kernel,  everything else must be
  40. provided by the OS emulation that rides on top of it.
  41.  
  42. The Mac is designed to give the GUI the highest priority.  It is also
  43. difficult to program for.
  44.  
  45. Windows NT is a large bloated mess with Windows 3.1 running on top as
  46. a user shell.
  47.  
  48. OS2/2.0 still requires loadable graphics drivers for SVGA support.
  49.  
  50. There seem to be an awful lot of satisfied users of graphics on UNIX
  51. boxes.
  52.  
  53. >    It occurs to me that you could still make X a user process if you
  54. >just had graphics primitives built in to the kernel.  That way you wouldn't
  55. >be stuck with X.  This would also make it work on differing architectures.
  56. >While my PC doesn't have a frame buffer mapped to memory like a Sparc or
  57. >something (or mapped to a /dev/ entry) it is possible.  GNU C maps the
  58. >graphics card buffer as a single 1 meg address space in upper memory
  59. >allowing you to access it just like a Mac or a UNIX box.  No more stupid
  60. >segment swapping.  This might help promote better motherboards too.  I'd
  61. >like to see a 386/486 class motherboard that was designed to be a good
  62. >motherboard and not a good DOS motherboard.  That might take awhile but
  63. >maybe DOS will die someday...
  64.  
  65.  
  66. You must be referring to GNU C as it was ported to MSDOS.  In it's other
  67. incarnations, it doesn't have specific graphics support.  On UNIX systems
  68. that is left up to the designers of the system library code.
  69.  
  70. -- 
  71.  
  72. Rick Kelly    rmk@rmkhome.UUCP    unixland!rmkhome!rmk    rmk@frog.UUCP
  73.