LinkUser will create a file moniker with the hard-coded pathname C:\INOLE\CHAP09\LINKSRC\GOOP.LKS, so someone had better create that file. If you run LinkSource by itself, it will display a window with a File /Create GOOP.LKS menu item that does exactly this. If you are interested in the exact code, look at CApp::CreateSampleFile, CApp::CreateStore, and CApp::WriteDescription in LINKSRC.CPP. Besides being a demonstration of the use of Structured Storage, this procedure also creates a compound file with five first-level substorages named "Object m," under each of which are five more substorages named "Sub-Object n." Overall, the file will contain 26 distinct storage elements (including the root), and each will contain a description stream with some relevant text. You can easily modify the code to create more storage elements on either level if you want.
Obviously, this file is a contrived example that gives us some persistent data to which we can bind through monikers. A real-world application, of course, would use many different files, but typically those files will all have the same internal structure. The names might be more variable, and data might not be structured perfectly in isolated storage elements and streams, but you get the idea. The benefit of using a storage hierarchy in the manner that LinkSource does is that the item names in a long composite moniker are nothing more than the substorage names in the file. The Patron implementation we'll see later works in the same way. Of course, this is not efficient for all types of applications, for example a spreadsheet, which uses item names to identify sections of data within a particular stream.
The final note about the file is that LinkSource marks it with its own CLSID, specifically CLSID_LinkedFile, by calling IStorage::SetClass. This allows the file moniker to easily retrieve this CLSID and launch LinkSource to get at its file object. Let's see how that works.