[Implementation] URL moniker [Notes] 
The system implementation of URL monikers supports BindToStorage for stream objects on all URLs and for storage objects in the case where the designated resource is a compound file. Because the URL moniker supports asynchronous binding, the actual return value of its BindToStorage may vary depending on the object parameters established in the bind context. However, the semantics of the bind operation are identical regardless of synchronous or asynchronous usage, as follows: The URL moniker pulls further information for the bind operation from the bind context. For example, the moniker can obtain pointers to the IBindStatusCallback and IEnumFORMATETC interfaces that are registered in the bind context. Further information can include additional bind options specified on the bind context through IBindCtx::SetBindOptions, such as the dwTickCountDeadline parameter or the grfFlags value of BIND_MAYBOTHERUSER. The moniker then queries the client by calling IBindStatusCallback::GetBindInfo and initiates the bind operation with the transport and passes the resulting IBinding to the client by calling IBindStatusCallback::OnStartBinding. If the caller requested an asynchronous IStream or IStorage by specifying the BINDF_ASYNCSTORAGE flag in the BINDINFO structure retrieved from the IBindStatusCallback::GetBindInfo, method the URL moniker returns the object as soon as possible. Calls to these IStorage or IStream objects that reference data not yet available return E_PENDING. If the caller does not specify asynchronous IStream or IStorage as described above, the URL moniker will still return an object through the IBindStatusCallback::OnDataAvailable method as soon as possible. However, calls to these objects that reference data not yet available will block until the data becomes available. For some applications, this will require the least modification of their existing I/O code yet may still result in improved performance depending on their access patterns.