home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / os2 / advocacy / 10931 < prev    next >
Encoding:
Internet Message Format  |  1992-12-25  |  3.8 KB
  1. Xref: sparky comp.os.os2.advocacy:10931 comp.os.ms-windows.advocacy:3423
  2. Newsgroups: comp.os.os2.advocacy,comp.os.ms-windows.advocacy
  3. Path: sparky!uunet!mcsun!sun4nl!dutrun!donau!dutecaj.et.tudelft.nl!linstee
  4. From: linstee@dutecaj.et.tudelft.nl (Erik van Linstee)
  5. Subject: Re: FCC will proclaim Microsoft is run by Communists! : )
  6. Message-ID: <1992Dec25.181732.15997@donau.et.tudelft.nl>
  7. Sender: news@donau.et.tudelft.nl (UseNet News System)
  8. Nntp-Posting-Host: dutecaj.et.tudelft.nl
  9. Organization: Delft University of Technology, Dept. of Electrical Engineering
  10. References: <1992Dec24.203801.7799@donau.et.tudelft.nl> <1992Dec24.222133.10992@tc.cornell.edu> <1992Dec25.102400.13417@donau.et.tudelft.nl> <1992Dec25.163338.29576@tc.cornell.edu>
  11. Date: Fri, 25 Dec 1992 18:17:32 GMT
  12. Lines: 64
  13.  
  14. bai@msiadmin.cit.cornell.edu (Dov Bai-MSI Visitor) writes:
  15.  
  16. >In article <1992Dec25.102400.13417@donau.et.tudelft.nl> linstee@dutecaj.et.tudelft.nl (Erik van Linstee) writes:
  17.  
  18. >>Well, I don't know anything about your FTC, and I don't quite get
  19. >>what it has to do with software needing to know about systems
  20. >>internals.
  21. >>All I am saying is that software engineers needn't worry about
  22. >>system internals. Only time critical software needs to grab an
  23. >>interrupt and as regular software goes this would only be a
  24. >>comm. package. And even then the designer needn't know about
  25. >>the internals, because he can use a library that installs an
  26. >>interrupt handler. Of course he can prefer to do it himself, as
  27. >>I often do, but that is only because I choose not to use anything
  28. >>I don't have total control over. this is of course only feasible
  29. >>if you design a piece of software by yourself.
  30. >>Summary: application designers need not worry about system internals,
  31. >>thats what the systems the designers are for.
  32.  
  33. >Does not the DOS programmer need to know about segment:offset 
  34. >addressing, what memory model to use, and when ? Can one program
  35. >effectively on DOS without that knowledge ?
  36.  
  37. No, one need not know about segment:offset. Why do you think they
  38. should?
  39. Yes, one needs to know what memory model to use when programming
  40. in C, but only to optimise results. That is a feature C provides.
  41. Programming in Pascal does not involve memory models. Anyway,
  42. choosing the memory model is no programming decision, proper
  43. code is not affected by memory model.
  44. No, one can not program effectively for DOS period.
  45.  
  46. >How about the differences between 286/386 ?
  47.  
  48. Well, what about them?
  49.  
  50. >How about the 640k limit and how to overcome it ? Need not the 
  51. >programmer know about extended/expanded memory, DPMI/VCPI interfaces ?
  52.  
  53. The 640k limit is of no concern. When you write an app. and you
  54. need memory, you request it and check if you got it. You do not
  55. consider if maybe the target system has a specific limit, you
  56. just check for any limit to be reached. Either way you have to
  57. alwayys consider a system running out of memory. On a 32M system
  58. do you consider a memory limit? What if only 640k is still available?
  59. Does that affect your programming? I think not.
  60. No, a programmer needn't know about DPMI/VCPI interfaces. If he
  61. wants memory, he requests it, he does not generally care where it
  62. comes from. The DPMI/VCPI interface should be hidden from him,
  63. unless of course he is writing his own memory management, but
  64. I can't think of a reason why an application should need that.
  65.  
  66. >I have in front of me the second edition (1992) of the book
  67. >"Extending DOS - A Programmer's Guide to Protected Mode DOS" by
  68. >Ray Duncan. The first introductory chapter include detailed description 
  69. >of selectors, descriptors etc. 
  70.  
  71. Protected mode DOS, where can you buy that? Oh wait, it says
  72. Extending DOS. So it isn't part of DOS? Then it can't be of
  73. a DOS app. programmers concern, can it? Looks like systems programming
  74. to me, but I could be wrong.
  75.  
  76.  
  77. Erik van Linstee   |   Delft University of Technology   |   I'll be back ... 
  78.