home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / arch / 11905 < prev    next >
Encoding:
Text File  |  1992-12-23  |  6.2 KB  |  163 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!menudo.uh.edu!sugar!ficc!peter
  3. From: peter@ferranti.com (peter da silva)
  4. Subject: Re: <None> (Should be Open Systems, bloody NEWS system...)
  5. Message-ID: <id.CG2W.R8A@ferranti.com>
  6. Organization: Xenix Support, FICC
  7. References: <1992Dec22.011414.21727@ryn.mro4.dec.com> <id.CD1W.3Q2@ferranti.com> <1992Dec23.050719.4047@ryn.mro4.dec.com>
  8. Date: Wed, 23 Dec 1992 16:11:29 GMT
  9. Lines: 152
  10.  
  11. In article <1992Dec23.050719.4047@ryn.mro4.dec.com> Peter.Mayne@cao.mts.dec.com writes:
  12. > But a model isn't an API.
  13.  
  14. Before the phrase "application program interface" became chic, the most
  15. commonly used phrase for it was "programming model".
  16.  
  17. > Encouragement of clean extensions is what caused the BSD/SVR4/others problems
  18. > in the first place. That's why I asked which UNIX API?
  19.  
  20. If you want to be literal, the comon subset of BSD and System V... basically
  21. Version 7 with a few extensions (the socket interface is pretty universal).
  22.  
  23. > >> Asynchronous I/O.
  24. > >> Waiting for multiple synchronisation objects.
  25.  
  26. > >I've proposed a general asynchronous *interface* for system calls, that would
  27. > >allow both of these. There is no conflict with the UNIX API that would require
  28. > >abandoning it.
  29.  
  30. > But you said the UNIX API,
  31.  
  32. That's right. The UNIX programming model. The point is that the UNIX API is
  33. very high level, and can be modified to provide any capability I've ever
  34. heard of without breaking it. There is NO excuse for any new operating
  35. system after about 1984 or 85 to use anything lower level. It increases the
  36. cost of software design, increases the cost of education and training, and
  37. decreases the amount of commonly available high quality software.
  38.  
  39. There is nothing in Windows, Windows NT, or OS/2 that requires a basic
  40. system interface other than UNIX-style I/O. The only reason for even
  41. considering anything else for a conventional operating system is simple
  42. cynical marketing decisions.
  43.  
  44. > Your general asynchronous interface sounds interesting. Tell us more in
  45. > another thread?
  46.  
  47. I need to write up a FAQ on it, OK.
  48.  
  49. > >> ACLs on objects.
  50.  
  51. > >Andrew has this, without abandoning the UNIX programming model.
  52.  
  53. > I presume you mean the Andrew file system. But we're talking about operating
  54. > systems, not file systems.
  55.  
  56. But the UNIX operating system interface is centered on the file system.
  57.  
  58. > >> Quotas.
  59.  
  60. > >I've seen both hierarchy and user quotas.
  61.  
  62. > What are hierarchy quotas?
  63.  
  64. > BTW, I'm not talking about file system quotas, I mean operating system quotas.
  65.  
  66. You mean like ulimit?
  67.  
  68. > >> >Why did Microsoft have to create
  69. > >> >a completely new API from scratch, and implement it in such a way that
  70. > >> >programs using it are entirely insulated from their UNIX API environment
  71. > >> >(POSIX shell)?
  72.  
  73. > >> Which new API?
  74.  
  75. > >Win32.
  76.  
  77. [and Win16, for that matter]
  78.  
  79. > Because:
  80. > (1) POSIX 1003.1 does not address the many areas that Win32 does.
  81.  
  82. Where it doesn't it can be trivially extended to do so.
  83.  
  84. > (2) POSIX 1003.1 is not a UNIX API.
  85.  
  86. Yes it is.
  87.  
  88. > (3) Win32 is actually based on the Win16 API (and therefore isn't written
  89. > from scratch), because it makes Win16 programs easier to port, and Microsoft,
  90. > being a nasty commercial company, recognised that that makes it easier
  91. > to get new software onto NT (cf porting from Win16 to OS/2).
  92.  
  93. And the Win16 API is equally broken, with no redeeming features, and no
  94. excuse for not being UNIX-based.
  95.  
  96. > >> POSIX 1003.1, which is a standard and therefore hardly new?
  97.  
  98. > >That's not the native API, nor the one Microsoft is using for primary NT
  99. > >software development. And you can't make Windows calls from a program
  100. > >running under the POSIX shell.
  101.  
  102. > Assuming you mean the POSIX 1003.1 API, because there is no POSIX 1003.2
  103. > shellin NT, neither should you be able to, because then it wouldn't be a
  104. > POSIX 1003.1 compliant program.
  105.  
  106. So what? It's a non-1003.1 compliant program. You're saying that the
  107. operating system vendor should make it impossible for a program using the
  108. 1003.1 interface to use any non 1003.1 calls? That's insane.
  109.  
  110. Of course Microsoft may simply be putting the 1003.1 support in purely as
  111. a marketing tool, without any intention of making it in any way useful.
  112. That would explain it.
  113.  
  114. > >(shell, in this case, is apparently Microsoft's term for an emulation
  115. > > environment... it's not the command line interpreter)
  116.  
  117. > Microsoft have not implemented a POSIX shell (1003.2), they have
  118. > implemented a POSIX API (1003.1).
  119.  
  120. What I have read on NT has implied that Microsoft is using the terms "shell"
  121. and "subsystem" interchangably. If that's not the case, s/shell/subsystem/g.
  122.  
  123. > >But is the object manager mapped into a filestore name space? If not, what
  124. > >was meant by that original remark, do you think?
  125.  
  126. > Actually, the filestore name space is mapped into the object name space, which
  127. > seems to be a much more sensible arrangement to me.
  128.  
  129. So, can I access any arbitrary object that a POSIX program might want to use
  130. via the filestore name space? If not, that's awfully short-sighted of
  131. Microsoft, because that's the way UNIX is progressing.
  132.  
  133. Of course Microsoft may simply be putting the 1003.1 support in purely as
  134. a marketing tool, without any intention of making it in any way useful.
  135.  
  136. > >> >Since OS/2 and NT have virtually the same level of backwards-compatibility
  137. > >> >with DOS, how do you make out that the OS/2 approach is any way diferent?
  138.  
  139. > >> NT uses the protected subsystem approach made popular by Mach. OS/2 provides
  140. > >> a DOS API, but the NT kernel knows nothing about DOS, since DOS (and OS/2, and
  141. > >> POSIX, and...) APIs are provided by the subsystems.
  142.  
  143. > >How does this affect the quality of the emulation:
  144.  
  145. > Emulation of what?
  146.  
  147. DOS. The original message I was responding to said that Windows had better
  148.  
  149. > >that is (getting back to
  150. > >the original comment), why would you have to buy "all new software" under
  151. > >OS/2 but not under NT?
  152.  
  153. > Dunno, OS/2 runs DOS/Windows programs as well or better than
  154. > DOS/Windows, or so IBM keeps telling us. But I'm not answering that
  155. > question, I'm answering yours.
  156.  
  157. No, you're answering a different but related question.
  158. -- 
  159. Peter da Silva                                            `-_-'
  160. Ferranti International Controls Corporation                'U` 
  161. Sugar Land, TX  77487-5012 USA
  162. +1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"
  163.