Hello, I have started implementing a small winelib-program that shall eventually add ActiveX support to the Konqueror web browser. For testing I'm using the Shockwave Flash OCX and experienced some problems due to unimplemented functions and features in winelib. First thing is typelib registration, which doesn't work yet as the debug output tells. Okay, did that manually. Then, for setting the control's properties, I tried the easy way via IDispatch::Invoke(), which calls ITypeInfo::Invoke() and that's only a stub :( I worked around this via evil assembler hacks to call the interface's members as given by the vtable offsets in the FUNCDESC using stdcall convention - unfortunately g++ doesn't support specifying a calling convention for method pointers like HRESULT (IDispatch::*setProp)(BSTR). After getting this to work, I hit the next problem: unimplemented urlmon.RegisterBindStatusCallback and when I use a native urlmon.dll it tries to call shlwapi.154, with native shlwapi it still doesn't work somehow, but that's a different story. Anyway, what I'd basically need to get this to work properly is - typelib registration - IDispatch::Invoke() - RegisterBindStatusCallback() and probably asyncronous bind contexts - probably a "real" URL Moniker, not just CreateURLMoniker() using a File Moniker What I'd like to know is if anyone is already working on any of these and if so what's the status and how I could help getting these implemented. if no one started yet, I'd still like to give it a try. Thanks, -Malte PS: the attached patch fixes urlmon.h not being C++-safe. -- Wars don't determine who's right, only who's left.
On Montag, 28. Mai 2001 22:19, Malte Starostik wrote:
Anyway, what I'd basically need to get this to work properly is - typelib registration As a start I gave RegisterTypeLib() a try. There are a few things I'm uncertain about, but for the typelibs I tried the resulting registry entries match the ones windows generates. -Malte -- Wars don't determine who's right, only who's left.
Hi Malte, We (Macadamian) were working on implementing oleaut32.dll, if you search the archives of WINE HQ around dec 2000 / jan 2001 you can see some of the patches that we submitted. Unfortunately, work has been shelved for the moment, but there is a starting point for you. For IDispatch::Invoke / ITypeInfo::Invoke, there is a patch at: http://www.integrita.com/cgi-local/lwgate.pl/WINE-PATCHES/archives/2000-12/d... As well please see discussion of patch at: http://www.integrita.com/cgi-local/lwgate.pl/WINE-DEVEL/archives/2001-01/dat... (with reasons why it wasn't committed, search for "invoke") As for your other issues:
- typelib registration
Requires adding some registry entries. Not too bad, pretty much any COM book will tell you all you need to do.
- IDispatch::Invoke() See above
- RegisterBindStatusCallback() and probably asyncronous bind contexts Hummm... no idea.
- probably a "real" URL Moniker, not just CreateURLMoniker() using a File Moniker
See the Brockschmidt book. Have fun. :-) Seriously, I don't think anyone has done any work on this one or is currently working on this besides the stubbed DLL that is in the tree. -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. james(a)macadamian.com ~ http://www.macadamian.com Funniest Definition found in a Japanese<->English Dictionary so far: Moose: Amerika Ushi (American Cow) (should be: mu-su in katakana)
On Mon, 28 May 2001, Malte Starostik wrote:
unfortunately g++ doesn't support specifying a calling convention for method pointers like HRESULT (IDispatch::*setProp)(BSTR).
Since when? The construct HRESULT CALLBACK (*stuff)(...) is used all over the Wine headers, so I'd think someone would have noticed if g++ didn't support it...
On Mittwoch, 30. Mai 2001 00:39, Ove Kaaven wrote:
On Mon, 28 May 2001, Malte Starostik wrote:
unfortunately g++ doesn't support specifying a calling convention for method pointers like HRESULT (IDispatch::*setProp)(BSTR).
Since when? The construct HRESULT CALLBACK (*stuff)(...) is used all over the Wine headers, so I'd think someone would have noticed if g++ didn't support it... HRESULT CALLBACK (*stuff)(...) works indeed. I only tried HRESULT CALLBACK (IFooBar::*stuff)(...) which yields: warning: `stdcall' attribute directive ignored and results in stack corruption then I ignore this warning. So it seems it accepts __attribute__ ((stdcall)) for function pointers but not method pointers :( -Malte -- Wars don't determine who's right, only who's left.
On Wed, 30 May 2001, Malte Starostik wrote:
On Mittwoch, 30. Mai 2001 00:39, Ove Kaaven wrote:
On Mon, 28 May 2001, Malte Starostik wrote:
unfortunately g++ doesn't support specifying a calling convention for method pointers like HRESULT (IDispatch::*setProp)(BSTR).
Since when? The construct HRESULT CALLBACK (*stuff)(...) is used all over the Wine headers, so I'd think someone would have noticed if g++ didn't support it... HRESULT CALLBACK (*stuff)(...) works indeed. I only tried HRESULT CALLBACK (IFooBar::*stuff)(...) which yields: warning: `stdcall' attribute directive ignored and results in stack corruption then I ignore this warning.
Can you explain why you do this, then? I can't imagine why you would want to declare a method pointer like this.
On Mittwoch, 30. Mai 2001 03:33, Ove Kaaven wrote:
On Wed, 30 May 2001, Malte Starostik wrote:
On Mittwoch, 30. Mai 2001 00:39, Ove Kaaven wrote:
On Mon, 28 May 2001, Malte Starostik wrote:
unfortunately g++ doesn't support specifying a calling convention for method pointers like HRESULT (IDispatch::*setProp)(BSTR).
Since when? The construct HRESULT CALLBACK (*stuff)(...) is used all over the Wine headers, so I'd think someone would have noticed if g++ didn't support it...
HRESULT CALLBACK (*stuff)(...) works indeed. I only tried HRESULT CALLBACK (IFooBar::*stuff)(...) which yields: warning: `stdcall' attribute directive ignored and results in stack corruption then I ignore this warning.
Can you explain why you do this, then? I can't imagine why you would want to declare a method pointer like this. Well, that was just the first thing that came to mind. Assembler was the second. I somehow didn't even think of a plain function pointer - well yes, I am more used to C++ than C :) Of course it's kinda hard to initialize a C++ method pointer from a vtable offset. Anyway, it should be implemented in winelib and not in my app, so it's not feasible after all. But that doesn't matter now that I realized a full implementation will probably need assembler as the number of arguments is virtually unlimited. So an array of parameters that is copied to the stack via inline assembler is IMHO the way to go. Will give it a try. -Malte -- Wars don't determine who's right, only who's left.
On Wed, May 30, 2001 at 04:32:19AM +0200, Malte Starostik wrote:
On Mittwoch, 30. Mai 2001 03:33, Ove Kaaven wrote:
On Wed, 30 May 2001, Malte Starostik wrote:
On Mittwoch, 30. Mai 2001 00:39, Ove Kaaven wrote:
On Mon, 28 May 2001, Malte Starostik wrote:
unfortunately g++ doesn't support specifying a calling convention for method pointers like HRESULT (IDispatch::*setProp)(BSTR).
Since when? The construct HRESULT CALLBACK (*stuff)(...) is used all over the Wine headers, so I'd think someone would have noticed if g++ didn't support it...
HRESULT CALLBACK (*stuff)(...) works indeed. I only tried HRESULT CALLBACK (IFooBar::*stuff)(...) which yields: warning: `stdcall' attribute directive ignored and results in stack corruption then I ignore this warning.
Can you explain why you do this, then? I can't imagine why you would want to declare a method pointer like this. Well, that was just the first thing that came to mind. Assembler was the second. I somehow didn't even think of a plain function pointer - well yes, I am more used to C++ than C :) Of course it's kinda hard to initialize a C++ method pointer from a vtable offset. Anyway, it should be implemented in winelib and not in my app, so it's not feasible after all. But that doesn't matter now that I realized a full implementation will probably need assembler as the number of arguments is virtually unlimited. So an array of parameters that is copied to the stack via inline assembler is IMHO the way to go. Will give it a try.
? Why can't you use the WINE supplied macros INTERFACE_FUNCTION? IDispatch_Invoke(ptr,arg1,arg2,.......); They should be defined to the correct C++ method calls. Ciao, Marcus
On Mittwoch, 30. Mai 2001 07:46, Marcus Meissner wrote:
On Wed, May 30, 2001 at 04:32:19AM +0200, Malte Starostik wrote:
Well, that was just the first thing that came to mind. Assembler was the second. I somehow didn't even think of a plain function pointer - well yes, I am more used to C++ than C :) Of course it's kinda hard to initialize a C++ method pointer from a vtable offset. Anyway, it should be implemented in winelib and not in my app, so it's not feasible after all. But that doesn't matter now that I realized a full implementation will probably need assembler as the number of arguments is virtually unlimited. So an array of parameters that is copied to the stack via inline assembler is IMHO the way to go. Will give it a try.
?
Why can't you use the WINE supplied macros INTERFACE_FUNCTION?
IDispatch_Invoke(ptr,arg1,arg2,.......);
They should be defined to the correct C++ method calls. Because all I have is an IDispatch pointer and a vtable offset to the method. Calling Invoke itself is not a problem at all. The method to be called by Invoke isn't known at compile time. -Malte -- Wars don't determine who's right, only who's left.
Because all I have is an IDispatch pointer and a vtable offset to the method. Calling Invoke itself is not a problem at all. The method to be called by Invoke isn't known at compile time. -Malte
It sounds to me like you have an impedance mismatch: you have a system that wants to call a C linkage function, and you want to tie it into a C++ object. What you'll have to do is something like this: class Base_class { ... virtual RETTYPE Real_func(arg1, arg2, <etc>) = 0; static RETTYPE Entry_func_stub(void *dis, arg1, arg2, <etc>) { Base_class *ptr = (Base_class *)dis; return dis->Real_func(arg1,arg2,<etc>); } void Hook_up_function(void) { Set_some_func_ptr(Entry_func_stub,(void *)this); } }; .... class Child1: public Base_class { RETTYPE Real_func(arg1,arg2,<etc>); }; Class Child2: public Base_class { RETTYPE Real_func(arg1,arg2,<etc>); }; The stub function in the base class can be coorced into having non-C++ linkage with an appropriate declaration, and will call the appropriate vtable entry and offset the this pointer correctly. While I've not done this under Wine or Windows, I have done this sort of thing in several RTOSs with great success.
participants (5)
-
David Hagood -
James Hatheway -
Malte.Starostik＠t-online.de -
Marcus Meissner -
Ove Kaaven