windows-xp/Source/XPSP1/NT/com/ole32/ole232/doc/preraid.txt

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.