home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / linux / 23127 < prev    next >
Encoding:
Text File  |  1993-01-07  |  2.4 KB  |  50 lines

  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!haven.umd.edu!wam.umd.edu!joel
  3. From: joel@wam.umd.edu (Joel M. Hoffman)
  4. Subject: Re: DOS emulation
  5. Message-ID: <1993Jan7.224043.23029@wam.umd.edu>
  6. Sender: usenet@wam.umd.edu (USENET News system)
  7. Nntp-Posting-Host: rac2.wam.umd.edu
  8. Organization: University of Maryland, College Park
  9. References: <79132@hydra.gatech.EDU> <1993Jan5.174435.3669@wam.umd.edu> <1993Jan7.184329.8050@bernina.ethz.ch>
  10. Date: Thu, 7 Jan 1993 22:40:43 GMT
  11. Lines: 37
  12.  
  13. In article <1993Jan7.184329.8050@bernina.ethz.ch> almesber@nessie.cs.id.ethz.ch (Werner Almesberger) writes:
  14. >In article <1993Jan5.174435.3669@wam.umd.edu> joel@wam.umd.edu (Joel M. Hoffman) writes:
  15. >> I see two possibilities:  One, giving the DOS program full control of
  16. >> the screen, for SVGA graphics.  The program could do whatever it
  17. >> wanted, and so the VC code would have to be augmented to save/restore
  18. >> the complete state of the video card.  This would be a good thing,
  19. >[...]
  20. >> The only problem with this approach is that I don't think
  21. >> graphics programs could run in the background.
  22. >
  23. >If you mean "detaching from a display", why not ? It's not necessarily
  24. >different from switching a VC. VCs aren't things that really exist in
  25. >hardware either.
  26. >
  27. >If you mean "switching to a different VC", why not ? The display memory
  28. >could be mapped to the physical frame buffer while the respective VC is
  29. >in the "foreground" which is copied to a buffer in user space when
  30. >switching to a different VC. Now, that buffer memory could be mapped to
  31. >the display memory and the DOS program could happily continue to
  32. >scribble to what it thinks is its screen. It would even run faster ;-)
  33. >
  34.  
  35. It's not that simple, becuase of the registers.  Currently, each VC
  36. emulates a video buffer, which means that as long as a process is only
  37. writing to the text part of a video card, everything is fine.  X, on
  38. the other hand, does lots of complex things with the card, and so
  39. doesn't like the (current) VC scheme.  To really get things running,
  40. so that DOS processes that like to use the entire video card (not to
  41. mention X) can run either in the background or on a non-selected VC
  42. (which, as you mention, is basically the same thing), the VC code
  43. would have to emulate the entire video card, not just the text buffer.
  44.  
  45. I think that's a good goal to shoot for, for lots of reasons.  But I
  46. certainly don't know enough even to begin.
  47.  
  48. -Joel
  49. (joel@wam.umd.edu)
  50.