home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / sysv386 / 16367 < prev    next >
Encoding:
Text File  |  1992-11-10  |  2.8 KB  |  58 lines
  1. Newsgroups: comp.unix.sysv386
  2. Path: sparky!uunet!ferkel.ucsb.edu!taco!gatech!darwin.sura.net!zaphod.mps.ohio-state.edu!cs.utexas.edu!sun-barr!ames!pacbell.com!att-out!cbnewsj!dwex
  3. From: dwex@cbnewsj.cb.att.com (david.e.wexelblat)
  4. Subject: X server & dynamic linking (was Re: Two Xfree86 questions)
  5. Organization: AT&T
  6. Date: Tue, 10 Nov 1992 17:20:38 GMT
  7. Message-ID: <1992Nov10.172038.484@cbnewsj.cb.att.com>
  8. References: <1992Nov02.234155.2179@sco.COM> <1992Nov4.175056.24918@cbnewsj.cb.att.com> <1992Nov06.173208.20900@sco.com>
  9. Lines: 47
  10.  
  11. In article <1992Nov06.173208.20900@sco.com> staceyc@sco.COM (Stacey Campbell) writes:
  12. > 
  13. > In article <1992Nov4.175056.24918@cbnewsj.cb.att.com> dwex@cbnewsj.cb.att.com (david.e.wexelblat) writes:
  14. > >I have heard that SCO's server works by dynamically loading the 
  15. > >appropriate driver(s) at run time.  Is that true?
  16. > 
  17. > It is.  We found that keeping the core server (/usr/bin/X11/Xsco), the
  18. > drawing engines for each class of video card (SVGA, XGA, 8514/A, S3, and
  19. > so on), and the board specific initialization code (/usr/lib/grafinfo/*/*)
  20. > independent of each other to be the most flexible way to support a bunch
  21. > of cards, get reasonable performance, make it real easy to write support
  22. > for a new card, and to enable us to move to X11R5 without (in theory)
  23. > touching a single line of our card specific drawing code.  This turned out
  24. > to be as difficult an engineering job as it sounds.  ;-)
  25. > 
  26.  
  27. I would think so.  Without a standard for the dix/ddx/os interfaces, MIT
  28. can go ahead and redefine those interfaces out from under you.  You
  29. would have to have your own sub-ddx API, then port ddx changes to match it.
  30.  
  31. > >If so (and you are allowed to tell :->), how does that work?  I thought
  32. > >that SVR3 didn't support dynamically loadable objects.
  33. > 
  34. > I'm pretty sure that the 20 pages of fine print I signed when I started
  35. > here included the line "...and you will not blab trickey source code
  36. > hacks to people on the net...", however, if you recall the old BSD rogue
  37. > game that would save itself by writing its core to a file then restore
  38. > the game by "unexecing" itself (Franz Lisp and older TeX versions also used
  39. > this trick), well we do something similar though in my opinion even
  40. > nastier.  So even though SVR3.2 doesn't come with dynamic loading it can
  41. > be added at the user program level.
  42.  
  43. Wow.  I'm impressed.  I hadn't thought about doing it that way (I am
  44. aware of unexec from Gnu Emacs).  I think we'll stick with link-time
  45. server configuration :->.  Of course, we have a rather different
  46. audience.
  47.  
  48. > -- 
  49. >           Stacey Campbell - staceyc@sco.com - uunet!sco!staceyc
  50.  
  51.  
  52. --
  53. David Wexelblat <dwex@mtgzfs3.att.com>  (908) 957-5871
  54. AT&T Bell Laboratories, 200 Laurel Ave - 4B-421, Middletown, NJ  07748
  55.  
  56. "The meaning of life?  That's simple.  Try to be happy, try not to hurt
  57.  other people, and hope to fall in love."  -- Mallory Keaton
  58.