Re: COM vtable inconsistencies with g++ (was SIGSEGV inIDirectDrawImpl_EnumDisplayModes)

2002-11-28 Thread Ove Kaaven

On Thu, 28 Nov 2002, Christian Costa wrote:

> Does ICOM_USE_INTERFACE_ATTRIBUTE prevent g++ to add the 8 bytes offset?

Yeah.

>  From which g++ version this can be used?

Not sure, but I'm pretty sure it's been supported in Debian's 2.95.4 stuff
(which grabbed lots of stuff from cvs, I think). So I'd guess that it
probably works in 3.0.





Re: COM vtable inconsistencies with g++ (was SIGSEGV inIDirectDrawImpl_EnumDisplayModes)

2002-11-02 Thread Francois Gouget
On Sat, 2 Nov 2002, Andreas Mohr wrote:
[...]
> The only advantage I can think of would be the use of Unix code, but then
> you could achieve the very same thing by writing the Unix equivalent DLL
> of a Windows DLL (e.g.: hardware access or so) and using the Unix specific
> DLL version instead on Wine.

That's one of the advantages and it allows you to do things you would
probably not be able to do by just loading a Winelib dll from a non
Winelib application. One such thing is mixing Win32 windows with QT ones
in a single application. This is not a pipedream, it has already been
been done on a large application at least once.

The other advantage of course is that Winelib makes it possible, at
least in theory, to port your application to non x86 platforms like the
Sparc or PPC. In fact I think the path to removing the x86 monopoly is:
 1. run existing Windows applications using Wine
 2. Linux grows market share
 3. Wine improves enough on non-Linux x86 Unix platforms (FreeBSD,
OpenBSD, Solaris) that you can run Windows apps on them as well as on
Linux
 4. now that Linux has a significant market share on the desktop ISVs
start taking Wine into account when designing applications
 5. ISVs use Winelib to migrate off the Win32 API to more cross-platform APIs
 6. ISVs use Winelib to port their applications to non x86 platforms or
port them directly if they already moved off Win32 using Winelib as a
transition

Not saying this will happen, there are too many factors involved: Java,
.Net, continued survival of non-x86 processors, etc. But Winelib might
play a significant role in the future.

-- 
Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/
 Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.





Re: COM vtable inconsistencies with g++ (was SIGSEGV inIDirectDrawImpl_EnumDisplayModes)

2002-11-02 Thread Ove Kaaven

On Sat, 2 Nov 2002, Matthew Bloch wrote:

> So with the ICOM_MSVTABLE_COMPAT flag set I get the "off-by-two" calling error 
> from within Winelib when it's trying to invoke a COM function.  When it's not 
> set I get the same bug occurring in my program when it tries to do the same.

Don't use ICOM_MSVTABLE_COMPAT with newer g++ versions, it's obsolete. Use
ICOM_USE_COM_INTERFACE_ATTRIBUTE.