preraid.txt This file contains general notes for the ole2w32.dll project. These items should all be entered into our raid database once that is established. 1. alexgo -- api.cpp contains a lot of seemingly redundant api's, such as OleNoteObjectVisible and OleSetContainedObject, which do nothing but call CoLockObjectExternal. We ought to think about replacing these with #define's. 2. alexgo -- there are *16* api's in api.cpp which all do basically the same thing, reading and writing private OLE info into a special stream in a storage. There is a lot of duplicate code between these functions; with a little bit of thought, we can clean this up significantly. Some of these (such as GetDocumentBitStg) don't even seem to be used by anyone. 3. alexgo -- fix writing ANSI strings to streams to write an ansi version to the 16bit named private stream (OLE_STREAM, COMPOBJ_STREAM) and write a duplicate unicode string to a 32bit private stream. Be sure to maintain consistent state across the two stream/strings 4. alexgo -- fix autoconversion of links. We need to return a new error code OLE_E_CLASSDIFFMUSTRECREATELINK to handle the case of custom links and modify the sample code to deal with this appropriately. See the file autolink.txt for a more thorough discussion of this issue. 5. alexgo -- fix the drawing of icons and labels. The code (icon.cpp) currently assumes English language with an ANSI character set. 6. DONE: alexgo -- the OleReg functions (in olereg.cpp and elsewhere) need to be updated to the new 32bit standard. The following note from ShannonC gives more details. From: Shannon Chan To: Object Oriented Interfaces,Methods&API's Subject: FINAL: Registry conflicts between 16 bit OLE2 and 32 bit OLE2 Date: Friday, December 03, 1993 11:19AM Last month, I sent out a proposal on how to resolve the registry conflicts between 16 bit OLE 2 and 32 bit OLE 2. There were no objections. This message describes the final resolution of this issue. Conflicting registry entries currently prevent the installation of 16 bit OLE 2 and 32 bit OLE 2 applications on the same machine. The 16 bit applications require 16 bit DLLs. The 32 bit applications require 32 bit DLLs. The problem is that the same registry entries are used to register both 16 bit DLLs and 32 bit DLLs. The solution to this problem is to define new registry entries for 32 bit OLE 2. 16 bit OLE 2 will continue to use the existing registry keys: InProcServer - Registers a 16 bit in-process server DLL. InProcHandler - Registers a 16 bit handler DLL. ProxyStubClsid - Maps an IID to a CLSID in a 16 bit proxy DLL. 32 bit OLE 2 will use new registry keys: InProcServer32 - Registers a 32 bit in-process server DLL. InProcHandler32 - Registers a 32 bit handler DLL. ProxyStubClsid32 - Maps an IID to a CLSID in a 32 bit proxy DLL. Some people asked why we need ProxyStubClsid32. We need ProxyStubClsid32 because the IID to CLSID mapping may be different for 16 bit interfaces and 32 bit interfaces. The IID to CLSID mapping depends on how we package the interface proxies into a set of proxy DLLs. ShannonC 7. alexgo -- need to replace all memory allocations with the debug versions for resource tracking. See alext's mail. 8. DONE (partially) alexgo -- need to put in call tracing stuff (LEDebugOut). 9. alexgo -- optimization. The defhandler makes many many calls to IsRunning. We may be able to make IsRunning faster or perhaps analyze our code paths and reduce the number of calls to it. 10. alexgo -- the OleConvert api's in the ole1 directory need to be implemented (currently, they are just stubbed). 11. alexgo -- the test harness should ensure that structures (such as FORMATETC) are packed ala MS C style /Zp8 packing.