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

Re: wineps include fix.

by Huw D M Davies

Actually aren't you supposed to do this? #include <ft2build.h> #include FT_FREETYPE_H #include FT_xxxx_H Huw. -- Dr. Huw D M Davies | Clarendon Laboratory h.davies1(a)physics.ox.ac.uk | Parks Road Tel: +44 1865 272390 | Oxford OX1 3PU Fax: +44 1865 272400 | UK

May 30, 2001

EMAIL REJECTED. RE: Re: wineps include fix.

by ian.pilcher＠home.com

<!! You are not on my whitelist, to avoid spam, I have not recieved your email !!> If your message was not Spam or USE, I strongly apologize for the inconvenice cause by this block, but the ammount of spam recieved on this email address (around 10 per day) is too much for me, and I refuse to read it, so please, accept this appology and resend your message to the address below. Thank you for your time. This message was generated by antispam Your message was not accepted either because: * I don't recognize your address, or * The magic cookie in the 'dated' or 'sender' address you sent to has expired or is invalid. You can contact me using the address: <crazney-dated-80d93cd3482f4319(a)crazney.net> but it will only work for the next 5 days. If you're just sending me SPAM/UCE, buzz off. Regards, David Hammerton aka crazney --your email-- On Wed, 30 May 2001, Ian Pilcher wrote: > You're getting the error because FreeType's macros are not being defined > by your include files. This is supposed to be the way to work around > the > fact that the FreeType guys rename their include files with every minor > release. > > freetype/freetype.h should either define the macros or include another > file that does so. If you can figure out why that isn't happening, let > me know. It is happening, ftheader.h just doesn't define those two symbols. It defines these: #define FT_CONFIG_CONFIG_H <freetype/config/ftconfig.h> #define FT_CONFIG_OPTIONS_H <freetype/config/ftoption.h> #define FT_CONFIG_MODULES_H <freetype/config/ftmodule.h> #define FT_FREETYPE_H <freetype/freetype.h> #define FT_ERRORS_H <freetype/fterrors.h> #define FT_SYSTEM_H <freetype/ftsystem.h> #define FT_IMAGE_H <freetype/ftimage.h> #define FT_TYPES_H <freetype/fttypes.h> #define FT_LIST_H <freetype/ftlist.h> #define FT_OUTLINE_H <freetype/ftoutln.h> #define FT_MODULE_H <freetype/ftmodule.h> #define FT_RENDER_H <freetype/ftrender.h> #define FT_TYPE1_TABLES_H <freetype/t1tables.h> #define FT_TRUETYPE_IDS_H <freetype/ttnameid.h> #define FT_TRUETYPE_TABLES_H <freetype/tttables.h> #define FT_TRUETYPE_TAGS_H <freetype/tttags.h> #define FT_GLYPH_H <freetype/ftglyph.h> #define FT_BBOX_H <freetype/ftbbox.h> #define FT_BEZIER_H <freetype/ftbezier.h> #define FT_CACHE_H <freetype/ftcache.h> #define FT_CACHE_IMAGE_H <freetype/cache/ftcimage.h> #define FT_CACHE_SMALL_BITMAPS_H <freetype/cache/ftcsbits.h> #define FT_MAC_H <freetype/ftmac.h> #define FT_MULTIPLE_MASTERS_H <freetype/ftmm.h> #define FT_SFNT_NAMES_H <freetype/ftsnames.h> #define FT_TRIGONOMETRY_H <freetype/fttrigon.h> #define FT_SYNTHESIS_H <freetype/ftsynth.h> #define FT_CACHE_MANAGER_H <freetype/cache/ftcmanag.h> #define FT_CACHE_INTERNAL_LRU_H <freetype/cache/ftlru.h> #define FT_CACHE_INTERNAL_GLYPH_H <freetype/cache/ftcglyph.h> #define FT_CACHE_INTERNAL_CHUNK_H <freetype/cache/ftcchunk.h> #define FT_INTERNAL_INTERNAL_H <freetype/internal/internal.h> 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?

May 30, 2001

Re: wineps include fix.

by Ove Kaaven

