home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / next / advocacy / 3538 < prev    next >
Encoding:
Text File  |  1993-01-03  |  3.0 KB  |  62 lines
  1. Newsgroups: comp.sys.next.advocacy
  2. Path: sparky!uunet!microsoft!hexnut!edwardj
  3. From: edwardj@microsoft.com (Edward Jung)
  4. Subject: Re: Weight of NT OS-level "objects"?
  5. Message-ID: <1993Jan04.002835.1342@microsoft.com>
  6. Date: 04 Jan 93 00:28:35 GMT
  7. Organization: Strategy Division, Microsoft Corp.
  8. References: <1992Dec31.234458.6859@fnbc.com>
  9. Keywords: NT,Smalltalk,Windows,Microsoft,Object Oriented
  10. Lines: 50
  11.  
  12. In the newsgroup comp.sys.next.advocacy <1992Dec31.234458.6859@fnbc.com> you wri
  13. te:
  14. >Will OO languages shipped for NT be able to base objects on NT objects, or
  15. >will objects in a running app exist in a whole different name space?  I
  16.  
  17. NT objects are all kernel objects, so they are generally not used
  18. by user-level processes (which generally don't need -- and for safety
  19. and security should not have -- the ability to define kernel objects)
  20. The NT object manager can be extended to handle more object types
  21. (although there are many limitations to this), but it is not expected
  22. that this is the way developers get OO support. Even subsystems (i.e.
  23. Win32, Win16, OS/2, POSIX) do not define new NT kernel objects since
  24. they are user-level code (similar to Mach 3.0's architecture, but
  25. not NeXT's, which uses a variation of an earlier Mach). NT objects
  26. are very low overhead (hey, they're in the kernel!), and in many
  27. ways are thus also low functionality (they do not, for example,
  28. transparently distribute across networks).
  29.  
  30. In some sense, microkernel architectures are not the way to TRULY
  31. support objects from "top to bottom". In fact, virtually all of
  32. today's chip architectures don't support objects efficiently. Any
  33. object system running on a modern kernel of traditional design
  34. such as Mach, NT, OS/2, etc. is generally layered on top of
  35. traditional kernel services which are in turn on top of traditional
  36. chip architectures. There exist research object-oriented systems
  37. (like Choices) that are "ground-up" OO, and a number of failed
  38. chip architectures that support OO better. Many IBM chip
  39. architectures are better at supporting objects than others;
  40. these are not found in workstations or personal computers.
  41.  
  42. Microsoft defined a basic object model and released it in a
  43. set of interfaces called "Object Linking and Embedding" (OLE).
  44. This object model is primative and only contains the minimal
  45. definition required to enable linking and embedding functionality.
  46. The next version (widely available in beta) also includes
  47. storage and external programmability functionality. A future
  48. systems product will extend this model for transparent 
  49. distribution and "plug and play" protocols, and base the entire
  50. suite of OS services on this model.
  51.  
  52. A point of fact that is lost on many people is that OLE is
  53. the object model that has the widest use today by applications.
  54. It is neither a class library nor a language-dependent model
  55. (although there are class libraries that "make it easier"
  56. shipped by various other parties). And, I'll admit, it has
  57. an ugly API and no interesting tools. But we're working on it ;-\
  58.  
  59. --
  60. Edward Jung, Software Architect     edwardj@microsoft.com
  61. Advanced Systems, Microsoft Corp.
  62.