With everything OLE already does, it can, of course, always do more. As I mentioned earlier, an evolutionary technology such as OLE keeps changing. When I wrote the first edition of this book during the first half of 1993, OLE 2 had just been released, and many of the technologies we've seen, such as Connectable Objects, Property Pages, and OLE Controls, did not yet exist. In 1994, Microsoft made a number of improvements to OLE Automation, implementing dual interfaces, for example, and also added the capabilities for OLE Controls. Incremental enhancements of this nature will continue well into the future.
For the short term (the next two years or so), I can offer a brief list of the enhancements that you can expect. Of course, I cannot guarantee the timing of any of this—these are simply the features that Microsoft considers a priority:
These items are only those enhancements that Microsoft will make to the technologies we've already seen. Microsoft is also working on new systems technologies that will push OLE into even more areas than it exists in today.
One of the first places you will see (or have already seen) this expansion is the shell extensions to Windows 95, which are all based on COM objects of some sort that implement specific interfaces. For example, a Windows 95 "file viewer" is a simple COM object (with a CLSID and a server) that implements interfaces such as IPersistFile and IFileViewer. Other types of objects provide for extensions to object context menus, hooks for copy and move operations for directories and files, control over system icons, and custom extensions to object property sheets.
The way Windows 95 employs simple COM objects illustrates how useful such objects can be. Eventually you'll even see device drivers take advantage of COM's benefits for negotiating features through interfaces. Most device drivers today are simply DLLs that export specific functions—you can achieve the same end in COM with an in-process object for which all those functions are factored into meaningful interfaces. Over time, enhancements to device drivers will mean new interfaces to implement alongside existing interfaces. The ability to do this robustly is a tremendous improvement over current device driver models because most drivers have to be updated whenever a new version of the operating system is released. With an interface model, driver updates could happen incrementally.
Microsoft is also creating a specification for working with databases through OLE technologies, intended to augment and work with the Open Database Connectivity (ODBC) standard (which will, of course, continue to be fully supported). You can expect to see interfaces that can be used for purposes such as connecting to and managing databases, creating database schema, handling transactioning models, generating and executing queries, working with rows and columns (sorting, filtering, notifying), and so on.
Developers are working as well to create OLE-based multimedia technology for dealing with special content types and other needs unique to multimedia. And work is also going on related to accessibility, or providing ways for computers to work better with people who have various disabilities.
Of course, Microsoft cannot do everything by itself, and many areas of technology concern only a certain segment of the computer industry. For example, the WOSA/XRT specification we saw in Chapter 10 was the work of the Open Market Data Council, which involved representatives of more than 80 companies. Microsoft played only a supporting role in that effort, helping to guide the design to make appropriate use of OLE. But such a gathering of different companies with a common interest doesn't need Microsoft at all! Because COM already allows anyone to create his or her own custom interfaces with standard or custom marshaling, any group of people can get together, find solutions to their common problems, define interfaces to implement those solutions, and then use those interfaces to have their applications communicate and integrate with one another.
Indeed, a key design goal of OLE was the capability for any programmer to create, extend, or evolve an existing design without central coordination of his or her activity while still maintaining a true guarantee of robustness in the system. (In particular, the widespread use of GUIDs as a fundamental data type ensures that no two pieces of code will work together unless programmers intend that they do so.) What's important is that no changes to OLE or to the operating system are necessary. This means that no one needs to approach Microsoft and coerce them to add new APIs to the system or dedicate any other sort of resources. OLE empowers individuals in a partnership to create new designs for integration and interoperability. No one company dominates such a relationship because everyone involved is working for the common interest: integrating applications and components to solve customer problems.
For the longer term, it's hard to know what new additions and changes Microsoft will make and what sorts of technologies other groups might create themselves. There are so many interesting and exciting directions to pursue! In any case, Microsoft doesn't want to work in a vacuum, so they do welcome your ideas and requests. Let Microsoft know what your priorities are and what new features you would like to see. You can send electronic mail to oleidea@microsoft.com, or you can write a letter or send a fax to the attention of OLE Program Management. If you are involved in a third-party initiative and would like Microsoft's involvement in the effort, contact Microsoft through the OLESOLN forum on CompuServe or by e-mail at i-stds@microsoft.com.