The following is a paid commercial announcement.
Hello, friends. Ole' Bob Data here. Are you cranky because the only way to describe data is by using a lousy little clipboard format? Are you irritable because the only way to exchange data is by using a crummy global-memory handle? Are you tired of waiting around while you try to copy a 30-MB, 24-bit, device-independent bitmap, listening to your disk chug like Grandma's old Hoover? Well, friends, I can end your misery forever. What I have here can end hard disk swapping that sounds like a Studebaker lug nut in a meat grinder! It's New and Improved Ultra-Structures, free with every purchase of OLE and free with every instance of a data object! No longer do you just say, "Bitmap"! No longer do you just say, "Metafile"! Be free! Be fresh! Send me your paycheck! Tell your data object not only that you want a bitmap but that you want it to be just a thumbnail sketch! Tell your data object not only that you want that metafile but that you want it created for a PostScript device! Tell your data object that you want every known translation of the Bible, Koran, Torah, I Ching, Bhagavad-Gita, and the collected thoughts of Mao Tse-tung, and not just as a lousy temperamental piece of global memory but in a compound file!!! The choice is yours! How much would you be willing to pay? Five API functions? Twenty API functions? A hundred new API functions? No! These are yours free with your qualified use of a data object! Available at a data object supplier near you.
Taxlicensinganddestinationchargesapplicablebutvoidwhereprohibitedanddoesnotincludedealerprep
markuportheoverheadofpayingforridiculousadvertisementslikethisorthetendollarsaminutewe
automaticallychargetoeverycreditcardinyournamejustforlisteningtous.
Now back to our scheduled programming.
Every version of Windows since version 1 back in 1985 has performed all data exchange (the clipboard and DDE) using a simple clipboard format and a global-memory handle. To copy data to the clipboard, you call SetClipboardData, passing a clipboard format and a global-memory handle. To paste, you call GetClipboardData with a clipboard format and get back a global-memory handle. DDE is restricted in the same fashion: WM_DDE_DATA messages carry with them only a global-memory handle containing the data and an item that describes what might be in that memory.
OLE 1 employed this same scheme for its data transfer needs and suffered accordingly. As happens with the clipboard and DDE, many copies of the same data generally sat in memory at any given moment. Small data were tolerable, but large 24-bit DIBs rapidly drained the system of free memory. Often a source would load a large block of data into memory from disk, and it promptly ended up back on the disk as virtual memory. The consumer would then load this data back from the disk through virtual memory, eventually writing it somewhere else on the disk. I think all of us have experienced a good 15 minutes' worth of serious grinding noises coming from a hard drive in these cases. OLE 1 merely exacerbated the problem because it did this for both a graphical presentation and a content object's native data, which was often just as large.
The OLE architects realized that this was an area for major improvement when they began designing OLE 2. In fact, Structured Storage grew out of the need to have an efficient shareable storage medium that different components could access incrementally. The architects were also set on adding OLE Drag and Drop and didn't want another protocol to suffer the same performance problems as the others.
Thus, it became necessary to extend the allowable mediums for data exchange beyond global memory and to expand the format definition beyond the clipboard format. At the same time, the designers needed to preserve compatibility with existing mechanisms, making the clipboard format and memory handle a subset of the new order of things. Enter two new structures, FORMATETC and STGMEDIUM.