On Wed, 30 May 2001, Ian Pilcher wrote: > You're getting the error because FreeType's macros are not being defined > by your include files. This is supposed to be the way to work around > the > fact that the FreeType guys rename their include files with every minor > release. > > freetype/freetype.h should either define the macros or include another > file that does so. If you can figure out why that isn't happening, let > me know. It is happening, ftheader.h just doesn't define those two symbols. It defines these: #define FT_CONFIG_CONFIG_H <freetype/config/ftconfig.h> #define FT_CONFIG_OPTIONS_H <freetype/config/ftoption.h> #define FT_CONFIG_MODULES_H <freetype/config/ftmodule.h> #define FT_FREETYPE_H <freetype/freetype.h> #define FT_ERRORS_H <freetype/fterrors.h> #define FT_SYSTEM_H <freetype/ftsystem.h> #define FT_IMAGE_H <freetype/ftimage.h> #define FT_TYPES_H <freetype/fttypes.h> #define FT_LIST_H <freetype/ftlist.h> #define FT_OUTLINE_H <freetype/ftoutln.h> #define FT_MODULE_H <freetype/ftmodule.h> #define FT_RENDER_H <freetype/ftrender.h> #define FT_TYPE1_TABLES_H <freetype/t1tables.h> #define FT_TRUETYPE_IDS_H <freetype/ttnameid.h> #define FT_TRUETYPE_TABLES_H <freetype/tttables.h> #define FT_TRUETYPE_TAGS_H <freetype/tttags.h> #define FT_GLYPH_H <freetype/ftglyph.h> #define FT_BBOX_H <freetype/ftbbox.h> #define FT_BEZIER_H <freetype/ftbezier.h> #define FT_CACHE_H <freetype/ftcache.h> #define FT_CACHE_IMAGE_H <freetype/cache/ftcimage.h> #define FT_CACHE_SMALL_BITMAPS_H <freetype/cache/ftcsbits.h> #define FT_MAC_H <freetype/ftmac.h> #define FT_MULTIPLE_MASTERS_H <freetype/ftmm.h> #define FT_SFNT_NAMES_H <freetype/ftsnames.h> #define FT_TRIGONOMETRY_H <freetype/fttrigon.h> #define FT_SYNTHESIS_H <freetype/ftsynth.h> #define FT_CACHE_MANAGER_H <freetype/cache/ftcmanag.h> #define FT_CACHE_INTERNAL_LRU_H <freetype/cache/ftlru.h> #define FT_CACHE_INTERNAL_GLYPH_H <freetype/cache/ftcglyph.h> #define FT_CACHE_INTERNAL_CHUNK_H <freetype/cache/ftcchunk.h> #define FT_INTERNAL_INTERNAL_H <freetype/internal/internal.h> 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?

May 30, 2001

WINE server messages

by David Howells

Hello Alexandre, 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. David

May 30, 2001

Re: wineps include fix.

by Ian Pilcher

David Hammerton wrote: > > hi, seems you have done some updating on it.. but now it still doesnt compile, > im not sure if your trying to include something that is defined elsewhere or > you made a typo, but it seems to bawk on: > > gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -g -O2 > -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_REENTRANT > -I/usr/X11R6/include -o truetype.o truetype.c > truetype.c:13: `#include' expects "FILENAME" or <FILENAME> > truetype.c:14: `#include' expects "FILENAME" or <FILENAME> > I give up. You're getting the error because FreeType's macros are not being defined by your include files. This is supposed to be the way to work around the fact that the FreeType guys rename their include files with every minor release. freetype/freetype.h should either define the macros or include another file that does so. If you can figure out why that isn't happening, let me know. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

May 30, 2001

Re: some unimplemented COM stuff

by Malte.Starostik＠t-online.de

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.

May 30, 2001

Re: some unimplemented COM stuff

by Marcus Meissner

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

May 30, 2001

Status of ASPI?

by Dax Kelson

> > I'm having a failure with a windows app. The application starts, and it > asks me to name my project and pick a directory to store it in. When I do > so, I get errors such as: > > fixme:shell:PathGetCharTypeA d > fixme:shell:PathGetCharTypeA f > fixme:shell:PathGetCharTypeA d > fixme:shell:PathGetCharTypeA t Lots of thanks to Marcus, and his implementation of PathGetChar. I can report that his patch worked for me. My next hurdle is ASPI support. This application I'm running needs to access my DVD drive via ASPI, and it complains it can't see any device. On the Linux side of things, I've setup ide-scsi emulation for my ATAPI DVD drive. Here is the error I'm getting: fixme:aspi:SendASPI32Command ASPI: Partially implemented SC_HA_INQUIRY for adapter 0. At one point I thought ASPI was working since you could use Win32 CDR burning software with Wine. What is the current status of ASPI in Wine? Many thanks! Dax

May 30, 2001

Re: some unimplemented COM stuff

by Malte.Starostik＠t-online.de

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.

May 30, 2001

Re: some unimplemented COM stuff

by Ove Kaaven

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.

May 30, 2001