Making builtin OLE32 work right
mh at codeweavers.com
Sat Feb 19 08:15:58 CST 2005
Here is a brain dump of what I already know we need to fix for the CW
1) InstallShield: RPC call re-entrancy
2) Lotus Notes: OLE drag/drop leaves an image of the window behind
when it closes. Native does this functionality very
differently to us.
3) VB apps: As Holly Bostick discovered to her cost, we can't
load all OLEPicture resources correctly. Our OLEFont
code also has misc bugs in, but we don't have any
tests and code which uses these objects is rare so
the full extent of the work here is an unknown
4) OLE Storage: IIRC misc things break in Office when this is pulled
5) Office embedding: We need marshallers for IOleObject for this, I think ...
possibly a lot more. I do not know the details.
6) iTunes/iPod: Not fully investigated yet but I think we need to
drop the typelib marshaller hack (this stands a
good chance of breaking InstallShield for a short
time as well)
And one thing we probably don't care about:
7) Microsoft Transaction Server needs the typelib marshaller to generate
RPC marshal-ops (format strings) instead of using custom marshalling
like we do right now. But who cares about MTS while InstallShield and
Office still aren't there? :)
On Sat, 19 Feb 2005 10:58:27 +0900, Mike McCormack wrote:
> Hi All,
> I'd like to compile a list of all applications that don't work correctly
> without native ole32 (aka dcom95), then go through and try fix them.
> I think bugzilla is probably the right place to save the list, and that
> alot of the information we're looking for is already in the appdb.
> How can we extract if easily? Maybe the appdb guys can provide a check
> box that app maintainers can click on to indicate that builtin ole32
> works fine?
> any ideas?
More information about the wine-devel