home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / mswindo / programm / win32 / 3127 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  2.9 KB
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!hal.com!olivea!charnel!sifon!newsflash.concordia.ca!nstn.ns.ca!cs.dal.ca!iisat!mkseast!dale
  2. From: dale@mkseast.uucp (Dale Gass)
  3. Newsgroups: comp.os.ms-windows.programmer.win32
  4. Subject: NT Subsystems...
  5. Message-ID: <1993Jan26.211925.8015@mkseast.uucp>
  6. Date: 26 Jan 93 21:19:25 GMT
  7. Organization: Mortice Kern Systems, Atlantic Canada Branch
  8. Lines: 48
  9.  
  10. Just got "Inside Windows NT", and am starting to understand the NT design
  11. a bit better...  I do have some concerns, though...
  12.  
  13. I can see the elegance in having every user process be a client of a
  14. subsystem, which is implemented in terms of NT kernel level calls.
  15. However, these NT kernel level calls are apparently not accessible
  16. from user level applications, only from the subsystems.  If the subsystem
  17. decides to provide an API to grant access to the functionality provided
  18. by the kernel level API's, fine.  If it doesn't, there's no way you can
  19. achieve that functionality within the subsystem.
  20.  
  21. This strikes me as a serious disadvantage to this design approach.
  22. I am at the mercy of Microsoft's subsystem implementations in determining
  23. the functionality I can get out of NT.  They don't provide any full-screen
  24. control from the Posix subsystem, so all my Posix applications are doomed
  25. to be pathetic interactively...  This wouldn't be so bad if there were some
  26. way for the developer to work around it, but there doesn't appear to be
  27. any way to do so, short of re-implementing the subsystem from scratch.
  28.  
  29. Also, I have seen no evidence of a "Subsystem Developers Toolkit", which
  30. would allow me to write my own subsystem to meet my all of my needs.
  31. I guess these kernel level calls are the undocumented ones which Microsoft
  32. doesn't document, because they are "subject to change"...
  33.  
  34. What I would *love* to see would be either the availability of subsystem
  35. source code (not likely) so a developer could extend it (which would
  36. require all my customers to have the new subsystem, ugh!), or even better,
  37. add some hook for developers to *extend* the API's available from a
  38. subsystem.
  39.  
  40. With the latter approach, for example, I could implement a full curses
  41. by adding the appropriate API's, written in terms of the kernel level
  42. API's.  This "subsystem extension" (most likely a DLL) could allow adding
  43. any functionality to any subsystem, in whatever manner is most appropriate
  44. to the developer.
  45.  
  46. Without many of the common extensions found on Posix compliant system
  47. (such as curses, terminfo, etc.), the Posix subsystem is more or less 
  48. useless.  It may meet the U.S. government FIPS, but no applications of any 
  49. complexity could be made to work under it, so it will not be a Posix system 
  50. of choice.  I don't necessarily expect Microsoft to provide these extensions
  51. themselves, but I do expect them to make it possible for me to provide them, 
  52. if I wish.  Currently, they don't.
  53.  
  54. -dale
  55. -- 
  56.  Dale Gass, Mortice Kern Systems, Atlantic Canada Branch
  57. Business: dale@east.mks.com, Pleasure: dale@mkseast.uucp
  58.