November 2008 - Wine-devel - list.winehq.org

fixme: IDirect3DDevice9::CreateQuery
by Krzysztof Drewniak 09 Nov '08

09 Nov '08

I'm getting a "fixme:d3d:IWineD3DDeviceImpl_EvictManagedResources (0xb550510) : stub fixme:d3d:IWineD3DDeviceImpl_CreateQuery (0xb550510) Unhandled query type 4 fixme:d3d9:IDirect3DDevice9Impl_CreateQuery (0xb543bc8) call to IWineD3DDevice_CreateQuery failed" over and over again and the app isn't working right. Either can someone fix this of drop me a line about what might need to be done? (Not a Wine expert, but I'll gladly help.) Krzys D

2 1

Re: [PATCH] Implement GdipGetLogFontA
by Adam Petaccia 09 Nov '08

09 Nov '08

Ignore. Will resend. On Sun, 2008-11-09 at 13:03 -0500, Adam Petaccia wrote: > --- > dlls/gdiplus/font.c | 25 +++++++++++++++++++++++++ > dlls/gdiplus/gdiplus.spec | 2 +- > 2 files changed, 26 insertions(+), 1 deletions(-) > > diff --git a/dlls/gdiplus/font.c b/dlls/gdiplus/font.c > index 32713c7..2477f7b 100644 > --- a/dlls/gdiplus/font.c > +++ b/dlls/gdiplus/font.c > @@ -368,6 +368,31 @@ GpStatus WINGDIPAPI GdipGetFontUnit(GpFont *font, Unit *unit) > } > > /******************************************************************************* > + * GdipGetLogFontA [GDIPLUS.@] > + */ > +GpStatus WINGDIPAPI GdipGetLogFontA(GpFont *font, GpGraphics *graphics, > + LOGFONTA *lfa) > +{ > + INT bytesWritten; > + /* FIXME: use graphics */ > + if(!(font && graphics && lfa)) > + return InvalidParameter; > + > + memcpy(&font->lfw, lfa, sizeof(LOGFONTA)); > + bytesWritten = WideCharToMultiByte(CP_ACP, 0, font->lfw.lfFaceName, -1, > + lfa->lfFaceName, LF_FACESIZE, NULL, NULL); > + > + if (bytesWritten == 0) > + { > + ERR("Could not convert from WideChar to Multibyte with error %d\n", > + GetLastError()); > + return GenericError; > + } > + > + return Ok; > +} > + > +/******************************************************************************* > * GdipGetLogFontW [GDIPLUS.@] > */ > GpStatus WINGDIPAPI GdipGetLogFontW(GpFont *font, GpGraphics *graphics, > diff --git a/dlls/gdiplus/gdiplus.spec b/dlls/gdiplus/gdiplus.spec > index a2790a3..0e7ac5c 100644 > --- a/dlls/gdiplus/gdiplus.spec > +++ b/dlls/gdiplus/gdiplus.spec > @@ -311,7 +311,7 @@ > @ stdcall GdipGetLineSpacing(ptr long ptr) > @ stub GdipGetLineTransform > @ stdcall GdipGetLineWrapMode(ptr ptr) > -@ stub GdipGetLogFontA > +@ stdcall GdipGetLogFontA(ptr ptr ptr) > @ stdcall GdipGetLogFontW(ptr ptr ptr) > @ stdcall GdipGetMatrixElements(ptr ptr) > @ stub GdipGetMetafileDownLevelRasterizationLimit

1 0

Re: mshtml: Implement IHTMLStyle get/put posLeft (try 9)
by Austin English 09 Nov '08

09 Nov '08

On Fri, Nov 7, 2008 at 10:53 PM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Hi, > Use strtolW correctly. > > Changelog: > mshtml: Implement IHTMLStyle get/put posLeft > > Best Regards > Alistair Leslie-Hughes > > > > > > You forgot to attach the patch :-) -- -Austin

1 0

wine build time: 6 (or 3) minutes with q9400
by Dan Kegel 08 Nov '08

08 Nov '08

