This possibility exists in any program, not only those using a shared library, but a problem can become very difficult to track down if it exists in someone else's code. In SOM, the only solution is extensive testing of new versions of libraries, which is not always easy. While SOM and COM were contrapositioned by IBM, they were not mutually exclusive. In 1995 Novell contributed ComponentGlue technology to OpenDoc for Windows. This technology provided different means to integrate between COM- and SOM-based components. In particular, SOM objects can be made available to OLE2 applications by either late binding bridge (based on IDispatch) or COM interfaces having higher performance. In essence, SOM classes are implementing COM interfaces this way. The flexibility offered by SOM was considered worth the trouble by almost all , but similar systems, such as Sun Microsystems' Distributed Objects Everywhere, also supported full inheritance. NeXT's Portable Distributed Objects avoided these issues via a strong versioning system, allowing library authors to ship new versions along with the old, thereby guaranteeing backward compatibility for the small cost of disk space. See also Component Object Model GObject Objective-C XPCOM Windows Runtime References External links IBM SOMobjects Developer's Toolkit Version 3.0 for Windows NT, OS/2 Warp, and AIX Documentation System Object Model SOM Object-oriented programming System Object Model