home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / arch / 11877 < prev    next >
Encoding:
Text File  |  1992-12-22  |  3.2 KB  |  82 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!psinntp!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.CD1W.3Q2@ferranti.com>
  6. Organization: Xenix Support, FICC
  7. References: <BzGL07.2wK@dscomsa.desy.de> <id.2K0W.G37@ferranti.com> <1992Dec22.011414.21727@ryn.mro4.dec.com>
  8. Date: Tue, 22 Dec 1992 15:31:03 GMT
  9. Lines: 71
  10.  
  11. In article <id.2K0W.G37@ferranti.com>, peter@ferranti.com (peter da silva) writes:
  12. > You seem to have a strong opinion about this, so could you explain to me
  13. > precisely how the UNIX API is lacking, and what specific features of NT
  14. > would be impossible under a UNIX API.
  15.  
  16. In article <1992Dec22.011414.21727@ryn.mro4.dec.com> Peter.Mayne@cao.mts.dec.com writes:
  17. > Which UNIX API? (Here we go again. :-)
  18.  
  19. The basic UNIX model of resources as objects in the file name space, the basic
  20. UNIX system calls, and so on. Clean extensions are, as they have always been,
  21. encouraged.
  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. > ACLs on objects.
  31.  
  32. Andrew has this, without abandoning the UNIX programming model.
  33.  
  34. > Quotas.
  35.  
  36. I've seen both hierarchy and user quotas.
  37.  
  38. > >Why did Microsoft have to create
  39. > >a completely new API from scratch, and implement it in such a way that
  40. > >programs using it are entirely insulated from their UNIX API environment
  41. > >(POSIX shell)?
  42.  
  43. > Which new API?
  44.  
  45. Win32.
  46.  
  47. > POSIX 1003.1, which is a standard and therefore hardly new?
  48.  
  49. That's not the native API, nor the one Microsoft is using for primary NT
  50. software development. And you can't make Windows calls from a program
  51. running under the POSIX shell.
  52.  
  53. (shell, in this case, is apparently Microsoft's term for an emulation
  54.  environment... it's not the command line interpreter)
  55.  
  56. > >Well for UNIX, where access to virtually all system resources is provided
  57. > >through the filestore, I would agree. But NT has half a dozen different
  58. > >mechanisms for interacting with the system... how can multiuser security
  59. > >be managed if it only protects a minor part of the system?
  60.  
  61. > All interactions with the NT kernel go through the object manager, and hence
  62. > through the security subsystem.
  63.  
  64. But is the object manager mapped into a filestore name space? If not, what
  65. was meant by that original remark, do you think?
  66.  
  67. > >Since OS/2 and NT have virtually the same level of backwards-compatibility
  68. > >with DOS, how do you make out that the OS/2 approach is any way diferent?
  69.  
  70. > NT uses the protected subsystem approach made popular by Mach. OS/2 provides
  71. > a DOS API, but the NT kernel knows nothing about DOS, since DOS (and OS/2, and
  72. > POSIX, and...) APIs are provided by the subsystems.
  73.  
  74. How does this affect the quality of the emulation: that is (getting back to
  75. the original comment), why would you have to buy "all new software" under
  76. OS/2 but not under NT?
  77. -- 
  78. Peter da Silva                                            `-_-'
  79. Ferranti International Controls Corporation                'U` 
  80. Sugar Land, TX  77487-5012 USA
  81. +1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"
  82.