home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / linux / 22772 < prev    next >
Encoding:
Internet Message Format  |  1993-01-05  |  3.1 KB
  1. Path: sparky!uunet!munnari.oz.au!spool.mu.edu!caen!destroyer!gatech!prism!gt8134b
  2. From: gt8134b@prism.gatech.EDU (Howlin' Bob)
  3. Newsgroups: comp.os.linux
  4. Subject: DOS emulation
  5. Message-ID: <79132@hydra.gatech.EDU>
  6. Date: 5 Jan 93 15:01:19 GMT
  7. Organization: Georgia Institute of Technology
  8. Lines: 57
  9.  
  10. wolff@liberator.et.tudelft.nl (Rogier Wolff) writes:
  11. >Now I don't agree with this. the windows API has in the HUNDREDS of calls.
  12. >Also given that hardware is slightly logical because making exceptions
  13. >and so forth in silicon is very expensive.
  14.  
  15. Well, try it in software.  I promise you, it doesn't look cheap from
  16. that side either.
  17.  
  18. >This is what is wrong with the current DOS emulator. It starts by emulating
  19. >the MSDOS API. You should start by emulating the hardware, and after you
  20.  
  21. It doesn't really emulate the MS-DOS "API,"  as it were.  The DOS emulator
  22. emulates the BIOS, and a very few int 21h calls that are necessary for
  23. the "network redirector" (linux.exe) and good performance.  IBM thought
  24. enough ahead to make a slight buffer between software and hardware: the
  25. BIOS.  A lot of software calls the BIOS (for disk access, a lot of video
  26. stuff, etc.)   MS-DOS itself calls the BIOS.  It is absolutely necessary 
  27. to have some BIOS emulation.  Furthermore, the whole point of the BIOS is
  28. hardware independence; the PC builder writes a BIOS to take advantage of
  29. whatever features, quirks, and slight incompatibilities his machine might
  30. have.  Running under Linux is a major feature of the DOS emulator.  Matthias
  31. wrote the BIOS with such in mind. :-)
  32.  
  33. It would be idiotic to rely totally on hardware emulation and then run the
  34. machine's native (ROM) BIOS under that.  The overhead would be tremendous.
  35. If I can write a pseudo-BIOS trap for all int 10h (video) calls that
  36. handles most calls with a very few lines of C (say, a few variable
  37. assignments, input/output, etc), whyever would I want to do otherwise.
  38. The entire int 10h section in my emulator is under 200 lines (I think)
  39. and is sufficient for most programs.  (of course, direct screen writes
  40. are also handled with a special feature of vm86 mode).
  41.  
  42. >are able to run MSDOS using that, you can start optimizing performance
  43. >and functionality by trapping some MSDOS calls that you know are often
  44. >used and are best emulated. The basic hardware that  MSDOS needs is:
  45. >Keyboard/timers/video/floppy (harddisk).
  46.  
  47. Almost no programs directly hit the harddisk/floppydisk.  But I agree
  48. with the others, and am working on it.
  49.  
  50. >At first video emulation need only be at 80x25 textmode. In the end it
  51. >shouldn't be too hard to detect "going into graphics", and emulate that
  52. >too. It might become a little slow, but it should at least work....
  53.  
  54. That becomes difficult.  I plan on getting around to it, but it's not the
  55. most urgent thing right now.  I would be most pleased if you implemented
  56. such a thing, however.  Please mail me any suggestions/diffs you have.
  57.  
  58. Robert Sanders
  59. gt8134b@prism.gatech.edu
  60.  
  61.  
  62. -- 
  63. Robert Sanders
  64. Georgia Institute of Technology, Atlanta Georgia, 30332
  65. uucp:      ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt8134b
  66. Internet: gt8134b@prism.gatech.edu
  67.