home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / c / 18644 < prev    next >
Encoding:
Text File  |  1992-12-21  |  3.0 KB  |  66 lines
  1. Newsgroups: comp.lang.c
  2. Path: sparky!uunet!mcsun!news.funet.fi!hydra!klaava!wirzeniu
  3. From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
  4. Subject: Re: Peek/Poke in C
  5. Message-ID: <1992Dec18.193320.20790@klaava.Helsinki.FI>
  6. Organization: University of Helsinki
  7. References: <pal.724673747@regent.e-technik.tu-muenchen.de> <BzGIDn.Ho4@news.cso.uiuc.edu> <mcdonald.621@aries.scs.uiuc.edu>
  8. Date: Fri, 18 Dec 1992 19:33:20 GMT
  9. Lines: 55
  10.  
  11. mcdonald@aries.scs.uiuc.edu (J. D. McDonald) writes:
  12. >AND FOLKS, PLEASE, don't go blathering about "portability". It makes you
  13. >look silly. If the address of something on you computer is 13556, that's 
  14. >what it is, and you have no choice about using it.
  15.  
  16. True, if you have to access memory location 13556, then you have to
  17. access memory location 13556.  The question is, do you have to access
  18. memory location 13556?  ;-)
  19.  
  20. It is my experience that many programmers in the wonderful (or not so
  21. wonderful) realm of DOS answer this question far too quickly with an
  22. "Of course!".  In practice, what they are after is either utilizing
  23. some machine specific peculiarity (such as getting a random number by
  24. reading from the counter updated by the timer interrupt), or
  25. "efficiency".  I put that in quotes, because what they mean by
  26. efficiency usually means just writing directly to the screen,
  27. especially in programs where that portion of the program is not a
  28. bottlneck, like in a program that counts words in files (the program
  29. will spend several minutes in reading files, then the answer has to be
  30. poked directly to the screen memory in order to save a millisecond or
  31. two).
  32.  
  33. The fact that the services that MS-DOS provides are inadequate, and in
  34. the old days way too slow (the hardware is fast enough now that e.g.
  35. using DOS for writing things to the screen is quite fast enough in
  36. almost all cases), has lead to the DOS Programmer Syndrome.  People
  37. suffering from this disease make the assumption that any program that
  38. does anything useful has to access the hardware directly and bypass
  39. the operating system.  The earliest sign is usually that they want to
  40. write their own library for writing things directly to the screen
  41. memory.
  42.  
  43. I'm not saying that all cases of accessing the hardware are wrong,
  44. just that it is way too common a practice, and often not even the best
  45. answer.
  46.  
  47. Also, the same syndrome probably affects programmers using other tools
  48. as well, but it seems to be worst among DOS programmers.
  49.  
  50. >The answer is "if you can do it at all in C, you cast the address to
  51. >a pointer of the proper sort and access that pointer ...
  52.  
  53. The cast might not work, but the implementation might still provide a
  54. way to do it (e.g. via a library routine, or an extension to the
  55. language, such as a new operator), so I think that the correct answer
  56. is "please check your friendly manual; if that doesn't work, try using
  57. a cast".
  58.  
  59. >But remember, you purists out there, this likely **IS** kernal code.
  60.  
  61. Only as far as any program running under DOS is kernal code.
  62.  
  63. --
  64. Lars.Wirzenius@helsinki.fi  (finger wirzeniu@klaava.helsinki.fi)
  65.    MS-DOS, you can't live with it, you can live without it.
  66.