FWIW: with wine from git from a couple days ago, here are wine build times on various Intel CPUs in seconds on Ubuntu 8.10's gcc-4.3.2 (or 8.04): sec cpu wine notes 676 e7200 June http://kegel.com/new-computer-2008.html ubuntu 8.04 615 e7300 Nov 585 e7400 Nov (estimated, supposedly 5% faster than e7300) 540 e8400 Nov 360 q9400 Nov In all cases, this was with the default optimization level, -O2. Compiling with -O0 was roughly twice as fast (e.g. 196 seconds to build on the q9400). The dual core e7300 and e8400 were tested with -j3; the quad core q9400 with -j5. The current crop of CPUs is that they run cooler than older ones. Replacing the old Athlon 64's in the patchwatcher cluster with new CPUs and 80+ power supplies makes a big difference in the room's temperature! The quad CPUs are coming down in price. Once you get used to fast builds, it's hard to go back, so don't try a q9400 or faster CPU unless you want to keep it :-) Older benchmarks: http://techgage.com/article/intel_core_2_quad_q6600/4 (is gentoo really that fast, or was he building with -O0?) http://www.winehq.org/pipermail/wine-devel/2008-June/066121.html (q6600 386 seconds).

3 5

Re: [1/2] richedit: Created initial tests for windowless richedit controls. (try 2)
by Peter Oberndorfer 08 Nov '08

08 Nov '08

On Samstag 08 November 2008, Dylan Smith wrote: > (Ensured compiler independence by modifying byte code templates) > > The initial tests added simply call CreateTextServices, and query for > the ITextServices interface, then cleans up. > > Since CreateTextServices needs an implementation of ITextHost to be > given, this patch needed a stub implementation. This required wrappers > for converting thiscall to stdcall which are now implementing by > adapting a byte code wrapper template. Although byte code isn't portable > across processors, this is only needed for x86 platforms so it is only > meant to be compiler independent. > > In order to investigate what is happening in the tests, it is helpful > to trace the calls to ITextHost methods by the richedit controls. I > realized it would be too verbose to trace all these calls by default, > so I wrapped them all with a check for winedebug > 1, since normally > winedebug is 0 or 1. > --- > dlls/riched20/tests/Makefile.in | 3 +- > dlls/riched20/tests/txtsrv.c | 593 +++++++++++++++++++++++++++++++++++++++ > 2 files changed, 595 insertions(+), 1 deletions(-) > create mode 100644 dlls/riched20/tests/txtsrv.c > Hi, This page [1] seems to suggest memory returned from HeapAlloc is marked as not executable. Other tests (ntdll exception) are using VirtualAlloc() for dynamically created code. patch 1 > +/* The following x86 code string converts between the thiscall and stdcall > + * calling convetions. The thiscall calling convention places the This > + * pointer in ecx on the x86 platform, and the stdcall calling convention > + * pushes the This pointer on the stack as the first argument. > + * > + * The wrapper's code finishes by jumping to the real function. > + * > + * Byte codes are used so that a copy of it can be modified to use > + * for each method in ITextHost. */ patch 2 > -/* The following x86 code string converts between the thiscall and stdcall > +/* The following x86 code strings convert between the thiscall and stdcall > * calling convetions. The thiscall calling convention places the This Here you introduce comments that you seem to change in the second patch. Maybe use the right text in the first patch? Additionally the term code string sounds odd. Maybe replace that with "The following x86 assembler code..." or something similar? > #define ITextServices_QueryInterface(p,a,b) (p)->lpVtbl->QueryInterface(p,a,b) > #define ITextServices_AddRef(p) (p)->lpVtbl->AddRef(p) > #define ITextServices_Release(p) (p)->lpVtbl->Release(p) > -/*** ITextServices methods ***/ > -#define ITextServices_TxSendMessage(p,a,b,c,d) (p)->lpVtbl->TxSendMessage(p,a,b,c,d) > -#define ITextServices_TxDraw(p,a,b,c,d,e,f,g,h,i,j,k,l) (p)->lpVtbl->TxDraw(p,a,b,c,d,e,f,g,h,i,j,k,l) Why do you only move some of those #defines part of ITextServices and not the one part of IUnknown ? I do not know much about those #defines but this seems odd Maybe i am missing something but why do you need those thiscall wrappers? Wouldn't it be possible to use the DEFINE_THISCALL_WRAPPER and THISCALL macros like in txtserv.c? Greetings Peter [1] http://www.unixwiz.net/techtips/xp-sp2.html

