On Sat, Dec 04, 2004 at 01:38:59PM -0500, Vincent Béron wrote:
stdole32-generator.c file from Huw. Invocation from wineprefixcreate from me.
Changelog:
Automatically create c:\windows\system\stdole32.tlb.
Vincent
The native version of stdole32.tlb is actually a resource only dll that contains the typelib itself as TYPELIB resource #1. I think we probably want to do likewise.
Huw.
Le lun 06/12/2004 à 07:03, Huw D M Davies a écrit :
On Sat, Dec 04, 2004 at 01:38:59PM -0500, Vincent Béron wrote:
stdole32-generator.c file from Huw. Invocation from wineprefixcreate from me.
Changelog:
Automatically create c:\windows\system\stdole32.tlb.
Vincent
The native version of stdole32.tlb is actually a resource only dll that contains the typelib itself as TYPELIB resource #1. I think we probably want to do likewise.
I guess the easiest way (if we keep a winelib app) is to use {Begin,End,}UpdateResource{A,W} from kernel32.dll? Great, some more motivation to finish what I started to implement a couple months ago :)
Vincent
Vincent Béron vberon@mecano.gme.usherb.ca writes:
I guess the easiest way (if we keep a winelib app) is to use {Begin,End,}UpdateResource{A,W} from kernel32.dll?
Not really, it should probably be created by winebuild like other builtin dlls, or else directly in PE format by widl. Either way it won't be done from a Winelib app (but don't let this discourage you from finishing the UpdateResource support ;-)
On Tue, 07 Dec 2004 17:17:12 +0100, Alexandre Julliard wrote:
Not really, it should probably be created by winebuild like other builtin dlls, or else directly in PE format by widl. Either way it won't be done from a Winelib app (but don't let this discourage you from finishing the UpdateResource support ;-)
Hmm, so the approach with a custom app generating stdole32.tlb is not OK? As far as I'm aware this is what Microsoft do, I thought there were constructs in this file that midl/widl could not generate.
Mike Hearn mh@codeweavers.com writes:
Hmm, so the approach with a custom app generating stdole32.tlb is not OK?
No, we can't run a Winelib app during the build process, and stdole32.tlb really has to be built like everything else at compile time.
On Wed, Dec 08, 2004 at 12:02:28PM +0100, Alexandre Julliard wrote:
Mike Hearn mh@codeweavers.com writes:
Hmm, so the approach with a custom app generating stdole32.tlb is not OK?
No, we can't run a Winelib app during the build process, and stdole32.tlb really has to be built like everything else at compile time.
The reason I wrote a program was that I was unable to get midl to generate the correct typelib from stdole32.idl - it really didn't like producing IUnknown iirc. Of course, it may be that I was just being dumb, and that it's perfectly possible to do this. If not I guess we can always lift this restriction on widl.
Huw.
Huw D M Davies wrote:
On Wed, Dec 08, 2004 at 12:02:28PM +0100, Alexandre Julliard wrote:
Mike Hearn mh@codeweavers.com writes:
Hmm, so the approach with a custom app generating stdole32.tlb is not OK?
No, we can't run a Winelib app during the build process, and stdole32.tlb really has to be built like everything else at compile time.
The reason I wrote a program was that I was unable to get midl to generate the correct typelib from stdole32.idl - it really didn't like producing IUnknown iirc. Of course, it may be that I was just being dumb, and that it's perfectly possible to do this. If not I guess we can always lift this restriction on widl.
MIDL cannot generate correct stdole* typelibs because it forces the inclusion of objidl.idl. You have to use mktyplib. As you say, we can lift this restriction from widl. Here is a file that, when used with mktyplib, generates a pretty similar file to stdole32.tlb (similar as in generates the same output from typelib viewers, but isn't the same at the byte level): http://www.winehq.org/hypermail/wine-devel/2003/01/att-0858/01-stdole32.odl
Rob