Content deleted Content added
→Background: clean up, typo(s) fixed: Nevertheless → Nevertheless, using AWB |
|||
Line 8:
Oddly, the differences between any two [[programming language]]s on a single platform was almost as great. Each language had its own format for passing parameters into [[procedure call]]s, the file formats that they generated were often quite different. In general terms, it was not always possible to write different portions of a program in different languages, although doing so often has real utility. The problem was not so acute on [[minicomputer]]s and mainframes where the vendor often specified standards for their libraries, but on microcomputers the programming systems were generally delivered by a variety of 3rd party companies with no interest in standardization.
Nevertheless, this problem was being addressed in the early 1990s through the introduction of various [[shared library]] systems. These were actually intended to ease resource use on smaller platforms, by allowing a number of programs using a common resource, like the GUI, to share a single copy of code instead of each loading a separate copy into memory. As a side effect of being able to be called from many programs, these systems also defined a standard way to call them, using an [[interface definition language]], or IDL, to allow any language on the platform to understand the code inside the library.
Extending these systems to support [[remote procedure call]]s behind the scenes was seen as a natural evolution, providing a solution to the client/server programming problem. At the time there were a number of major projects to deliver such a system, including [[IBM]]'s [[System Object Model]] (SOM/DSOM), [[NeXT]]'s [[Portable Distributed Objects]], [[Microsoft]]'s [[Component Object Model]] (COM/DCOM) and many [[CORBA]] flavors. Sun, attempting to position itself as the future IBM in terms of backoffice support, felt they had to attack this market as well.
| |||