2 1

noob req: ddraw/vertexbuffer.c and HW vertex buffers
by FeepingCreature 08 Nov '08

08 Nov '08

Hi, I've been playing Gothic2 and getting lots of messages regarding d3d7:IDirect3DVertexBufferImpl_Optimize, printed by ddraw/vertexbuffer.c. Reading the comments for that function seems to indicate that vertex buffers are currently emulated in software, and will be handled in hardware as soon as wined3d is capable of that - however, reading wined3d/vertexbuffer.c, especially CreateVBO, implies that hardware/GL vertex buffers are already supported. Git logs also show that ddraw/vertexbuffer.c has not been changed in a few months. Did I completely mis-interpret the comments, or has this file simply been forgotten? And if so, could some kind soul sacrifice the time to bring it up to speed with the rest of Wine, so that us Gothic players can enjoy better framerates? Thanks for reading. ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

2 1

integration of winscard patches: ideas for implementing test cases?
by frechdachs69 07 Nov '08

07 Nov '08

Hi together! I am currently wondering which test cases make sense after an integration of winscard patches. So far most API calls are directly related to pcsc-lite behaviour and therefore we need a result from pcsc-lite which is comparable with what Win/winscard.dll would return to us. But this is almost always depending on the smartcard reader setup at the local machine. As a result I see a problem to automate such tests without having underlying assumptions concerning the attached smartcard readers and maybe inserted (or not) smartcards (i.e. specific hardware is necessary). Any ideas? Does anyone know whether someone has written a virtual card reader which can be accessed using pcsc-lite (i.e. an IFD handler exists which simulates reader behaviour)? Maybe together with the option to insert a virtual card? If not then I am going to subscribe to the pcsc-lite maling list and ask this question there, too. Any other ideas how to automate winscard tests to be able to add such tests to the regression test suite? Regards Heiko

2 1

Re: inetcomm: Add an implementation of IVirtualStream.
by Huw Davies 07 Nov '08

07 Nov '08

Hans Leidekker wrote: > This interface is undocumented but fortunately its name was enough > of a hint to create a sensible implementation. Used by Outlook when > retrieving or sending a mail. We already have MimeOleCreateVirtualStream() which is implemented on top of CreateStreamOnHGlobal()... Huw.

2 2

Issues with VMware Workstation 6.5.0, winetest and directx acceleration enabled
by Paul Vriens 07 Nov '08

07 Nov '08

Hi, FYI. I had to disable "Accelerate 3D graphics (DirectX 9.0c)" in the VM settings on several of my Vmware boxes. Winetest crashed my W2K and Vista box (ddraw:d3d) and made my Win98 box unresponsive (user32:sysparams when changing to 8bit display). If I can find some spare time I will report this to VMware. I do however run VMware Workstation on Fedora 8 which is not officially supported. -- Cheers, Paul.

2 1

[RFC] winecfg -- approach to making the theme names & colours lists sortable
by Reece Dunn 07 Nov '08

07 Nov '08

Hi, At the moment, if you have several themes installed on your system (e.g. by installing StyleXP) winecfg will list those themes in a random (read not sorted) order. If I just add the CBS_SORT flag, the wrong theme is chosen because the order in the combo boxes are assumed to be the same order in a DSA (dynamic array) containing the theme, size or colour data. My idea is to store the additional data in the combo box in the item's item data. This will mean a major rewrite of this area to remove the use of the DSAs, so I am wondering what the best way to approach this is. I am currently thinking something along the lines of: 1. Replace the DSA for the theme colour list, storing the data in the item data of the colour list combo box; 2. Replace the DSA for the theme size list, storing the data in the item data of the size list combo box; 3. Replace the DSA for the theme list, storing the data in the item data of the theme list combo box; 4. Make the theme list and theme colour lists sorted. Does this approach seem reasonable? - Reece

1 0