home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / mswindo / programm / win32 / 3120 < prev    next >
Encoding:
Text File  |  1993-01-28  |  4.4 KB  |  96 lines
  1. Newsgroups: comp.os.ms-windows.programmer.win32
  2. Path: sparky!uunet!europa.eng.gtefsd.com!emory!swrinde!sdd.hp.com!saimiri.primate.wisc.edu!usenet.coe.montana.edu!decwrl!pa.dec.com!rdg.dec.com!news.crl.dec.com!dbased.nuo.dec.com!nntpd.lkg.dec.com!ryn.mro4.dec.com!news
  3. From: pjdm@chmeee.enet.dec.com (Peter Mayne)
  4. Subject: Re: NT Subsystems...
  5. Message-ID: <1993Jan28.044605.18806@ryn.mro4.dec.com>
  6. Lines: 83
  7. Sender: news@ryn.mro4.dec.com (USENET News System)
  8. Reply-To: Peter.Mayne@cao.mts.dec.com
  9. Organization: Digital Equipment Corporation
  10. References:  <1993Jan26.211925.8015@mkseast.uucp>
  11. Date: Thu, 28 Jan 1993 04:46:05 GMT
  12.  
  13.  
  14. In article <1993Jan26.211925.8015@mkseast.uucp>, dale@mkseast.uucp (Dale Gass) writes:
  15. >I can see the elegance in having every user process be a client of a
  16. >subsystem, which is implemented in terms of NT kernel level calls.
  17. >However, these NT kernel level calls are apparently not accessible
  18. >from user level applications, only from the subsystems.  If the subsystem
  19. >decides to provide an API to grant access to the functionality provided
  20. >by the kernel level API's, fine.  If it doesn't, there's no way you can
  21. >achieve that functionality within the subsystem.
  22.  
  23. That's the idea.
  24.  
  25. >This strikes me as a serious disadvantage to this design approach.
  26. >I am at the mercy of Microsoft's subsystem implementations in determining
  27. >the functionality I can get out of NT.  They don't provide any full-screen
  28. >control from the Posix subsystem, so all my Posix applications are doomed
  29. >to be pathetic interactively...  This wouldn't be so bad if there were some
  30. >way for the developer to work around it, but there doesn't appear to be
  31. >any way to do so, short of re-implementing the subsystem from scratch.
  32.  
  33. If POSIX doesn't specify full-screen control (or any other feature that you
  34. want), then MS are wasting time and money by (a) deciding what to add in, and
  35. (b) adding it in. If they do put it in, or you work around it, then it isn't
  36. POSIX.
  37.  
  38. >Also, I have seen no evidence of a "Subsystem Developers Toolkit", which
  39. >would allow me to write my own subsystem to meet my all of my needs.
  40. >I guess these kernel level calls are the undocumented ones which Microsoft
  41. >doesn't document, because they are "subject to change"...
  42. >
  43. >What I would *love* to see would be either the availability of subsystem
  44. >source code (not likely) so a developer could extend it (which would
  45. >require all my customers to have the new subsystem, ugh!), or even better,
  46. >add some hook for developers to *extend* the API's available from a
  47. >subsystem.
  48.  
  49. It was exactly the availability of these "features" that caused UNIX to
  50. become the dog's breakfast of various API's that it became. Please don't
  51. let NT go the same way.
  52.  
  53. >With the latter approach, for example, I could implement a full curses
  54. >by adding the appropriate API's, written in terms of the kernel level
  55. >API's.  This "subsystem extension" (most likely a DLL) could allow adding
  56. >any functionality to any subsystem, in whatever manner is most appropriate
  57. >to the developer.
  58.  
  59. It is certain that this wouldn't work, since the kernel has no
  60. knowledge of the POSIX environment. The only thing that knows the POSIX
  61. environment and defines the POSIX semantics is the POSIX subsystem, not
  62. the kernel.
  63.  
  64. >Without many of the common extensions found on Posix compliant system
  65. >(such as curses, terminfo, etc.), the Posix subsystem is more or less 
  66. >useless.  It may meet the U.S. government FIPS, but no applications of any 
  67. >complexity could be made to work under it, so it will not be a Posix system 
  68. >of choice.
  69.  
  70. Any POSIX compliant program, no matter how complex, should work in the
  71. POSIX subsystem. If FIPS only allows mickey mouse (tm) programs, it's hardly
  72. Microsoft's fault.
  73.  
  74. If POSIX isn't "complex" enough for you, use Win32. Besides, I don't
  75. really think that people are going to buy NT as a POSIX system of
  76. choice, are they? :-)
  77.  
  78. >I don't necessarily expect Microsoft to provide these extensions
  79. >themselves, but I do expect them to make it possible for me to provide them, 
  80. >if I wish.  Currently, they don't.
  81.  
  82. See above. I expect them to make it impossible to provide such
  83. extensions. And I hope it stays that way.
  84.  
  85. >-dale
  86. >-- 
  87. > Dale Gass, Mortice Kern Systems, Atlantic Canada Branch
  88. >Business: dale@east.mks.com, Pleasure: dale@mkseast.uucp
  89.  
  90. PJDM
  91. --
  92. Peter Mayne                     | My statements, not Digital's.
  93. Digital Equipment Corporation   |
  94. Canberra, ACT, Australia        | "AXP!": Bill the Cat
  95.  
  96.