May 2001 - Wine-Devel - list.winehq.org

Re: PATCH: Version 2, GetX11WindowId

by Alexandre Julliard

Nikolas Zimmermann <wildfox(a)kde.org> writes: > Hi there, > > andrewl (#winehq) advised me to remove > the winuser.h dependencies > > here is the new patch > > Any comments? The main problem is that this requires linking the application to x11drv, which is not a good idea. x11drv is an internal driver that should only be loaded by user/gdi. There needs to be a way to do that without loading x11drv, for instance by using window properties. This is somewhere on my todo list for the new window management code that I'm currently working on. -- Alexandre Julliard julliard(a)winehq.com

May 30, 2001

Re: wineps include fix.

by Alexandre Julliard

Ian Pilcher <ian.pilcher(a)home.com> writes: > I *believe* that <freetype/freetype.h> should always include the header > that defines the macros. If not, it's going to be a nightmare checking > for 2.0.1, 2.0.2, 2.0.3, etc. -- let alone every intermediate snapshot > that a rawhide/cooker distribution might use. It seems the rule is now to use ft2build.h instead of freetype.h. And this will certainly change in the next release again... so yes, it will be a nightmare if we actually try to use the silly macros. But if we simply bypass them and do autoconf checks like we do for every other package, I think it should work, and be harder to break (though I'm sure the freetype guys will manage to do it ;-) Basically do a AC_CHECK_HEADERS(freetype/freetype.h freetype/foo.h freetype/bar.h) and then #ifdef HAVE_FREETYPE_FREETYPE_H #include <freetype/freetype.h> #endif #ifdef HAVE_FREETYPE_FOO_H #include <freetype/foo.h> #endif etc. Then when they change all the header names again in the next release we can simply add the new names to the list. -- Alexandre Julliard julliard(a)winehq.com

May 30, 2001

Re: wineps include fix.

by Ian Pilcher

Alexandre Julliard wrote: > > > FT_SFNT_NAMES_H doesn't appear anywhere in the 2.0.1 headers. It > > appears to be impossible to be source code compatible between 2.0.1 and > > 2.0.2. > > How about doing autoconf checks for all the possible header names > variations, and including the ones we find? This would be a lot more > robust than trying to find the header that defines the macros that > define the headers that define what we need... > I *believe* that <freetype/freetype.h> should always include the header that defines the macros. If not, it's going to be a nightmare checking for 2.0.1, 2.0.2, 2.0.3, etc. -- let alone every intermediate snapshot that a rawhide/cooker distribution might use. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

May 30, 2001

Re: WINE server messages

by Alexandre Julliard

David Howells <dhowells(a)redhat.com> writes: > I'm having a little trouble deciding exactly how to emulate the "module > registration" functionality in my kernel module. It occurs to me that this > might be easier to accomplish with a change to the current wine server message > set. My idea is: > > * Have the server only deal with NT Section objects and views of Sections. > > * Have no separate module table attached to a process. > > * Implement NtQuerySectionInformation/NtSetSectionInformation calls (or > whatever they're called) as wineserver messages. > > * Add an extra Wine-specific information class for the purpose of recording > the extra module information. > > * The wineserver process structure can then be changed so that rather than > keeping a separate list of process_dlls, they can just keep a list of > section views, some of which will be images/modules. Maintaining a section list in the server is certainly something we could do, but I don't really see why you want to get rid of the modules list. What would you gain by doing that?> -- Alexandre Julliard julliard(a)winehq.com

May 30, 2001

Re: wineps include fix.

by Alexandre Julliard

Ian Pilcher <ian.pilcher(a)home.com> writes: > FT_SFNT_NAMES_H doesn't appear anywhere in the 2.0.1 headers. It > appears to be impossible to be source code compatible between 2.0.1 and > 2.0.2. How about doing autoconf checks for all the possible header names variations, and including the ones we find? This would be a lot more robust than trying to find the header that defines the macros that define the headers that define what we need... -- Alexandre Julliard julliard(a)winehq.com

May 30, 2001

Re: wineps include fix.

by Ian Pilcher

Ove Kaaven wrote: > > So FT_TRUETYPE_TABLES_H and FT_GLYPH_H is covered, but FT_NAMES_H and > FT_TRUETYPE_NAMES_H is not. Apparently the defines were changed or > something - FT_SFNT_NAMES_H is apparently the one you must use now? Let me know if this works. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ======================================================================== diff -urN ../wine-20010529cvs/dlls/wineps/truetype.c ./dlls/wineps/truetype.c --- ../wine-20010529cvs/dlls/wineps/truetype.c Tue May 29 18:16:33 2001 +++ ./dlls/wineps/truetype.c Wed May 30 13:24:37 2001 @@ -9,11 +9,31 @@ #ifdef HAVE_FREETYPE +/* + * These stupid ifdefs should work for FreeType 2.0.1 and 2.0.2. 2.0.3 and + * beyond are anybody's guess. + */ + #include <freetype/freetype.h> -#include FT_NAMES_H -#include FT_TRUETYPE_NAMES_H -#include FT_TRUETYPE_TABLES_H #include FT_GLYPH_H +#include FT_TRUETYPE_TABLES_H + +#ifdef FT_NAMES_H +#include FT_NAMES_H /* 2.0.1 */ +#endif + +#ifdef FT_SFNT_NAMES_H +#include FT_SFNT_NAMES_H /* 2.0.2 */ +#endif + +#ifdef FT_TRUETYPE_NAMES_H +#include FT_TRUETYPE_NAMES_H /* 2.0.1 */ +#endif + +#ifdef FT_TRUETYPE_IDS_H +#include FT_TRUETYPE_IDS_H /* 2.0.2 */ +#endif + #include <sys/types.h> #include <dirent.h> #include <string.h>

May 30, 2001

PATCH: Version 2, GetX11WindowId

by Nikolas Zimmermann

Hi there, andrewl (#winehq) advised me to remove the winuser.h dependencies here is the new patch Any comments? Bye Bye Niko -- Nikolas Zimmermann wildfox(a)kde.org

May 30, 2001

Re: wineps include fix.

by Ian Pilcher

Huw D M Davies wrote: > > Actually aren't you supposed to do this? > > #include <ft2build.h> > #include FT_FREETYPE_H > #include FT_xxxx_H > 2.0.1 (at least as packaged by Red Hat) does not include a file named ft2build.h. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

May 30, 2001

Re: wineps include fix.

by Ian Pilcher

Ove Kaaven wrote: > > So FT_TRUETYPE_TABLES_H and FT_GLYPH_H is covered, but FT_NAMES_H and > FT_TRUETYPE_NAMES_H is not. Apparently the defines were changed or > something - FT_SFNT_NAMES_H is apparently the one you must use now? FT_SFNT_NAMES_H doesn't appear anywhere in the 2.0.1 headers. It appears to be impossible to be source code compatible between 2.0.1 and 2.0.2. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

May 30, 2001

Re: some unimplemented COM stuff

by David Hagood

> 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.

May 30, 2001