home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / mswindo / misc / 2402 < prev    next >
Encoding:
Text File  |  1992-08-26  |  2.3 KB  |  48 lines
  1. Newsgroups: comp.os.ms-windows.misc
  2. Path: sparky!uunet!sun-barr!ames!pacbell.com!att!cbfsb!cbnewsg.cb.att.com!ashaw
  3. From: ashaw@cbnewsg.cb.att.com (andrew.shaw)
  4. Subject: Re: Windows == OS
  5. Message-ID: <1992Aug26.194050.10608@cbfsb.cb.att.com>
  6. Sender: news@cbfsb.cb.att.com
  7. Organization: AT&T
  8. References: <714807912.1@ttlg.ttlg.UUCP>
  9. Date: Wed, 26 Aug 1992 19:40:50 GMT
  10. Lines: 36
  11.  
  12. From article <714807912.1@ttlg.ttlg.UUCP>, by Monroe.Thomas@ttlg.UUCP (Monroe Thomas):
  13. > I agree 100% with you...  the GUI *should* be a separate entity from
  14. > the OS.  Windows, up until 3.x has certainly inter-related OS and
  15. > GUI...
  16. > 
  17. > *However*, can we make assumptions about the types of terminals
  18. > attached to our OS?  Unix doesn't.  I think what is falling out is
  19. > that there should be hooks in the OS to make GUI apps easier to
  20. > produce.  After all, perhaps one of the resources that often gets
  21. > neglected in the definition of an OS is the graphical monitor.
  22. > Screenspace deserves to be managed too, IMNSHO.  The question is, can
  23. > the OS provide general enough screen managemnt tools so that the GUI
  24. > flavour remains unaffected???  I dunno.
  25. > 
  26.  
  27. I'm not sure that I like putting application-specific hooks in the OS.
  28. What I do like is the UNIX(R) solution of having the hardware come
  29. with drivers.  The drivers are supposed to conform to the published
  30. conventions and can use already existing kernel services (eg mask
  31. interrupts).  At installation time you parameterize the driver with
  32. the specifics of your hardware setup (I/O address, IRQ, etc) and
  33. then the driver is incorporated into the kernel.  So the old OS
  34. provides hooks in the form of read/write/ioctl system calls that
  35. are directed to the particular driver based on the device passed.
  36. The new OS (kernel) provides hooks in the form of the driver for
  37. the device, eg writing to /dev/ega should update the screen.  If
  38. you change to another card, just do the same thing, and then
  39. writing to /dev/vga should update the screen.  This way the apps
  40. do not need to know the specifics of the hardware: they can
  41. merely look to see if /dev/svga, /dev/vga, /dev/ega, /dev/cga,
  42. /dev/tty exist and open the desired one.  I realize that using
  43. graphics is a bad example here, since under X all of this
  44. would be taken care of by the X server, with yet another API,
  45. but...
  46.  
  47.  
  48.