March 2006 - Wine-Devel - list.winehq.org

Re: configure: add --with-fontfir (try3) with patch!

by Vitaly Lipatov

On Tuesday 21 February 2006 20:10, Vitaly Lipatov wrote: > I made some fixes to correct work. > > Changelog > add --with-fontdir parameter to configure for set WINE fonts > placement. Sorry, what is broken with my patch? http://www.winehq.org/pipermail/wine-patches/2006-February/024535.html -- Lav Vitaly Lipatov Saint-Petersburg, Etersoft www.etersoft.ru GNU! ALT Linux Team! WINE! LaTeX! LyX!

March 5, 2006

Re: KERNEL32: Improve descriptions

by Marcus Meissner

On Sun, Mar 05, 2006 at 07:39:04PM +0300, Vitaly Lipatov wrote: > On Sunday 05 March 2006 14:13, Alexandre Julliard wrote: > > Vitaly Lipatov <lav(a)etersoft.ru> writes: > > > -UINT WINAPI GetTempFileNameW( LPCWSTR path, LPCWSTR prefix, > > > UINT unique, LPWSTR buffer ) +UINT WINAPI GetTempFileNameW( > > > LPCWSTR lpPathName, LPCWSTR lpPrefixString, UINT uUnique, > > > LPWSTR lpTempFileName ) > > > > *Please* don't change nice readable parameter names into the > > horrible Hungarian line noise format. > Sorry, I thought we need to fix parameter names according to > MSDN :( > Have we some policy about it? Will I change Hungarian notation to > readable names when possible? Just don't change the name. The *types* should be the same as MSDN, the *names* do not need to. Ciao, Marcus

March 5, 2006

fixme:commdlg:GetFileName95 Flags 0x00900000 not yet implemented

by Rainer Dorsch

Hello, wine-0.9.9 still does not display folders correctly in a file select box (Lotus Notes in this case). Folders and files are displayed with the file symbol. It seems to be only a display issue, clicking on folders still opens them. A screenshot is here http://www.winehq.org/pipermail/wine-devel/attachments/20060223/9f1675d7/fi… shows an example for rd at silverboxy:~/test$ ls -l insgesamt 4 drwxr-xr-x 2 rd rd 4096 2006-02-23 17:08 dir -rw-r--r-- 1 rd rd 0 2006-02-23 17:08 file rd at silverboxy:~/test$ The console shows this log fixme:imm:ImmReleaseContext (0x30170, 0x4997af70): stub fixme:imm:ImmReleaseContext (0x30190, 0x4997af70): stub fixme:imm:ImmReleaseContext (0x30170, 0x4997af70): stub fixme:imm:ImmReleaseContext (0x30170, 0x4997af70): stub fixme:imm:ImmReleaseContext (0x30170, 0x4997af70): stub fixme:commdlg:GetFileName95 Flags 0x00900000 not yet implemented fixme:imm:ImmReleaseContext (0x30190, 0x4997af70): stub fixme:process:GetProcessWorkingSetSize (0xffffffff,0x4075d768,0x4075d76c): stub fixme:process:SetProcessWorkingSetSize (0xffffffff,33554432,33554432): stub - harmless when opening a file select box. Causes this one fixme:commdlg:GetFileName95 Flags 0x00900000 not yet implemented this wine glitch? Thanks, Rainer -- Rainer Dorsch Alzentalstr. 28 D-71083 Herrenberg 07032-919495 Icq: 32550367

March 5, 2006

Re: KERNEL32: Improve descriptions

by Vitaly Lipatov

On Sunday 05 March 2006 14:13, Alexandre Julliard wrote: > Vitaly Lipatov <lav(a)etersoft.ru> writes: > > -UINT WINAPI GetTempFileNameW( LPCWSTR path, LPCWSTR prefix, > > UINT unique, LPWSTR buffer ) +UINT WINAPI GetTempFileNameW( > > LPCWSTR lpPathName, LPCWSTR lpPrefixString, UINT uUnique, > > LPWSTR lpTempFileName ) > > *Please* don't change nice readable parameter names into the > horrible Hungarian line noise format. Sorry, I thought we need to fix parameter names according to MSDN :( Have we some policy about it? Will I change Hungarian notation to readable names when possible? -- Lav Vitaly Lipatov Saint-Petersburg, Etersoft www.etersoft.ru GNU! ALT Linux Team! WINE! LaTeX! LyX!

March 5, 2006

Re: [Compile problem] GL_STENCIL_BACK_FAIL vs. GL_STENCIL_BACK_FAIL_ATI

by H. Verbeet

On 05/03/06, Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: > Hallo, > > compiling a recent CVS checkout, I go a failure with GL_STENCIL_BACK_FAIL > etc undefined. Same problem for me. http://www.winehq.org/pipermail/wine-devel/2006-March/045297.html > It seems that a patch from Vitaly regarding wined3d_gl.h from > yesterday evening as notor only partial applied. Well, no, the patch is just like that. It assumes GL_STENCIL_BACK_FAIL, GL_STENCIL_BACK_PASS_DEPTH_FAIL and GL_STENCIL_BACK_PASS_DEPTH_PASS are defined, which is not guaranteed. > Appended patch lets me circumvent that problem. I'm not sure if GL_STENCIL_BACK_FAIL and GL_STENCIL_BACK_FAIL_ATI are interchangeable, but more importantly it makes the same kind of assumptions about what's going to be defined.

March 5, 2006

Re: DirectDraw -> WineD3D patch

by Stefan Dösinger

> That's indeed the reason. Simple fix is to set the rendertarget usage also > for ddraw offscreen surfaces.Not sure if there are any possible sideeffects > of this, but until now i haven't seen any. That looks a bit more complex. I changed the way ddraw and WineD3D interact some time ago, but I didn't update the palette code for that change. I think I have to re-write the palette setting code, it's pretty crappy ATM.

March 5, 2006

[Compile problem] GL_STENCIL_BACK_FAIL vs. GL_STENCIL_BACK_FAIL_ATI

by Uwe Bonnes

Hallo, compiling a recent CVS checkout, I go a failure with GL_STENCIL_BACK_FAIL etc undefined. It seems that a patch from Vitaly regarding wined3d_gl.h from yesterday evening as notor only partial applied. Appended patch lets me circumvent that problem. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- Index: wine/dlls/wined3d/device.c =================================================================== RCS file: /home/wine/wine/dlls/wined3d/device.c,v retrieving revision 1.145 diff -u -r1.145 device.c --- wine/dlls/wined3d/device.c 4 Mar 2006 17:10:57 -0000 1.145 +++ wine/dlls/wined3d/device.c 5 Mar 2006 14:47:13 -0000 @@ -3773,9 +3773,9 @@ GLint action = StencilOp(Value); - glGetIntegerv(GL_STENCIL_BACK_FAIL, &stencilFail); - glGetIntegerv(GL_STENCIL_BACK_PASS_DEPTH_FAIL, &depthFail); - glGetIntegerv(GL_STENCIL_BACK_PASS_DEPTH_PASS, &stencilPass); + glGetIntegerv(GL_STENCIL_BACK_FAIL_ATI, &stencilFail); + glGetIntegerv(GL_STENCIL_BACK_PASS_DEPTH_FAIL_ATI, &depthFail); + glGetIntegerv(GL_STENCIL_BACK_PASS_DEPTH_PASS_ATI, &stencilPass); if(WINED3DRS_CCW_STENCILFAIL == State) { stencilFail = action;

March 5, 2006

World of Warcraft 0.10 Public Test Realm (PTR)

by Tomas Carnecky

At a certain point the screen just turns black, it's always at the same point, and when looking through the +x11drv trace I can see these messages at that point: trace:x11drv:X11DRV_DCICommand (20,(12,2079885668,543712117),(nil)) trace:x11drv:X11DRV_DCICommand (20,(13,1792,543712117),0x7bf88d40) trace:x11drv:X11DRV_DCICommand (20,(11,1792,543712117),0x7bf88d60) trace:x11drv:X11DRV_DCICommand (20,(10,1792,543712117),0x7bf88ea8) also, these messages don't appear in version 1.9.4 (which is the 'live' version). So I suspect that Blizzard added something related to this function to the 0.10 version which breaks something. When the screen turns black, its just the screen, everything else works, keyboard for sure, I can press 'Esc' to get out of the game, not sure about the mouse though.. Does anyone have an idea how to fix this? tom

March 5, 2006

Re: shell32: Unicode'ify ISFHelper interface

by Michael Jung

Hey Vitaliy, thanks for the comments. I've sent an updated version. On Saturday 04 March 2006 20:26, Vitaliy Margolen wrote: > Here > > +++ b/dlls/shell32/shfldr_fs.c > > + if (uLen < lstrlenW (wszNewFolder) + 4) > and here > > +++ b/dlls/shell32/shfldr_unixfs.c > > + if (uLen < sizeof(wszNewFolder)/sizeof(WCHAR)+3) > Why 4 in one place and 3 in the other? That's because the sizeof expression counts the terminating zero, while strlen does'nt. Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

March 5, 2006

WineFile improvements

by John Len

Hello! I am now preparing patch, which should add unimplemented functionality. While preparing the patch, I've got a couple of questions: 1. There is a menu item "Associations". Should I implement it as a control panel applet? Anyway, it's pretty clear, it shouldn't be an integral part of winefile, as it isn't winefile specific. 2. Should Find File be a stand-alone application? 3.What library should pack/unpack use? Should it use zip/unzip utilities or some dll? Thanks for answering any of these questions Yours Truely, Evgeny F

March 5, 2006

Re: KERNEL32: Improve descriptions

by Alexandre Julliard

Vitaly Lipatov <lav(a)etersoft.ru> writes: > -UINT WINAPI GetTempFileNameW( LPCWSTR path, LPCWSTR prefix, UINT unique, LPWSTR buffer ) > +UINT WINAPI GetTempFileNameW( LPCWSTR lpPathName, LPCWSTR lpPrefixString, UINT uUnique, LPWSTR lpTempFileName ) *Please* don't change nice readable parameter names into the horrible Hungarian line noise format. -- Alexandre Julliard julliard(a)winehq.org

March 5, 2006

Re: DirectDraw -> WineD3D patch and Wine-0.9.9

by Stefan Dösinger

Hi, > No, it isn't. AFAIK this patch modifies DirectDraw and Direct3D 7 Correct. I started sending 2 header patches, and they were merged. I'll steadily send small WineD3D patches until WineD3D is ready for the ddraw merge, then I'll provide a last patch for testing. If it works fine and AJ likes it, it can be merged. Don't know if it will be in Wine 1.0, depends on the time and how many regressions occur. There's a high number of ddraw / d3d7 apps which work, so regressions are likely. Stefan

March 5, 2006

Re: [d3d8] regression between 0.9.8 and 0.9.9 in Age of Mythology

by Roderick Colenbrander

> Yes I noticed that the new code was always 1c4 as well, but hadn't > gone back to see what the old code was doing. But 1c4 definitely > seems wrong since the vertex coordinates are all messed up and invalid > according to MSDN. For example z is supposed to be [0,1] but I get > large values, and rhw is also supposed to be between [0,1/MaxVertexW] > but I was getting negative values. I'll look into the FVF code more. I think that those 'wrong' values appear in the cases where 0x1c4 shouldn't be used. The fvf is set by the SetFVF call which is called from d3d8's SetVertexShader. (the comment in drawprim.c saying that the fvf needs to be set in the stateblock from d3d's SetVertexShader can be ignored I think as it appears that's already done by this call) The FVF received by SetFVF is the vertex shader itself. I think something goes wrong with selecting the vertex shader but I haven't looked at this yet. Roderick -- Echte DSL-Flatrate dauerhaft f�r 0,- Euro*! "Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl

March 5, 2006

GL_STENCIL-related build failures in dlls/wined3d/device.c

by Gerald Pfeifer

The recent changes to dlls/wined3d/device.c cause the following build failures for me on FreeBSD 5.4, though I assume this is in fact not related to FreeBSD but to xorg 6.8.2 or libglut 6.4.1 on this system. device.c: In function `IWineD3DDeviceImpl_SetRenderState': device.c:3776: error: `GL_STENCIL_BACK_FAIL' undeclared (first use in this function) device.c:3776: error: (Each undeclared identifier is reported only once device.c:3776: error: for each function it appears in.) device.c:3777: error: `GL_STENCIL_BACK_PASS_DEPTH_FAIL' undeclared (first use in this function) device.c:3778: error: `GL_STENCIL_BACK_PASS_DEPTH_PASS' undeclared (first use in this function) gmake[2]: *** [device.o] Error 1 gmake[2]: Leaving directory `/.amd_mnt/nashira/files5/test/wine/dlls/wined3d' gmake[1]: *** [wined3d] Error 2 The most straightforward patch would be the one below, but it leaves three "variable may be used uninitialized" warnings in the first of the two affected spots. Gerald Index: device.c =================================================================== RCS file: /home/wine/wine/dlls/wined3d/device.c,v retrieving revision 1.145 diff -u -3 -p -r1.145 device.c --- device.c 4 Mar 2006 17:10:57 -0000 1.145 +++ device.c 5 Mar 2006 08:35:52 -0000 @@ -3226,9 +3226,15 @@ HRESULT WINAPI IWineD3DDeviceImpl_SetRen GLint action = StencilOp(Value); +#ifdef GL_STENCIL_FAIL glGetIntegerv(GL_STENCIL_FAIL, &stencilFail); +#endif +#ifdef GL_STENCIL_PASS_DEPTH_FAIL glGetIntegerv(GL_STENCIL_PASS_DEPTH_FAIL, &depthFail); +#endif +#ifdef GL_STENCIL_PASS_DEPTH_PASS glGetIntegerv(GL_STENCIL_PASS_DEPTH_PASS, &stencilPass); +#endif if(WINED3DRS_STENCILFAIL == State) { stencilFail = action; @@ -3773,9 +3779,15 @@ HRESULT WINAPI IWineD3DDeviceImpl_SetRen GLint action = StencilOp(Value); +#ifdef GL_STENCIL_BACK_FAIL glGetIntegerv(GL_STENCIL_BACK_FAIL, &stencilFail); +#endif +#ifdef GL_STENCIL_BACK_PASS_DEPTH_FAIL glGetIntegerv(GL_STENCIL_BACK_PASS_DEPTH_FAIL, &depthFail); +#endif +#ifdef GL_STENCIL_BACK_PASS_DEPTH_PASS glGetIntegerv(GL_STENCIL_BACK_PASS_DEPTH_PASS, &stencilPass); +#endif if(WINED3DRS_CCW_STENCILFAIL == State) { stencilFail = action;

March 5, 2006

Re: Wine 0.9.9 and instalation of AutoCAD 2000

by Boaz Harrosh

Vitaliy Margolen wrote: > Please submit bug reports to http://bugs.winehq.org/ instead of sending > e-mails here. > Bug report aside, he is a developer and he wants to fix this. What he's asking is if any one remember an issue concerning: "map_image Section .rsrc"

March 5, 2006

Re: Wine 0.9.9 and instalation of AutoCAD 2000

by Vitaliy Margolen

Saturday, March 4, 2006, 11:11:35 PM, Dimitry Naldayev wrote: > Hi all, > When I try to install AutoCAD 2000 on Wine 0.9.9 (hmm... it is cvs checkout > about 04 march 2006 21:00 GMT+0500 PERM. I do not remember precise time) > I get error in console: > err:module:map_image Section .rsrc too large (f000+e000/1c000) > and installation programm draw error box with message > "Cannot load c:\windows\temp\_ISTMP0.DIR\iutil.dll" > but the file is present... Please submit bug reports to http://bugs.winehq.org/ instead of sending e-mails here. Thank you. Vitaliy.

March 5, 2006

Wine 0.9.9 and instalation of AutoCAD 2000

by Dimitry Naldayev

Hi all, When I try to install AutoCAD 2000 on Wine 0.9.9 (hmm... it is cvs checkout about 04 march 2006 21:00 GMT+0500 PERM. I do not remember precise time) I get error in console: err:module:map_image Section .rsrc too large (f000+e000/1c000) and installation programm draw error box with message "Cannot load c:\windows\temp\_ISTMP0.DIR\iutil.dll" but the file is present... Any ideas where to dig? --- Dimitry

March 5, 2006

Re: DirectDraw -> WineD3D patch

by Peter Beutner

Hi > I'll look at this, the whole palette code is a bit messy. My suspicion is that > IDirectDrawPaletteImpl_SetEntries / IWineD3DPaletteImpl_SetEntries doesn't > update all surfaces that use a palette. That's indeed the reason. Simple fix is to set the rendertarget usage also for ddraw offscreen surfaces.Not sure if there are any possible sideeffects of this, but until now i haven't seen any. f005d3af1e8f4cacf1211c6fc3952acbd4766332 diff --git a/dlls/ddraw/ddraw.c b/dlls/ddraw/ddraw.c index 34d91da..4b44035 100644 --- a/dlls/ddraw/ddraw.c +++ b/dlls/ddraw/ddraw.c @@ -1788,8 +1788,8 @@ IDirectDrawImpl_CreateNewSurface(IDirect PixelFormat_WineD3DtoDD(&pDDSD->ddpfPixelFormat, Mode.Format); Format = Mode.Format; - /* If it's a off-screen D3D device, set the rendertarget usage */ - if(pDDSD->ddsCaps.dwCaps & DDSCAPS_3DDEVICE) + /* If it's a off-screen D3D/DDraw device, set the rendertarget usage */ + if(pDDSD->ddsCaps.dwCaps & ( DDSCAPS_3DDEVICE | DDSCAPS_OFFSCREENPLAIN) ) Usage |= WINED3DUSAGE_RENDERTARGET; } }

March 5, 2006

Re: [d3d8] regression between 0.9.8 and 0.9.9 in Age of Mythology

by Aric Cyr

On 3/5/06, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > > On 3/4/06, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > I installed AOM (trial) here and I think the issue is related to the FVF. > The function initializeFVF is only partially implemented and in case of the > new code with my patch I see values '0x1c4 / 0x2' while using the old code I > see other values too (0x112, 0x2d2, 0x212, 0x152). So I think we should look > there and check what the old code did. (the code is quite differently) Yes I noticed that the new code was always 1c4 as well, but hadn't gone back to see what the old code was doing. But 1c4 definitely seems wrong since the vertex coordinates are all messed up and invalid according to MSDN. For example z is supposed to be [0,1] but I get large values, and rhw is also supposed to be between [0,1/MaxVertexW] but I was getting negative values. I'll look into the FVF code more. Regards, Aric -- Aric Cyr <Aric.Cyr at gmail dot com> (http://acyr.net)

March 5, 2006

Re: wined3d: Implemented fallback for separate stencil operation in WINED3DRS_CCW_STENCIL*

by H. Verbeet

On 04/03/06, Vitaly Budovski <vbudovsk(a)cs.rmit.edu.au> wrote: > + glGetIntegerv(GL_STENCIL_BACK_FAIL, &stencilFail); > + glGetIntegerv(GL_STENCIL_BACK_PASS_DEPTH_FAIL, &depthFail); > + glGetIntegerv(GL_STENCIL_BACK_PASS_DEPTH_PASS, &stencilPass); device.c: In function `IWineD3DDeviceImpl_SetRenderState': device.c:3776: error: `GL_STENCIL_BACK_FAIL' undeclared (first use in this function) device.c:3776: error: (Each undeclared identifier is reported only once device.c:3776: error: for each function it appears in.) device.c:3777: error: `GL_STENCIL_BACK_PASS_DEPTH_FAIL' undeclared (first use in this function) device.c:3778: error: `GL_STENCIL_BACK_PASS_DEPTH_PASS' undeclared (first use in this function)

March 5, 2006

Re: [d3d8] regression between 0.9.8 and 0.9.9 in Age of Mythology

by Roderick Colenbrander

> On 3/4/06, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > > Right now d3d8's SetVertexShader is disabled because d3d8 shaders don't > work > > using wined3d yet. Last week I experimented a bit with it and I managed > to > > get some simple vertex shader examples working (for instance > > http://www.codesampler.com/source/dx8_vs11_shader_simple.zip and the > dolphin > > sample from sdk although with small issues). If I run bigger apps like > > 3dmark2001 and others there are huge drawing issues. I'm not very > familiar > > with the shader/drawing code (and vertex shaders in general) so it is > very > > difficult for me to debug. You can try the patch attached to this email > but > > it is far from complete. If you or someone else with enough experience > can > > look at it, you're welcome as my time is limited. > > Thanks for the patch and info Roderick. > > I'll take a look and see if I can get things working a bit better. > Using your patch and the old d3d8 code I hope to whip something > together. I installed AOM (trial) here and I think the issue is related to the FVF. The function initializeFVF is only partially implemented and in case of the new code with my patch I see values '0x1c4 / 0x2' while using the old code I see other values too (0x112, 0x2d2, 0x212, 0x152). So I think we should look there and check what the old code did. (the code is quite differently) Roderick -- "Feel free" mit GMX FreeMail! Monat f�r Monat 10 FreeSMS inklusive! http://www.gmx.net

March 4, 2006

Re: shell32: Unicode'ify ISFHelper interface

by Vitaliy Margolen

Saturday, March 4, 2006, 10:35:54 AM, Michael Jung wrote: > ChangeLog: > Unicode'ify shell32 internal ISFHelper interface and it's implementors. > dlls/shell32/shellfolder.h | 4 ++- > dlls/shell32/shfldr_fs.c | 55 > +++++++++++++++++++++--------------------- dlls/shell32/shfldr_unixfs.c | > 32 ++++++++++++++---------- > dlls/shell32/shv_bg_cmenu.c | 6 ++--- > 4 files changed, 51 insertions(+), 46 deletions(-) Few questions: > - if (uLen < strlen (szNewFolder) + 4) > + if (uLen < lstrlenW (wszNewFolder) + 4) Probably should use sizeof(wszNewFolder)/sizeof(WCHAR) + 4. A bit awkward but compiled into single number. And it looks like that's what you used in shfldr_unixfs.c <g>. > - _ILSimpleGetText (pidl, szText, MAX_PATH); > - if (0 == strcasecmp (szText, lpName)) { > - sprintf (lpName, "%s %d", szNewFolder, i++); > + _ILSimpleGetTextW (pidl, wszText, MAX_PATH); > + if (0 == lstrcmpiW (wszText, pwszName)) { > + sprintfW (pwszName, wszFormat, wszNewFolder, i++); To be safe probably should use snprintfW instead. > + if (This->sPathTarget) > + lstrcpyW(wszNewDir, This->sPathTarget); Kind of the same thing. Here > +++ b/dlls/shell32/shfldr_fs.c > + if (uLen < lstrlenW (wszNewFolder) + 4) and here > +++ b/dlls/shell32/shfldr_unixfs.c > + if (uLen < sizeof(wszNewFolder)/sizeof(WCHAR)+3) Why 4 in one place and 3 in the other? Vitaliy Margolen

March 4, 2006

Re: WRT: winetest-latest is outdated

by Hans Leidekker

On Saturday 04 March 2006 12:34, Saulius Krasuckas wrote: > And that is done by issuing "make crosstest", which currently fails on my > box using most recent RPMs provided by Hans Leidekker. I've created an updated set of RPMs that allow me to cross build all Wine tests again. Find them here: http://mirzam.it.vu.nl/mingw/ -Hans

March 4, 2006

Re: DirectDraw -> WineD3D patch and Wine-0.9.9

by Olaf Leidinger

Hello! > Is this patch included in Wine-0.9.9 ? No, it isn't. AFAIK this patch modifies DirectDraw and Direct3D 7 Ciao, Olaf

March 4, 2006

Re: DirectDraw -> WineD3D patch and Wine-0.9.9

by Dimitry Naldayev

Stefan Dösinger <stefandoesinger(a)gmx.at> writes: > Hi, > I've brought my DirectDraw over WineD3D patch in a form where I want to show > it to the public for review. I've uploaded it to > http://stud4.tuwien.ac.at/~e0526822/, where it is described in detail(below > the game list). > > If there are no fundamental objections against it, I'll start sending patches > for WineD3D. The changes I'll make in small patches :) are: > > -> Header fixes, that wined3d_interface.h can be included with d3d.h > -> Adding methods to WineD3D for DirectDraw rendering > -> Adding the 2D only surface implementation to WineD3D > > When WineD3D is ready, I'll send a patch for dlls/ddraw to wine-devel and > wine-user for a broad regression testing, and when the regressions are out, > the ddraw can be replaced(From my POV, AJ has the last word of course ;) ) > Is this patch included in Wine-0.9.9 ? The summary for Wine-0.9.9 say "+ Direct3D 8 and 9 now use the same code" or this is separate thing from yours patch ? -- Dimitry

March 4, 2006

Re: [d3d8] regression between 0.9.8 and 0.9.9 in Age of Mythology

by Aric Cyr

On 3/4/06, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > Right now d3d8's SetVertexShader is disabled because d3d8 shaders don't work > using wined3d yet. Last week I experimented a bit with it and I managed to > get some simple vertex shader examples working (for instance > http://www.codesampler.com/source/dx8_vs11_shader_simple.zip and the dolphin > sample from sdk although with small issues). If I run bigger apps like > 3dmark2001 and others there are huge drawing issues. I'm not very familiar > with the shader/drawing code (and vertex shaders in general) so it is very > difficult for me to debug. You can try the patch attached to this email but > it is far from complete. If you or someone else with enough experience can > look at it, you're welcome as my time is limited. Thanks for the patch and info Roderick. I'll take a look and see if I can get things working a bit better. Using your patch and the old d3d8 code I hope to whip something together. Regards, Aric -- Aric Cyr <Aric.Cyr at gmail dot com> (http://acyr.net)

March 4, 2006

Re: [d3d8] regression between 0.9.8 and 0.9.9 in Age of Mythology

by Roderick Colenbrander

> It seems that during the porting of d3d8 to use wined3d some of there > was some breakage. Age of Mythology was working fine, but now all > vertex data is totally messed up (2D is menus and stuff is fine). It > has been this way in CVS for the past few days, when I first noticed > it. I thought it might be my local changes so I didn't report it, but > testing with the new 0.9.9 it had the same behavior (i.e. not my fault > :) > > After debugging things for a while it seems that problem lies in > vertex data with RHW set. It seems that AoM is using all pre-lit and > pre-transformed vertex data and this is not being processes properly. > I think the problem is with drawprim.c:drawStridedSlow() but I haven't > been able to figure out exactly where yet. If anyone has any ideas > (or patches!) I'd be glad to help debug. > > Regards, > Aric Right now d3d8's SetVertexShader is disabled because d3d8 shaders don't work using wined3d yet. Last week I experimented a bit with it and I managed to get some simple vertex shader examples working (for instance http://www.codesampler.com/source/dx8_vs11_shader_simple.zip and the dolphin sample from sdk although with small issues). If I run bigger apps like 3dmark2001 and others there are huge drawing issues. I'm not very familiar with the shader/drawing code (and vertex shaders in general) so it is very difficult for me to debug. You can try the patch attached to this email but it is far from complete. If you or someone else with enough experience can look at it, you're welcome as my time is limited. Regards, Roderick -- "Feel free" mit GMX FreeMail! Monat f�r Monat 10 FreeSMS inklusive! http://www.gmx.net

March 4, 2006

Re: Alexandre Julliard : configure: Use --rpath if supported when building binaries to point to

by Vitaly Lipatov

В сообщении от 2 марта 2006 07:29 Dan Kegel написал(a): > Vitaly wrote: > >Build system in ALT Linux has strict requires to use rpath and last > > changes in wine conflicts with it. > > Can you explain more about ALT Linux's build system and rpath? During package build files installs to buildroot dir not root dir. Some projects push full path to buildroot in rpath. It is forbidden. > Does it disallow all use of rpath by applications? It is forbidden to use rpath until it really needed. I do not see as rpath will be useful in rpm package. -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

March 4, 2006

Re: WRT: winetest-latest is outdated

by Saulius Krasuckas

* On Fri, 3 Mar 2006, Detlef Riekenberg wrote: > > Winetest (ELF) compiled again recently > ( http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php ), This is done by issuing "make test", IIRC. > but the crossbuilds are still missing. And that is done by issuing "make crosstest", which currently fails on my box using most recent RPMs provided by Hans Leidekker. > Is there anything that we can do for help? I started asking Hans about this in my previous letter. :)

March 4, 2006

[d3d8] regression between 0.9.8 and 0.9.9 in Age of Mythology

by Aric Cyr

It seems that during the porting of d3d8 to use wined3d some of there was some breakage. Age of Mythology was working fine, but now all vertex data is totally messed up (2D is menus and stuff is fine). It has been this way in CVS for the past few days, when I first noticed it. I thought it might be my local changes so I didn't report it, but testing with the new 0.9.9 it had the same behavior (i.e. not my fault :) After debugging things for a while it seems that problem lies in vertex data with RHW set. It seems that AoM is using all pre-lit and pre-transformed vertex data and this is not being processes properly. I think the problem is with drawprim.c:drawStridedSlow() but I haven't been able to figure out exactly where yet. If anyone has any ideas (or patches!) I'd be glad to help debug. Regards, Aric -- Aric Cyr <Aric.Cyr at gmail dot com> (http://acyr.net)

March 4, 2006

Re: Question about copyright lines

by Stefan Dösinger

> Just to add to that, you should never delete existing copyright lines, > unless you rewrite the entire file from scratch. I copied all copyright lines from a file if I took code from it to a new file. The only file "exception" is dlls/ddraw/direct3d.c in my new ddraw implementation, as I've re-written that file. If I accidentally dropped someone's copyright line, just send me a note and I'll correct it. (Marcus, Lionel, Transgaming). But I'll try to get them right. My first plan was to check the authors of every function / code segment took over(There's not really much, except of thunks and old IDirect3DLight/Material/Viewport interfaces, where the whole files were copied), but that's almost impossible as ddraw was mainly coded in 1998-2000, and Wine-CVS starts in 2001.

March 4, 2006

Re: ddraw/specular lighting

by Stefan Dösinger

Am Freitag, 3. März 2006 13:58 schrieb david.adam: > Hello, > > A lot of ddraw games recquires specular lighting to work (Syberia I, > Settlers IV, etc...). Unfortunately, specular lighting is not implemented > in ddraw. Does the change ddraw/direct 7 WINED3D resolve this problem? > Otherwise, does somebody forsee to work on that? > The implmentation of specular lighting would improve considerably the > numbers of working games under wine.... I didn't spend a lot of attention to the lights, I just forward the SetLight / GetLight calls to WineD3D, which supports D3DLIGHT_POINT, D3DLIGHT_DIRECTIONAL and D3DLIGHT_SPOT. So ATM there's no specular light support, but I'm sure that this can be added.

March 4, 2006

Re: DirectDraw -> WineD3D patch

by Stefan Dösinger

Hi, > from IWineD3DDeviceImpl_CreatePalette: > + memset(&palVersion, 0, sizeof(LOGPALETTE)); > + object->hpal = CreatePalette(&palVersion); > + memcpy(&object->palVersion, &palVersion, sizeof(LOGPALETTE)); > + /* FIXME Using the palVersion member from IWineD3DPaletteImpl for > CreatePalette + * directly causes a heap corruption. Why? In original > ddraw this was a WORD, + * which failed too. Confused ... > + */ > + object->palNumEntries = IWineD3DPaletteImpl_Size(Flags); > > That can't really work. This only creates a palette with zero entries. > You need to set palNumEntries before calling CreatePalette. > Attached patch( applies on top of yours ) should fix it( i.e. do it the > same way it is done in the current implementation). > But the text colors in AoE are still lacking :/. > Needs some more investigation ... I'll look at this, the whole palette code is a bit messy. My suspicion is that IDirectDrawPaletteImpl_SetEntries / IWineD3DPaletteImpl_SetEntries doesn't update all surfaces that use a palette. I also have to take IWineD3DDevice::SetCurrentTexturePalette, IWineD3DDevice::GetCurrentTexturePalette as well as IWineD3DDevice::SetPaletteEntries and GetPaletteEntries in account.

March 4, 2006

Re: [wininet] More wininet tests InternetQueryOption and InternetSetOption - 2

by Vijay Kiran Kamuju

Hi Detlef, I almost cleanup every thing according to the review. If i couldnt get anything, i want to talk to u on irc personally or thru mail personally. As i put that patch in 15mins after seeing thru ur mail. I really couldnt find a test app which tests that option. So i wrote a sample program, which i incorporated in the tests. Thanks, Vijay PS: ----- I want to talk 2 u personally reg this patch on irc. Yes, i am a very bad programmer. On 3/4/06, Detlef Riekenberg <wine.dev(a)web.de> wrote: > Am Freitag, den 03.03.2006, 20:50 +0530 schrieb Vijay Kiran Kamuju: > > > Changes made according to some suggestions Detlef, waiting for more > > - It took me a really long time to write the review, but you ignored > almost everything > > I suggest, that you do what i did before sending patches to wine: > > Write a small Windows-App that call the Function, what you want to test > and learn, how it works. I'm still using PellesC 3.0 in wine for this. > > > > Add More tests for InternetQueryOption > > Add Tests for InternetSetOption > > Make the Patch as small as possible, so please test only one function. > > When you compile, there must be no warnings from the compiler! > (exception atm.: -fPIC on "make crosstest" in wine) > > Hope, that helps > > -- > By By ... > ... Detlef > >

March 4, 2006

Re: PIF execution

by paul

Stephan Linz wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > is there or will be there any solution to execute .bat programs over PIF files > and avoid the error below? > > fixme:winevdm:pif_cmd .bat programs in pif files are not supported. > > The "fixme" message occurs when I try to run external programs within the > famous simulator/IDE "VMLAB" (http://www.amctools.com/download.htm) > > I believe AMC Tools knows about the problem (http://www.amctools.com/wine.htm) > but he has no solution til now. Please, understand my Email as a feature > request too. > > > > Stephan Linz > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (GNU/Linux) > > iD8DBQFEA1K+fWyCKlmj7ZARArSoAJ9sM35b/6S1LIn1yuuafVr1Vb6u6gCfeg7Z > IyWcXpTXL1gNtZH9s79rdvU= > =ya9M > -----END PGP SIGNATURE----- > > > I filed this bug http://bugs.winehq.org/show_bug.cgi?id=3638 a while back and just modified the subject. But since qemu with the kernel mod now runs a virtual PC at near native speeds it may be easier to install windows and your application in that. My application is a FPGA ide from Atmel. Paul R.

March 4, 2006

Re: Question about copyright lines

by Segin

Daniel Remenak wrote: >On 3/3/06, Segin <segin2005(a)gmail.com> wrote: > > >>Aric Cyr wrote: >> >> >> >>>Marcus Meissner <meissner <at> suse.de> writes: >>> >>> >>> >>> >>> >>>>On Fri, Mar 03, 2006 at 03:20:48PM +0100, Stefan D�singer wrote: >>>> >>>> >>>> >>>> >>>>>Hello, >>>>>At the top of every fine there's are some "Copyright <year> <name>" lines, >>>>>listing the persons who have contributed to a file, and when. Are there any >>>>>specifc rules about that? >>>>> >>>>> >>>>> >>>>> >>If you reverse the name and year, the copyright is invalid and >>unenforcable in the United States and many European states. >> >> >> > >In the United States and the United Kingdom, that is certainly not >true, and probably not in any other Berne Convention country ("Since >the Berne Convention prohibits formal requirements that affect the >"exercise and enjoyment" of the copyright, the United States changed >its law on March 1, 1989, to make the use of a copyright notice >optional."). See http://www.copyright.gov/circs/circ03.pdf and >http://www.copyright.gov/fls/fl100.html for the United States, and >http://www.patent.gov.uk/copy/indetail/copyclaim.htm and >http://www.intellectual-property.gov.uk/faq/copyright/index.htm for >the UK. > >"The use of a copyright notice is no longer required under U.S. law, >although it is often beneficial." (circ03) "Although a few countries >require that a work be marked with the international (c) mark followed >by the name of the copyright owner and year of publication, this is >not essential in most countries, including the UK." (copyclaim) "All >the Western European countries, the USA and Russia belong to the Berne >Convention which does not even require your work to be marked in any >way for automatic protection to apply." (copyright faq) > >In the U.S., "The notice for visually perceptible copies should >contain three elements. They should appear together or in close >proximity on the copies. The elements are: >1 The symbol (c) (the letter C in a circle), or the word "Copyright," >or the abbreviation "Copr."; and >2 The year of first publication...and... >3 The name of the owner of copyright in the work, or an abbreviation >by which the name can be recognized, or a generally known alternative >designation of the owner." (circ03) > >The elements just need to be in "close proximity" for the notice to be >valid...and the notice itself is not strictly necessary for copyright >protection, it's just useful for the lawyers if it gets challenged. >(e.g. "There may still be instances, such as the defense of innocent >infringement, where the question of proper notice may be a factor in >assessing damages in infringement actions...The omission of notice >does not affect the copyright protection, >and no corrective steps are required if the work was published on or >after March 1, 1989." (fl100)). > >For protection in countries which are signatories to the UCC but NOT >the Berne Convention (I don't know of any offhand), the year and name >do need to be in a specific order, AND you must also include the >C-in-a-circle symbol (c). "To guarantee protection for a copyrighted >work in all UCC member countries, the notice must consist of the >symbol (c) (the word "Copyright" or the abbreviation are not >acceptable), the year of first publication, and the name of the >copyright proprietor." (circ03) > >Disclaimer: This message does not constitute legal advice. > >--Daniel Remenak > > > Ok, but you still need to put the copyright year/holder's name in a certain order, as your last paragraph said. Just not nessessrary for most countries.

March 4, 2006

WRT: winetest-latest is outdated

by Detlef Riekenberg

Hi. The latest Winetest-Binaries are outdated ( http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/?N=D ). Winetest (ELF) compiled again recently ( http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php ), but the crossbuilds are still missing. Is there anything that we can do for help? -- By By ... ... Detlef

March 3, 2006

Re: [wininet] More wininet tests InternetQueryOption and InternetSetOption - 2

by Detlef Riekenberg

Am Freitag, den 03.03.2006, 20:50 +0530 schrieb Vijay Kiran Kamuju: > Changes made according to some suggestions Detlef, waiting for more - It took me a really long time to write the review, but you ignored almost everything I suggest, that you do what i did before sending patches to wine: Write a small Windows-App that call the Function, what you want to test and learn, how it works. I'm still using PellesC 3.0 in wine for this. > Add More tests for InternetQueryOption > Add Tests for InternetSetOption Make the Patch as small as possible, so please test only one function. When you compile, there must be no warnings from the compiler! (exception atm.: -fPIC on "make crosstest" in wine) Hope, that helps -- By By ... ... Detlef

March 3, 2006

Re: Question about copyright lines

by Daniel Remenak

On 3/3/06, Segin <segin2005(a)gmail.com> wrote: > Aric Cyr wrote: > > >Marcus Meissner <meissner <at> suse.de> writes: > > > > > > > >>On Fri, Mar 03, 2006 at 03:20:48PM +0100, Stefan Dösinger wrote: > >> > >> > >>>Hello, > >>>At the top of every fine there's are some "Copyright <year> <name>" lines, > >>>listing the persons who have contributed to a file, and when. Are there any > >>>specifc rules about that? > >>> > >>> > If you reverse the name and year, the copyright is invalid and > unenforcable in the United States and many European states. > In the United States and the United Kingdom, that is certainly not true, and probably not in any other Berne Convention country ("Since the Berne Convention prohibits formal requirements that affect the "exercise and enjoyment" of the copyright, the United States changed its law on March 1, 1989, to make the use of a copyright notice optional."). See http://www.copyright.gov/circs/circ03.pdf and http://www.copyright.gov/fls/fl100.html for the United States, and http://www.patent.gov.uk/copy/indetail/copyclaim.htm and http://www.intellectual-property.gov.uk/faq/copyright/index.htm for the UK. "The use of a copyright notice is no longer required under U.S. law, although it is often beneficial." (circ03) "Although a few countries require that a work be marked with the international (c) mark followed by the name of the copyright owner and year of publication, this is not essential in most countries, including the UK." (copyclaim) "All the Western European countries, the USA and Russia belong to the Berne Convention which does not even require your work to be marked in any way for automatic protection to apply." (copyright faq) In the U.S., "The notice for visually perceptible copies should contain three elements. They should appear together or in close proximity on the copies. The elements are: 1 The symbol (c) (the letter C in a circle), or the word "Copyright," or the abbreviation "Copr."; and 2 The year of first publication...and... 3 The name of the owner of copyright in the work, or an abbreviation by which the name can be recognized, or a generally known alternative designation of the owner." (circ03) The elements just need to be in "close proximity" for the notice to be valid...and the notice itself is not strictly necessary for copyright protection, it's just useful for the lawyers if it gets challenged. (e.g. "There may still be instances, such as the defense of innocent infringement, where the question of proper notice may be a factor in assessing damages in infringement actions...The omission of notice does not affect the copyright protection, and no corrective steps are required if the work was published on or after March 1, 1989." (fl100)). For protection in countries which are signatories to the UCC but NOT the Berne Convention (I don't know of any offhand), the year and name do need to be in a specific order, AND you must also include the C-in-a-circle symbol (c). "To guarantee protection for a copyrighted work in all UCC member countries, the notice must consist of the symbol (c) (the word "Copyright" or the abbreviation are not acceptable), the year of first publication, and the name of the copyright proprietor." (circ03) Disclaimer: This message does not constitute legal advice. --Daniel Remenak

March 3, 2006

Re: Question about copyright lines

by Segin

Aric Cyr wrote: >Marcus Meissner <meissner <at> suse.de> writes: > > > >>On Fri, Mar 03, 2006 at 03:20:48PM +0100, Stefan Dösinger wrote: >> >> >>>Hello, >>>At the top of every fine there's are some "Copyright <year> <name>" lines, >>>listing the persons who have contributed to a file, and when. Are there any >>>specifc rules about that? >>> >>> If you reverse the name and year, the copyright is invalid and unenforcable in the United States and many European states.

March 3, 2006

Re: Recently created font problem - anyone see similar?

by Joris Huizer

Dr J A Gow wrote: > Hi, > > I found that the following patch, committed to CVS on 23/02/06 > at 20:33:06 made all my Wine system fonts squashed up and unreadable, which > in turn made a mess of formatting in some dialog boxes. I backed the > patch out from a current tree and the problem went away. Anyone else see > this behaviour? I am wondering what the purpose of this patch is as > the fonts were quite OK before it was committed, and now they are > completely unreadable on this system. Any thoughts before I submit a > patch to put this back the way it was? > > John. > > The offending patch: > > Module: wine > Branch: refs/heads/master > Commit: 69a23a608eea59624b2f37ab424e0f42b3da5baf > URL: > http://source.winehq.org/git/?p=wine.git;a=commit;h=69a23a608eea59624b2f37a… > > > Author: Dmitry Timoshkov <dmitry at codeweavers.com> > Date: Thu Feb 23 20:33:06 2006 +0800 > > gdi: Use "MS Sans Serif" as default sans serif font, not Arial. > > --- > > dlls/gdi/freetype.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/gdi/freetype.c b/dlls/gdi/freetype.c > index ad0d6eb..51e92b8 100644 > --- a/dlls/gdi/freetype.c > +++ b/dlls/gdi/freetype.c > @@ -284,10 +284,10 @@ static struct list font_list = LIST_INIT > > static const WCHAR defSerif[] = {'T','i','m','e','s',' ','N','e','w',' ', > 'R','o','m','a','n','\0'}; > -static const WCHAR defSans[] = {'A','r','i','a','l','\0'}; > +static const WCHAR defSans[] = {'M','S',' ','S','a','n','s',' > ','S','e','r','i','f','\0'}; > static const WCHAR defFixed[] = {'C','o','u','r','i','e','r',' > ','N','e','w','\0'}; > > -static const WCHAR defSystem[] = {'A','r','i','a','l','\0'}; > +static const WCHAR defSystem[] = {'S','y','s','t','e','m','\0'}; > static const WCHAR SystemW[] = {'S','y','s','t','e','m','\0'}; > static const WCHAR MSSansSerifW[] = {'M','S',' ','S','a','n','s',' ', > 'S','e','r','i','f','\0'}; > > I the same font problem (I think) - In firefox, everything shows ok but file-saving dialogs (and maybe more?) render blocks instead of letters; where should I find the fonts wine used before, and where are they placed? (it seems ~/.wine/drive_c/windows/fonts is the directory that is mentioned?) thanks, Joris

March 3, 2006

Re: [wined3d] glStencilOpSeparate & glStencilFuncSeparate symbol errors

by H. Verbeet

On 03/03/06, Victor Pelt <peltco(a)mail.utexas.edu> wrote: > This patch fixes the compile error. it isn't pritty so any feedback is > appreciated This should be fixed by http://source.winehq.org/git/?p=wine.git;a=commitdiff;h=f8ed06ea3dbdf0e4578… With respect to your patch, you can't do it that way. You need to detect support for features during runtime, so basically anything containing an #ifdef is not going to work.

March 3, 2006

Wineconf 2006

by Jeremy White

Hi Folks, We've run into a bit of a snag around Wineconf 2006. Huw was trying to pull something together for this summer, but he's asked to beg off (he's going to be out with a thyroid operation for a bit; prognosis looks good, but...). Rob stepped up and volunteered to pull something together in Reading in the UK, and has been a good sport about getting it together. Sadly, the dates haven't been working out very well. Rob and I were trying to get something together for May 13th (all other dates in May don't work for one reason or another), but then internal folks here started telling us that that was way too soon. The problem with trying for June is that travel costs in June are astronomical; plane flights for example are twice the cost in June than in May. So what I'd like to ask is that people that are interested in coming to Wineconf give us a bit of feedback: http://www.winehq.org/site/wineconf/survey06 Also, I'd like to request that follow ups to this shift over to the Wineconf mailing list: http://www.winehq.org/mailman/listinfo/wineconf For those of you that don't know, Wineconf is our kinda sorta annual technical conference. It's a place where Wine developers gather to heckle Alexandre, talk about the mythical Wine 1.0, and marvel that there are 60 other people as crazy as themselves <grin>. There isn't usually any fee, although you have to bear your own travel costs. Everyone is welcome, but the focus is very technical and developer focused, so 'regular' users may feel a bit out of place. Cheers, Jeremy

March 3, 2006

Re: Regression in 0.9.9: Operation Flashpoint

by Mike McCormack

Riku Hintukainen wrote: > There seems to be a regression with Operation Flashpoint in wine-0.9.9, > possibly because of the dx8->wine3d move. Should I file a bug, or wait > if it gets fixed? Please log a bug instead of posting debugger backtraces to wine-devel. thanks, Mike

March 3, 2006

Re: Question about copyright lines

by Aric Cyr

Marcus Meissner <meissner <at> suse.de> writes: > > On Fri, Mar 03, 2006 at 03:20:48PM +0100, Stefan Dösinger wrote: > > Hello, > > At the top of every fine there's are some "Copyright <year> <name>" lines, > > listing the persons who have contributed to a file, and when. Are there any > > specifc rules about that? > > If you make a significant contribution, just add yourself there. > > (significant in my eyes -> new feature, code rewrite or similar) Just to add to that, you should never delete existing copyright lines, unless you rewrite the entire file from scratch. Stefan, you might want to review (if you haven't already) http://winehq.com/site/sending_patches before submitting many more patches. It might save you (and AJ) a lot of wasted time and rejections. Regards, Aric

March 3, 2006

Re: EaseReader gives fixme:amstream:IAMMultiMediaStreamImpl_Initialize

by Rob Shearman

Peter Åstrand wrote: > On Thu, 26 Jan 2006, Peter Åstrand wrote: > >> Hi. I'm trying to get the EaseReader application >> (http://www.dolphinaudiopublishing.com/products/EaseReader/) running >> in Wine. By using the native oleacc, oleaut32 and rpcrt4, it's now >> actually possible to start the application. The "self voicing" mode >> also works: The application "speaks", for example when hovering above >> menu choices. Listening to the actual DAISY book does not work, >> however. I get: >> >> fixme:imm:ImmGetContext (0x10136): stub >> fixme:imm:ImmGetContext (0x10136): stub >> fixme:amstream:IAMMultiMediaStreamImpl_QueryInterface >> (0x7a4fdc50/0x7a4fdc50)->({bebe595c-9a6f-11d0-8fde-00c04fd9189d},0x7fc6e968) >> >> fixme:amstream:IAMMultiMediaStreamImpl_Initialize >> (0x7a4fdc50/0x7a4fdc50)->(0,1,(nil)) partial stub! >> fixme:amstream:IAMMultiMediaStreamImpl_AddMediaStream >> (0x7a4fdc50/0x7a4fdc50)->((nil),0x4b0d3200,0,(nil)) partial stub! >> fixme:amstream:IAMMultiMediaStreamImpl_OpenFile >> (0x7a4fdc50/0x7a4fdc50)->(L"c:\\program files\\easereader >> demo\\help\\22_highlig.mp3",8) stub! > > > > It seems like the main problem is the IAMMultiMediaStreamImpl_OpenFile > stub. I've tried a quick-n-dirty hack: Just calling ShellExecute from > IAMMultiMediaStreamImpl_OpenFile. See the patch below. After > installing Winamp, this actually works (but stop/seek etc doesn't > work, of course). > > So: Now I'm wondering: How difficult would it be to properly implement > IAMMultiMediaStreamImpl_OpenFile? Most of the base functionality is there. IAMMultiMediaStreamImpl_OpenFile is just a helper method. This is roughly what it should do: CoCreateInstance with IFileSourceFilter on CLSID_AsyncReader. Call IFileSourceFilter_Load. Get the output pin and stash it in This. Call IGraphBuilder_AddSourceFilter. Then IAMMultiMediaStreamImpl_Render should do the following: Call IGraphBuilder_Render using the pin previously stashed away. Care needs to be taken in both cases to ensure the IGraphBuilder object has been set and in the second case the pin as well. Hope this helps, Rob

March 3, 2006

Re: COMCTL32: Fix some gcc 4.1 warnings caused by windowsx.h macros.

by Rob Shearman

Mike McCormack wrote: > ChangeLog: > Fix some gcc 4.1 warnings caused by windowsx.h macros. I see little benefit in this warning being enabled. IMHO, it would be better to see one patch that turns this warning off than ten patches that obfuscate the code Rob

March 3, 2006

Re: [wininet] More wininet tests InternetQueryOption and InternetSetOption - 2

by Vijay Kiran Kamuju

I missed the patch, here it is Changes made according to some suggestions Detlef, waiting for more Changelog ---------------- Add More tests for InternetQueryOption Add Tests for InternetSetOption

March 3, 2006

[wininet] More wininet tests InternetQueryOption and InternetSetOption - 2

by Vijay Kiran Kamuju

Changes made according to some suggestions Detlef, waiting for more Changelog ---------------- Add More tests for InternetQueryOption Add Tests for InternetSetOption

March 3, 2006

make crosstest

by Saulius Krasuckas

I am getting error with it: make[3]: Entering directory `/mnt/antras/usr/src/wine-git/dlls/advapi32/tests' i386-mingw32-gcc -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -gstabs+ -Wdeclaration-after-statement -Wpointer-arith -g -O2 -o crypt.cross.o crypt.c crypt.c:1: warning: -fPIC ignored for target (all code is position independent) ... i386-mingw32-gcc -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -gstabs+ -Wdeclaration-after-statement -Wpointer-arith -g -O2 -o testlist.cross.o testlist.c testlist.c:1: warning: -fPIC ignored for target (all code is position independent) i386-mingw32-gcc crypt.cross.o crypt_lmhash.cross.o crypt_md4.cross.o crypt_md5.cross.o crypt_sha.cross.o registry.cross.o security.cross.o testlist.cross.o -o advapi32_crosstest.exe -ladvapi32 -lkernel32 /usr/local/lib/gcc/i386-mingw32/3.4.4/libgcc.a: could not read symbols: Archive has no index; run ranlib to add one collect2: ld returned 1 exit status make[3]: *** [advapi32_crosstest.exe] Error 1 make[3]: Leaving directory `/mnt/antras/usr/src/wine-git/dlls/advapi32/tests' How this should be fixed? Here is a list of packages I use: $ rpm -qa | grep mingw mingw-runtime-3.7-16hl mingw-w32api-3.5-16hl mingw-binutils-2.16.91-9hl mingw-gcc-core-3.4.4-12hl

March 3, 2006

Re: DirectDraw -> WineD3D patch

by Peter Beutner

Stefan Dösinger schrieb: > Hi, > I've brought my DirectDraw over WineD3D patch in a form where I want to show > it to the public for review. I've uploaded it to > http://stud4.tuwien.ac.at/~e0526822/, where it is described in detail(below > the game list). nice work :). I just looked a bit into the palette issue( aka lost text color etc): from IWineD3DDeviceImpl_CreatePalette: + memset(&palVersion, 0, sizeof(LOGPALETTE)); + object->hpal = CreatePalette(&palVersion); + memcpy(&object->palVersion, &palVersion, sizeof(LOGPALETTE)); + /* FIXME Using the palVersion member from IWineD3DPaletteImpl for CreatePalette + * directly causes a heap corruption. Why? In original ddraw this was a WORD, + * which failed too. Confused ... + */ + object->palNumEntries = IWineD3DPaletteImpl_Size(Flags); That can't really work. This only creates a palette with zero entries. You need to set palNumEntries before calling CreatePalette. Attached patch( applies on top of yours ) should fix it( i.e. do it the same way it is done in the current implementation). But the text colors in AoE are still lacking :/. Needs some more investigation ... Peter b0a1e06bddc2bbc17bf7b5d991236a4cd76f0d1a diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c index f224c2c..9b0e468 100644 --- a/dlls/wined3d/device.c +++ b/dlls/wined3d/device.c @@ -1660,12 +1660,11 @@ HRESULT WINAPI IWineD3DDeviceImpl_Create HRESULT WINAPI IWineD3DDeviceImpl_CreatePalette(IWineD3DDevice *iface, DWORD Flags, PALETTEENTRY *PalEnt, IWineD3DPalette **Palette, IUnknown *Parent) { IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *) iface; IWineD3DPaletteImpl *object; - LOGPALETTE palVersion; HRESULT hr; FIXME("(%p)->(%lx, %p, %p, %p)\n", This, Flags, PalEnt, Palette, Parent); /* Create the new object */ - object = HeapAlloc(GetProcessHeap(), 0, sizeof(IWineD3DPaletteImpl)); + object = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(IWineD3DPaletteImpl)); if(!object) { ERR("Out of memory when allocating memory for a IWineD3DPalette implementation\n"); return DDERR_OUTOFVIDEOMEMORY; @@ -1676,15 +1675,14 @@ HRESULT WINAPI IWineD3DDeviceImpl_Create object->Flags = Flags; object->parent = Parent; object->wineD3DDevice = This; - - memset(&palVersion, 0, sizeof(LOGPALETTE)); - object->hpal = CreatePalette(&palVersion); - memcpy(&object->palVersion, &palVersion, sizeof(LOGPALETTE)); - /* FIXME Using the palVersion member from IWineD3DPaletteImpl for CreatePalette - * directly causes a heap corruption. Why? In original ddraw this was a WORD, - * which failed too. Confused ... - */ object->palNumEntries = IWineD3DPaletteImpl_Size(Flags); + + object->hpal = CreatePalette((const LOGPALETTE*)&(object->palVersion)); + + if(!object->hpal) { + HeapFree( GetProcessHeap(), 0, object); + return DDERR_OUTOFMEMORY; /* only reason why CreatePalette could have failed */ + } hr = IWineD3DPalette_SetEntries((IWineD3DPalette *) object, 0, 0, IWineD3DPaletteImpl_Size(Flags), PalEnt); if(FAILED(hr)) { diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h index 86b10bb..626154a 100644 --- a/dlls/wined3d/wined3d_private.h +++ b/dlls/wined3d/wined3d_private.h @@ -1309,9 +1309,9 @@ struct IWineD3DPaletteImpl { /* IWineD3DPalette */ HPALETTE hpal; - LOGPALETTE palVersion; - WORD palNumEntries; - PALETTEENTRY palents[256]; + WORD palVersion; /*| */ + WORD palNumEntries; /*| LOGPALETTE */ + PALETTEENTRY palents[256]; /*| */ /* This is to store the palette in 'screen format' */ int screen_palents[256]; DWORD Flags;

March 3, 2006

Re: make crosstest

by Hans Leidekker

On Friday 03 March 2006 16:14, Saulius Krasuckas wrote: > -lkernel32 /usr/local/lib/gcc/i386-mingw32/3.4.4/libgcc.a: could not read > symbols: Archive has no index; run ranlib to add one Run this command: $ i386-mingw32-ranlib /usr/local/lib/gcc/i386-mingw32/3.4.4/libgcc.a There's something wrong with package building on recent Fedora Core releases but I haven't found the cause of it yet. -Hans

March 3, 2006

[mlang.dll] DllCanUnloadNow

by Christian Gmeiner

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This patch + implements LockServer + implements DllCanUnloadNow + add some needed calls to LockModule() & UnlockModule() If it didn't get into cvs i want a mail with the cause. - -- Christian Gmeiner - student of computer science http://dxr3plugin.sf.net http://itb04.ath.cx http://javamill.ath.cx -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFECFi9Dwe2AbwGBA8RApDQAJ4nCMpbbOeWBTi/x1xV36MrBaKoNgCfRTG8 54cyjapBkvdO9DUkNP41k3k= =HK0l -----END PGP SIGNATURE----- Index: dlls/mlang/mlang.c =================================================================== RCS file: /home/wine/wine/dlls/mlang/mlang.c,v retrieving revision 1.25 diff -u -r1.25 mlang.c --- dlls/mlang/mlang.c 6 Dec 2005 10:39:43 -0000 1.25 +++ dlls/mlang/mlang.c 3 Mar 2006 08:47:38 -0000 @@ -453,6 +453,21 @@ static void fill_cp_info(const struct mlang_data *ml_data, UINT index, MIMECPINFO *mime_cp_info); +static LONG dll_count; + +/* + * Dll lifetime tracking declaration + */ +static void LockModule(void) +{ + InterlockedIncrement(&dll_count); +} + +static void UnlockModule(void) +{ + InterlockedDecrement(&dll_count); +} + BOOL WINAPI DllMain(HINSTANCE hInstDLL, DWORD fdwReason, LPVOID lpv) { switch(fdwReason) { @@ -709,6 +724,7 @@ { TRACE("Destroying %p\n", This); HeapFree(GetProcessHeap(), 0, This); + UnlockModule(); } return ref; @@ -735,8 +751,11 @@ static HRESULT WINAPI MLANGCF_LockServer(LPCLASSFACTORY iface,BOOL dolock) { - IClassFactoryImpl *This = (IClassFactoryImpl *)iface; - FIXME("(%p)->(%d),stub!\n",This,dolock); + if (dolock) + LockModule(); + else + UnlockModule(); + return S_OK; } @@ -2281,6 +2300,9 @@ mlang->ref = 1; *ppObj = (LPVOID) mlang; TRACE("returning %p\n", mlang); + + LockModule(); + return S_OK; } @@ -2288,8 +2310,7 @@ HRESULT WINAPI DllCanUnloadNow(void) { - FIXME("\n"); - return S_FALSE; + return dll_count == 0 ? S_OK : S_FALSE; } HRESULT WINAPI GetGlobalFontLinkObject(void)

March 3, 2006

Re: Question about copyright lines

by Marcus Meissner

On Fri, Mar 03, 2006 at 03:20:48PM +0100, Stefan Dösinger wrote: > Hello, > At the top of every fine there's are some "Copyright <year> <name>" lines, > listing the persons who have contributed to a file, and when. Are there any > specifc rules about that? If you make a significant contribution, just add yourself there. (significant in my eyes -> new feature, code rewrite or similar) Ciao, Marcus

March 3, 2006

Re: WINECFG: Eliminate some gcc 4.1 warnings caused by casts in macros.

by Francois Gouget

On Fri, 3 Mar 2006, Mike McCormack wrote: [...] > They would prefer that we use statement expressions, which are gcc specific, > in our macros. Something like: Thanks for the explanation. Sure, having an #ifdef/#else/#endif for each macro is way too painful. But what about the following: +#ifndef WINE_CAST +# if __GNUC__ +# define WINE_CAST(ctype, val) ({ctype r=(ctype)(val);r;}) +# else +# define WINE_CAST(ctype, val) ((ctype)(val)) +# endif +#endif + + #define Header_SetImageList(hwnd,himl) \ - (HIMAGELIST)SNDMSGA((hwnd),HDM_SETIMAGELIST,0,(LPARAM)himl) + WINE_CAST(HIMAGELIST, SNDMSGA((hwnd),HDM_SETIMAGELIST,0,(LPARAM)himl)) + This pre-processes to code that uses the statement expression on gcc compilers and to the regular cast for others. So there should be no warning in either case (I couldn't check with gcc 4.1 but this preprocesses to the expected form). I also checked with gcc 2.95 and it compiles fine and without warning there which should be enough backwards compatibility for everyone (otherwise we can go further and check the GCC version). Of course in a real patch the WINE_CAST macro would be declared somewhere in windef.h, and we'd still have to change all the macros that cast a function result. But that seems quite feasible and not too ugly and I would be willing to submit such a patch. We may also want to find a better name. WINE_MACRO_CAST? WINE_MCAST? __MACRO_CAST? WINE_CAST_RESULT? Should I send such a patch? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ In a world without fences who needs Gates?

March 3, 2006

Question about copyright lines

by Stefan Dösinger

Hello, At the top of every fine there's are some "Copyright <year> <name>" lines, listing the persons who have contributed to a file, and when. Are there any specifc rules about that? Thanks, Stefan

March 3, 2006

ddraw/specular lighting

by david.adam

Hello, A lot of ddraw games recquires specular lighting to work (Syberia I, Settlers IV, etc...). Unfortunately, specular lighting is not implemented in ddraw. Does the change ddraw/direct 7 WINED3D resolve this problem? Otherwise, does somebody forsee to work on that? The implmentation of specular lighting would improve considerably the numbers of working games under wine.... Best regards, Joaopa

March 3, 2006

Re: WSH, WMI scripts

by Vassilis Virvilis

Sreenivas Tatti wrote: > Hi Mike, > You could have understood my requirement. I am looking at WINE to get > this thing done. If not supported in WINE, then what other possible way, > I can achieve this. I have to do some windows registry modifications and > start/stop/query about windows services from a Linux box. > I have to remotely install my agent on a windows box. That is my goal. > Thanks in anticipation. > With regards, > Sreenivas It is absolutely unrelated to wine and completely off topic but since you asked why don't you install cygwin to the remote machines and do the staff you want to do with ssh and some local scripting. I mean if you can do it from a dos prompt, ok a cmd prompt, then you have to be able to do it with a ssh connection remotely and in a secure manner too. http://pigtail.net/LRP/printsrv/cygwin-sshd.html .bill

March 3, 2006

RE: WSH, WMI scripts

by Sreenivas Tatti

Hi Mike, You could have understood my requirement. I am looking at WINE to get this thing done. If not supported in WINE, then what other possible way, I can achieve this. I have to do some windows registry modifications and start/stop/query about windows services from a Linux box. I have to remotely install my agent on a windows box. That is my goal. Thanks in anticipation. With regards, Sreenivas -----Original Message----- From: Mike McCormack [mailto:mike(a)codeweavers.com] Sent: Friday, March 03, 2006 4:28 PM To: Sreenivas Tatti Cc: wine-devel(a)winehq.org Subject: Re: WSH, WMI scripts Sreenivas Tatti wrote: > I have a requirement that, I should run WSH and WMI scripts in Linux > environment in order to do some registry changes on a remote machine and > start/stop/query windows services on a remote machine. It's unlikely to work, as DCOM (OLE over the network) does not work, and Wine currently has no builtin support for WSH/WMI. Mike

March 3, 2006

Re: WSH, WMI scripts

by Mike McCormack

Sreenivas Tatti wrote: > I have a requirement that, I should run WSH and WMI scripts in Linux > environment in order to do some registry changes on a remote machine and > start/stop/query windows services on a remote machine. It's unlikely to work, as DCOM (OLE over the network) does not work, and Wine currently has no builtin support for WSH/WMI. Mike

March 3, 2006

WSH, WMI scripts

by Sreenivas Tatti

Hi, I have a requirement that, I should run WSH and WMI scripts in Linux environment in order to do some registry changes on a remote machine and start/stop/query windows services on a remote machine. Can I use WINE for this purpose. Thanks in anticipation. With regards, Sreenivas T.

March 3, 2006

Re: COMCTL32: Fix some gcc 4.1 warnings caused by windowsx.h macros.

by Thomas Weidenmueller

Rob Shearman wrote: > IMHO, it would be better to see one patch that turns this warning off > than ten patches that obfuscate the code I absolutely appreciate this warning, IMO it's not code obfuscation. - Thomas

March 3, 2006

Re: COMCTL32: Fix some gcc 4.1 warnings caused by windowsx.h macros.

by Mike McCormack

Rob Shearman wrote: > I see little benefit in this warning being enabled. > > IMHO, it would be better to see one patch that turns this warning off > than ten patches that obfuscate the code Yesterday, Alexandre fixed 4 problems that showed using this warning: http://source.winehq.org/git/?p=wine.git;a=commit;h=c9cc7e33ffaaf9b359d6bcc… They showed up with gcc 4.1, but I didn't notice them because of the warnings from function casts. It's probably possible to turn it off using -Wno-unused-value, but there are real problems that will be caught with it. Consider part of Alexandre's patch yesterday: +++ b/dlls/ole32/ole2.c @@ -801,7 +801,7 @@ static HRESULT WINAPI EnumOLEVERB_Next( rgelt->grfAttribs = atolW(pwszAttribs); if (pceltFetched) - *pceltFetched++; + (*pceltFetched)++; This->index++; } return hr; Getting rid of the relative small number of macro uses that cause the warning doesn't seem to difficult, or to obfuscate the code too much to me. Mike

March 3, 2006

Regression in 0.9.9: Operation Flashpoint

by Riku Hintukainen

There seems to be a regression with Operation Flashpoint in wine-0.9.9, possibly because of the dx8->wine3d move. Should I file a bug, or wait if it gets fixed? Please cc since I' m not subscribed. $ wine ./FLASHPOINTRESISTANCE.EXE wine: Unhandled page fault on read access to 0x00000fd1 at address 0xfd1 (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x00000fd1 in 32-bit code (0x0 0000fd1). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:00000fd1 ESP:7fbcf1dc EBP:7fbcf298 EFLAGS:00210206( - 00 - RIP1) EAX:69c2c330 EBX:7bf87af8 ECX:7bf87af8 EDX:7fd5b3e0 ESI:7fd66830 EDI:00001e00 Stack dump: 0x7fbcf1dc: 7bf616a3 00000405 00001e00 00001e00 0x7fbcf1ec: 00001e00 00000000 7fd5b408 00000003 0x7fbcf1fc: 3f800000 7bf88620 00000000 00000000 0x7fbcf20c: 00000000 00000000 00000000 00001e00 0x7fbcf21c: 00001e00 00001e00 00000000 00001e00 0x7fbcf22c: 00001e00 00001e00 00001e00 00001e00 Backtrace: =>1 0x00000fd1 (0x00000fd1) 2 0x7bf73840 IWineD3DStateBlockImpl_InitStartupStateBlock+0xd90 in wined3d (0x 7bf73840) 3 0x7bf698f9 IWineD3DImpl_CreateDevice+0x229 in wined3d (0x7bf698f9) 4 0x7c23b958 IDirect3D8Impl_CreateDevice+0x108 in d3d8 (0x7c23b958) 5 0x004f3134 in flashpointresistance (+0xf3134) (0x004f3134) 0x00000fd1: addb %al,0x0(%eax) Modules: Module Address Debug info Name (79 modules) PE 0x00400000-007e1000 Export flashpointresistance PE 0x10000000-10032000 Deferred ifc22 PE 0x65f00000-65fc2000 Deferred ole32 ELF 0x69e59000-69e90000 Deferred dsound<elf> \-PE 0x69e70000-69e90000 \ dsound PE 0x69ea0000-69ef3000 Deferred rpcrt4 ELF 0x7bf00000-7bf03000 Deferred <wine-loader> ELF 0x7bf3c000-7bf89000 Export wined3d<elf> \-PE 0x7bf50000-7bf89000 \ wined3d ELF 0x7bf89000-7c000000 Deferred libglu.so.1 ELF 0x7c220000-7c240000 Export d3d8<elf> \-PE 0x7c230000-7c240000 \ d3d8 ELF 0x7e9fb000-7ea10000 Deferred midimap<elf> \-PE 0x7ea00000-7ea10000 \ midimap ELF 0x7eb2d000-7eb4e000 Deferred msacm32<elf> \-PE 0x7eb30000-7eb4e000 \ msacm32 ELF 0x7eb4e000-7ebe4000 Deferred libasound.so.2 ELF 0x7ebe5000-7ebfc000 Deferred msacm<elf> \-PE 0x7ebf0000-7ebfc000 \ msacm ELF 0x7ebfc000-7ec1d000 Deferred winealsa<elf> \-PE 0x7ec10000-7ec1d000 \ winealsa ELF 0x7ec40000-7ec5a000 Deferred imm32<elf> \-PE 0x7ec50000-7ec5a000 \ imm32 ELF 0x7ec5a000-7ec61000 Deferred libxrender.so.1 ELF 0x7ec62000-7ec79000 Deferred ximcp.so.2 ELF 0x7f3da000-7f562000 Deferred r200_dri.so ELF 0x7f562000-7f5be000 Deferred libgl.so.1 ELF 0x7f5be000-7f66c000 Deferred libx11.so.6 ELF 0x7f66c000-7f677000 Deferred libxext.so.6 ELF 0x7f677000-7f67b000 Deferred libxxf86vm.so.1 ELF 0x7f67b000-7f68f000 Deferred libice.so.6 ELF 0x7f68f000-7f700000 Deferred winex11<elf> \-PE 0x7f6a0000-7f700000 \ winex11 ELF 0x7f700000-7f71c000 Deferred libexpat.so.0 ELF 0x7f71c000-7f73e000 Deferred libfontconfig.so.1 ELF 0x7f73e000-7f7a0000 Deferred libfreetype.so.6 ELF 0x7f7a1000-7f7aa000 Deferred libgcc_s.so.1 ELF 0x7f7ad000-7f7b5000 Deferred libxcursor.so.1.0.2 ELF 0x7f7b5000-7f7b8000 Deferred libxrandr.so.2 ELF 0x7f7b8000-7f7eb000 Deferred dinput<elf> \-PE 0x7f7d0000-7f7eb000 \ dinput ELF 0x7f7eb000-7f7ff000 Deferred dinput8<elf> \-PE 0x7f7f0000-7f7ff000 \ dinput8 ELF 0x7f7ff000-7f81b000 Deferred iphlpapi<elf> \-PE 0x7f810000-7f81b000 \ iphlpapi ELF 0x7f81b000-7f840000 Deferred ws2_32<elf> \-PE 0x7f820000-7f840000 \ ws2_32 ELF 0x7f840000-7f859000 Deferred wsock32<elf> \-PE 0x7f850000-7f859000 \ wsock32 ELF 0x7f859000-7f86d000 Deferred lz32<elf> \-PE 0x7f860000-7f86d000 \ lz32 ELF 0x7f86d000-7f884000 Deferred version<elf> \-PE 0x7f870000-7f884000 \ version ELF 0x7f884000-7f8bb000 Deferred advapi32<elf> \-PE 0x7f890000-7f8bb000 \ advapi32 ELF 0x7f8bb000-7f93a000 Deferred gdi32<elf> \-PE 0x7f8d0000-7f93a000 \ gdi32 ELF 0x7f93a000-7fa47000 Deferred user32<elf> \-PE 0x7f950000-7fa47000 \ user32 ELF 0x7fa47000-7fac0000 Deferred winmm<elf> \-PE 0x7fa50000-7fac0000 \ winmm ELF 0x7fc05000-7fcf0000 Deferred kernel32<elf> \-PE 0x7fc20000-7fcf0000 \ kernel32 ELF 0x7fe00000-7fe02000 Deferred xlcutf8load.so.2 ELF 0x7fe02000-7fe07000 Deferred libxxf86dga.so.1 ELF 0x7fe07000-7fe0f000 Deferred libsm.so.6 ELF 0x7fe0f000-7fe19000 Deferred libnss_files.so.2 ELF 0x7fe19000-7fe23000 Deferred libnss_nis.so.2 ELF 0x7fe23000-7fe38000 Deferred libnsl.so.1 ELF 0x7fe38000-7fe40000 Deferred libnss_compat.so.2 ELF 0x7fe41000-7fe50000 Deferred libz.so.1 ELF 0x7fe5c000-7fe7f000 Deferred libm.so.6 ELF 0x7fe7f000-7ff75000 Deferred libwine_unicode.so.1 ELF 0x7ff75000-7ffe0000 Deferred ntdll<elf> \-PE 0x7ff90000-7ffe0000 \ ntdll ELF 0xb7dd4000-b7dd8000 Deferred libdl.so.2 ELF 0xb7dd8000-b7ef0000 Deferred libc.so.6 ELF 0xb7f5b000-b7f75000 Deferred libwine.so.1 ELF 0xb7f75000-b7f8c000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 00000008 (D) C:\Program Files\Codemasters\Operation Flashpoint\FLASHPOINTRESISTA NCE.EXE 0000000b 15 0000000a 0 00000009 0 <==

March 3, 2006

Re: WINECFG: Eliminate some gcc 4.1 warnings caused by casts in macros.

by Mike McCormack

Francois Gouget wrote: > What are these warnings? What is causing them? Sorry, should have posted an explanation. The warning comes from code like this: char foo(x); #define bar(x) (int) foo(x) So for the example you gave from my patch: #define Header_SetImageList(hwnd,himl) \ (HIMAGELIST)SNDMSGA((hwnd),HDM_SETIMAGELIST,0,(LPARAM)himl) We get a "computed value is not used" warning when we use Header_SetImageList without assigning the returned value to anything. I reported this in the gcc bugzilla some time ago, but the gcc team claim that this is a feature, not a bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25955 They would prefer that we use statement expressions, which are gcc specific, in our macros. Something like: #define Header_SetImageList(hwnd,himl) \ ({ HIMAGELIST r; \ r = (HIMAGELIST)SNDMSGA((hwnd),HDM_SETIMAGELIST,0,(LPARAM)himl); \ r; }) Alexandre suggested that we use inline functions to solve this problem, however this requires including winuser.h when including windowsx.h, and that we choose SendMessageA or SendMessageW for the macros that deal with strings. Conceivably we could use: #ifdef HAVE_BORKED_GCC_COMPUTED_VALUE_NOT_USED_WARNING #define Header_SetImageList(hwnd,himl) \ ({ HIMAGELIST r; \ r = (HIMAGELIST)SNDMSGA((hwnd),HDM_SETIMAGELIST,0,(LPARAM)himl); \ r; }) #else #define Header_SetImageList(hwnd,himl) \ (HIMAGELIST)SNDMSGA((hwnd),HDM_SETIMAGELIST,0,(LPARAM)himl) #endif This requires use -DHAVE_BORKED_GCC_COMPUTED_VALUE_NOT_USED_WARNING when compiling Wine code and Winelib apps. > Do we really have to give up on the macros and use SendMessage directly > to avoid the warnings? If we do, then I would say this means the macros > are broken because it means Winelib users will get the same problem we > do and will have to modify their code or live with gobs of warnings. Yes, and it will be broken for WineLib. I quote Alexandre from IRC: <julliard> mike_m: hmm right, that's a PITA <mike_m> truely <julliard> i'd say get rid of windowsx.h then I agree this is not an ideal solution... let me know if you have any better ideas. Mike

March 3, 2006

Re: WINECFG: Eliminate some gcc 4.1 warnings caused by casts in macros.

by Francois Gouget

On Fri, 3 Mar 2006, Mike McCormack wrote: > ChangeLog: > Eliminate some gcc 4.1 warnings caused by casts in macros. What are these warnings? What is causing them? > - TreeView_SetImageList(tree, hImageList, TVSIL_STATE); > + SendMessageW( tree, LVM_SETIMAGELIST, TVSIL_STATE, (LPARAM)hImageList ); Do we really have to give up on the macros and use SendMessage directly to avoid the warnings? If we do, then I would say this means the macros are broken because it means Winelib users will get the same problem we do and will have to modify their code or live with gobs of warnings. So, is there a way to fix the macros? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.

March 3, 2006

Re: Launch native Linux apps?

by Stefan Dösinger

> Is it possible to set Wine up so that it can launch native Linux apps? For > example, set your native copy of Acrobat Reader to be associated to PDF > extensions in Wine, or even use the Linux plugin while using a browser? I have done this with Kmail and others. You have to add a few registry keys in HKCL and HKLM. Basically, you can launch any Linux app from wine by it's full path and pass command line arguments. There's of course the problem of converting Windows paths to Unix paths. At http://www.winehq.com/site/fun_projects my Kmail registry entries are described. For examples how to use Open Office, you have to google. I don't think that executing a Linux Plugin in a Win32 browser is possible, but cossover allows you to do the reverse. Stefan

March 3, 2006

Re: [wininet] More wininet tests InternetQueryOption and InternetSetOption - Corrected

by Vijay Kiran Kamuju

This is a detailed reply to ur mail. On 2/27/06, Detlef Riekenberg <wine.dev(a)web.de> wrote: > Am Mittwoch, den 22.02.2006, 23:13 +0530 schrieb Vijay Kiran Kamuju: > > Any thing wrong with this patch. > > Any Comments (expecting a lot) > > > > As you asked me, i took a look on this Patch. > > For my winspool-Patches, i was told to check the documented behavior and > only check undocumented behavior, when an Application relies on this > undocumented effect. > It's of course a good Idea, to print as much Informations as possible, > when a test Failed (err in your case). > > When i add a new Test, I add a trace after every tested API-Call, > compile the Test on linux with the mingw-crosstools as Windows-Binary > (make -C dlls/your_dllname_here/tests crosstest) and run that Binary on > all Windows-Versions that I have. After an update to the Parameter and > the Text for ok(), I do the tests on Windows again. > Then I test that Binary on wine. When there are no Failures left, i > remove the traces, compile again, test again, and after a final test in > wine with (make -C dlls/your_dllname_here/tests test), the diff is > created. > > > - Your Test did not apply here, so i merged the patch by cut & paste. > (malformed Patch) > > - I get 5 Failures on wine. (make -C dlls/wininet/tests test) > > > + hinet = InternetOpenA(useragent,INTERNET_OPEN_TYPE_DIRECT,NULL,NULL, > 0); > + ok((hinet != 0x0),"InternetOpen Failed\n"); > > - Please use (hinet != NULL) here, or is MSDN wrong (value / pointer)? > > - Does the other tests work, when InternetOpenA failed, or is it more > useful to return from the test here? > Just copied from http tests > > + SetLastError(0xdeadbeef); > + retval=InternetSetOptionA(hinet,INTERNET_OPTION_USER_AGENT, &inagent, > sizeof(inagent)); > + err=GetLastError(); > + ok(retval == 1,"Got wrong return value %d\n",retval); > + ok(err == 0xdeadbeef, "Got wrong error code %ld\n",err); > > For the Example above, my Idea is: > ok(retval, "returned %d with %ld (expected '!= 0')\n", retval, err); > Well due our partial implementation, we have not correctly implemented returning all the error states. Hence it requires seperate tests for error messages. > + len=0; > + SetLastError(0xdeadbeef); > + buffer=HeapAlloc(GetProcessHeap(),0,len); > + retval = > InternetQueryOptionW(hinet,INTERNET_OPTION_USER_AGENT,buffer,&len); > + err=GetLastError(); > + ok(buffer != NULL,"Output Buffer Should Not be Set"); > + todo_wine ok(len == 38,"Got wrong user agent length %ld instead of %d > \n",len,38); > + > > - You use HeapAlloc with a len of 0 and than the test "buffer != NULL": > This is a Test for HeapAlloc How to create a buffer with zero length does simple buffer = NULL suffice, i dont think so > - InternetQueryOptionW is not implemented in win95/98/me Will put a check for that once the base gets thru. > - Please avoid fixed numbers. When someone changes the Agent-Name, > the complete Test must be reworked. In most other tests we use basenumbers as well, i dont prefer using other functions in it. If there is a bug in their implementation, this test get affected. Each test case should be independent and atomic > > > For the tests of the W-Functions: > I was told, that i should test the Unicode-Functions only, when there > are other results as from the ANSI-Version. Since our ANSI - > Implementations should call the Unicode-Function, the ANSI-Test > validates both Implementations. > (Yes, i knew that the Implementation in wine is sometimes wrong: we have > Crosscalls W->A and some Unicode-Functions are stubs while the > ANSI-Versions are implemented) I am testing the both Unicode and Ansi Versions. If u are concerned about SetOptionW, i have made tests for this because our implementation for it is flawed. > > > + WideCharToMultiByte(CP_ACP,0,(WCHAR *)buffer,-1,tmpbuffer,len,0,0); > + todo_wine ok(!strcmp(inagent,tmpbuffer),"Got wrong user agent string % > s instead of %s\n",tmpbuffer,inagent); > > - This Test failed on Windows XP > Have to look into this. How to Compare char string and wchar string. > > + retval = InternetSetOptionW(NULL,INTERNET_OPTION_USER_AGENT, > &inpbuffer, sizeof(inpbuffer)); > You use ANSI-Parameter for an UNICODE-Function. > This is a test for bad programming ;) > > You can take a look at the Tests for winspool/GetPrinterDriverDirectory > - A test with the documented use to get the required size for the Buffer > (buffersize=0) > - A test with documented use (all Options valid) > - Buffer is larger (must succeed) > - Buffer is to small (must fail with a specific ERROR_*) > (Other Functions may truncate the returned Data) > - without a buffer (NULL), but with the correct buffersize. > This is for testing the API, when the app was unable to allocate > the Buffer, but did not check the Result of the allocation. > I will look into them > > > So there are some Reasons, why the test is not Ready yet. > > I read the Docs about InternetQueryOption on MSDN and IMHO there are so > many Documented values for dwOption, that I suggest to start with a > testing-table and fill it with all of our implemented Options for > InternetQueryOption / InternetSetOption. > We have then a complete Test of our wininet-Implementation with only a > small amount of code. The Table can grow very easy, when Applications > use Options that we need to implement. I wrongly chose to implement the INTERNET_OPTION_USER_AGENT, hence i am writing the tests for those. So that my implementation gets thru. I have tests for other options also in my mind. > > > -- > By By ... > ... Detlef > > Cheers, Vijay

March 3, 2006

Re: [wininet] More wininet tests InternetQueryOption and InternetSetOption - Corrected

by Vijay Kiran Kamuju

Thanks a lot on reviewing my patch, I have been busy lately. So i could not reply u soon enough. I will make some changes and send it to u for review. Thanks, Vijay On 2/27/06, Detlef Riekenberg <wine.dev(a)web.de> wrote: > Am Mittwoch, den 22.02.2006, 23:13 +0530 schrieb Vijay Kiran Kamuju: > > Any thing wrong with this patch. > > Any Comments (expecting a lot) > > > > As you asked me, i took a look on this Patch. > > For my winspool-Patches, i was told to check the documented behavior and > only check undocumented behavior, when an Application relies on this > undocumented effect. > It's of course a good Idea, to print as much Informations as possible, > when a test Failed (err in your case). > > When i add a new Test, I add a trace after every tested API-Call, > compile the Test on linux with the mingw-crosstools as Windows-Binary > (make -C dlls/your_dllname_here/tests crosstest) and run that Binary on > all Windows-Versions that I have. After an update to the Parameter and > the Text for ok(), I do the tests on Windows again. > Then I test that Binary on wine. When there are no Failures left, i > remove the traces, compile again, test again, and after a final test in > wine with (make -C dlls/your_dllname_here/tests test), the diff is > created. > > > - Your Test did not apply here, so i merged the patch by cut & paste. > (malformed Patch) > > - I get 5 Failures on wine. (make -C dlls/wininet/tests test) > > > + hinet = InternetOpenA(useragent,INTERNET_OPEN_TYPE_DIRECT,NULL,NULL, > 0); > + ok((hinet != 0x0),"InternetOpen Failed\n"); > > - Please use (hinet != NULL) here, or is MSDN wrong (value / pointer)? > > - Does the other tests work, when InternetOpenA failed, or is it more > useful to return from the test here? > > > + SetLastError(0xdeadbeef); > + retval=InternetSetOptionA(hinet,INTERNET_OPTION_USER_AGENT, &inagent, > sizeof(inagent)); > + err=GetLastError(); > + ok(retval == 1,"Got wrong return value %d\n",retval); > + ok(err == 0xdeadbeef, "Got wrong error code %ld\n",err); > > For the Example above, my Idea is: > ok(retval, "returned %d with %ld (expected '!= 0')\n", retval, err); > > + len=0; > + SetLastError(0xdeadbeef); > + buffer=HeapAlloc(GetProcessHeap(),0,len); > + retval = > InternetQueryOptionW(hinet,INTERNET_OPTION_USER_AGENT,buffer,&len); > + err=GetLastError(); > + ok(buffer != NULL,"Output Buffer Should Not be Set"); > + todo_wine ok(len == 38,"Got wrong user agent length %ld instead of %d > \n",len,38); > + > > - You use HeapAlloc with a len of 0 and than the test "buffer != NULL": > This is a Test for HeapAlloc > - InternetQueryOptionW is not implemented in win95/98/me > - Please avoid fixed numbers. When someone changes the Agent-Name, > the complete Test must be reworked. > > > For the tests of the W-Functions: > I was told, that i should test the Unicode-Functions only, when there > are other results as from the ANSI-Version. Since our ANSI - > Implementations should call the Unicode-Function, the ANSI-Test > validates both Implementations. > (Yes, i knew that the Implementation in wine is sometimes wrong: we have > Crosscalls W->A and some Unicode-Functions are stubs while the > ANSI-Versions are implemented) > > > + WideCharToMultiByte(CP_ACP,0,(WCHAR *)buffer,-1,tmpbuffer,len,0,0); > + todo_wine ok(!strcmp(inagent,tmpbuffer),"Got wrong user agent string % > s instead of %s\n",tmpbuffer,inagent); > > - This Test failed on Windows XP > > > + retval = InternetSetOptionW(NULL,INTERNET_OPTION_USER_AGENT, > &inpbuffer, sizeof(inpbuffer)); > You use ANSI-Parameter for an UNICODE-Function. > > > You can take a look at the Tests for winspool/GetPrinterDriverDirectory > - A test with the documented use to get the required size for the Buffer > (buffersize=0) > - A test with documented use (all Options valid) > - Buffer is larger (must succeed) > - Buffer is to small (must fail with a specific ERROR_*) > (Other Functions may truncate the returned Data) > - without a buffer (NULL), but with the correct buffersize. > This is for testing the API, when the app was unable to allocate > the Buffer, but did not check the Result of the allocation. > > > > So there are some Reasons, why the test is not Ready yet. > > I read the Docs about InternetQueryOption on MSDN and IMHO there are so > many Documented values for dwOption, that I suggest to start with a > testing-table and fill it with all of our implemented Options for > InternetQueryOption / InternetSetOption. > We have then a complete Test of our wininet-Implementation with only a > small amount of code. The Table can grow very easy, when Applications > use Options that we need to implement. > > > -- > By By ... > ... Detlef > >

March 3, 2006

BadMatch in glXCreateGLXPixmap (bug 3102)

by Damjan Jovanovic

"Star wars: knights of the old republic" dies on startup (see bug 3102) with BadMatch when create_glxpixmap() calls glXCreateGLXPixmap(). The man page for glXCreateGLXPixmap: GLXPixmap glXCreateGLXPixmap( Display *dpy, XVisualInfo *vis, Pixmap pixmap ) BadMatch is generated if the depth of pixmap does not match the depth value reported by core X11 for vis, or if pixmap was not created with respect to the same screen as vis. So can any xlib expert here give me some code to check for those 2 cases? Any other ideas what could be wrong? I believe a PBUFFER is involved, not the actual screen. Thanks Damjan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

March 3, 2006

Re: Recently created font problem - anyone see similar?

by Dmitry Timoshkov

"Dr J A Gow" <J.A.Gow(a)furrybubble.co.uk> wrote: > I found that the following patch, committed to CVS on 23/02/06 > at 20:33:06 made all my Wine system fonts squashed up and unreadable, which > in turn made a mess of formatting in some dialog boxes. I backed the > patch out from a current tree and the problem went away. Anyone else see > this behaviour? I am wondering what the purpose of this patch is as > the fonts were quite OK before it was committed, and now they are > completely unreadable on this system. Any thoughts before I submit a > patch to put this back the way it was? This usially means that you have no Wine bitmap fonts installed in windows/fonts. I sent a patch to wineprefixcreate to install them by default, by Alexandre rejected it. -- Dmitry.

March 3, 2006

Launch native Linux apps?

by Rich Gilson

Is it possible to set Wine up so that it can launch native Linux apps? For example, set your native copy of Acrobat Reader to be associated to PDF extensions in Wine, or even use the Linux plugin while using a browser? If so, how do I accomplish this? -- -- In a world without fences, who needs Gates?

March 3, 2006

Re: Recently created font problem - anyone see similar?

by Andrew Z

Dr J A Gow <J.A.Gow <at> furrybubble.co.uk> writes: > I found that the following patch, committed to CVS on 23/02/06 > at 20:33:06 made all my Wine system fonts squashed up and unreadable, which > in turn made a mess of formatting in some dialog boxes. I backed the > patch out from a current tree and the problem went away. Anyone else see > this behaviour? I am wondering what the purpose of this patch is as > the fonts were quite OK before it was committed, and now they are > completely unreadable on this system. Any thoughts before I submit a > patch to put this back the way it was? I had this problem too: http://bugs.winehq.org/show_bug.cgi?id=4682 I like the old behavior, and I don't like the solution of copying the fonts to the /usr/share/fonts because I want to be able to build WINE from source and run it from ~/wine without root permission (to install the fonts). Andrew

March 3, 2006

Re: DirectDraw -> WineD3D patch

by Aric Cyr

Stefan Dösinger <stefandoesinger <at> gmx.at> writes: > > Hi, > I've brought my DirectDraw over WineD3D patch in a form where I want to show > it to the public for review. I've uploaded it to > http://stud4.tuwien.ac.at/~e0526822/ , where it is described in detail(below > the game list). > Sweet! Looking forward to playing with this over the weekend. Seems like you are getting decent performance out of that radeon mobility 9000. I'll take a look at the OpenGL problem you list on the page and see if I can help (I love OpenGL, so any excuse to play with it is a good one) :) Good work! Hope your exams didn't suffer because of this ;) Regards, Aric

March 3, 2006

Recently created font problem - anyone see similar?

by Dr J A Gow

Hi, I found that the following patch, committed to CVS on 23/02/06 at 20:33:06 made all my Wine system fonts squashed up and unreadable, which in turn made a mess of formatting in some dialog boxes. I backed the patch out from a current tree and the problem went away. Anyone else see this behaviour? I am wondering what the purpose of this patch is as the fonts were quite OK before it was committed, and now they are completely unreadable on this system. Any thoughts before I submit a patch to put this back the way it was? John. The offending patch: Module: wine Branch: refs/heads/master Commit: 69a23a608eea59624b2f37ab424e0f42b3da5baf URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=69a23a608eea59624b2f37a… Author: Dmitry Timoshkov <dmitry at codeweavers.com> Date: Thu Feb 23 20:33:06 2006 +0800 gdi: Use "MS Sans Serif" as default sans serif font, not Arial. --- dlls/gdi/freetype.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/dlls/gdi/freetype.c b/dlls/gdi/freetype.c index ad0d6eb..51e92b8 100644 --- a/dlls/gdi/freetype.c +++ b/dlls/gdi/freetype.c @@ -284,10 +284,10 @@ static struct list font_list = LIST_INIT static const WCHAR defSerif[] = {'T','i','m','e','s',' ','N','e','w',' ', 'R','o','m','a','n','\0'}; -static const WCHAR defSans[] = {'A','r','i','a','l','\0'}; +static const WCHAR defSans[] = {'M','S',' ','S','a','n','s',' ','S','e','r','i','f','\0'}; static const WCHAR defFixed[] = {'C','o','u','r','i','e','r',' ','N','e','w','\0'}; -static const WCHAR defSystem[] = {'A','r','i','a','l','\0'}; +static const WCHAR defSystem[] = {'S','y','s','t','e','m','\0'}; static const WCHAR SystemW[] = {'S','y','s','t','e','m','\0'}; static const WCHAR MSSansSerifW[] = {'M','S',' ','S','a','n','s',' ', 'S','e','r','i','f','\0'};

March 2, 2006

DirectDraw -> WineD3D patch

by Stefan Dösinger

Hi, I've brought my DirectDraw over WineD3D patch in a form where I want to show it to the public for review. I've uploaded it to http://stud4.tuwien.ac.at/~e0526822/, where it is described in detail(below the game list). If there are no fundamental objections against it, I'll start sending patches for WineD3D. The changes I'll make in small patches :) are: -> Header fixes, that wined3d_interface.h can be included with d3d.h -> Adding methods to WineD3D for DirectDraw rendering -> Adding the 2D only surface implementation to WineD3D When WineD3D is ready, I'll send a patch for dlls/ddraw to wine-devel and wine-user for a broad regression testing, and when the regressions are out, the ddraw can be replaced(From my POV, AJ has the last word of course ;) ) Have fun playing, Stefan

March 2, 2006

getwinegit.sh 0.21 released

by Christian Lachner

Hellooo, punctual to the new wine-0.9.9-release there is a new version of my getwinegit.sh-script. No great changes but some smaller ones. First of all, the logger got more informative if you experience problems with your getwinegit.sh-installation. The second thing is a better checking of the config-vars. Not the supergreat errorhandling i would like it to be but now there is something that checks if the vars are set and so on. The last thing is that the readme got a bit more informatical (dependencies and compatibility of shells). Maybe there were some more minor changes in the script but... i can't remember ;). Current version is now 0.21. PS: the release is now packed in a tar.bz2 as requested :D

March 2, 2006

Re: Dogfood Challenge, week 2

by Dan Kegel

On 2/9/06, Dan Kegel <dank(a)kegel.com> wrote: > > Firefox is quite usable; I read gmail in it routinely. > Here's my current list of firefox dogfood bugs: > > http://bugs.winehq.org/show_bug.cgi?id=4441 - black bars > http://bugs.winehq.org/show_bug.cgi?id=4523 - copy broken > http://bugs.winehq.org/show_bug.cgi?id=4528 - too tall > http://bugs.winehq.org/show_bug.cgi?id=4529 - screwy stars At first glance, Mike's patch for 4529 also fixes bugs 3171, 4441, and 4442! Firefox just got a lot tastier. (The patch isn't in cvs yet, but I think it ought to be, based on my extensive ten minutes of testing :-) - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 2, 2006

Re: WineD3D Opengl 2.x compile fix

by H. Verbeet

On 02/03/06, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: >+ if(WINE_GL_VERSION_MAJOR(gl_info->gl_version) == 2) { Shouldn't that be >= 2? It seems unlikely functionality would get removed in later OpenGL versions.

March 2, 2006

Re: Alexandre Julliard : configure: Use --rpath if supported when building binaries to point to

by Alexandre Julliard

Vitaly Lipatov <lav(a)etersoft.ru> writes: > Now I think there is bug somewhere. I see in ps strange paths after ran any > program: > /usr/lib/../bin/wine-preloader > /usr/lib/../bin/wine-kthread notepad.exe > /usr/lib/../bin/wineserver That's not a bug, it's a feature. Binaries are now located relative to the library path, so if you move your Wine install somewhere else it still works, without having to set environment variables. -- Alexandre Julliard julliard(a)winehq.org

March 2, 2006

Re: Alexandre Julliard : configure: Use --rpath if supported when building binaries to point to

by Jan Zerebecki

On Wed, Mar 01, 2006 at 08:29:38PM -0800, Dan Kegel wrote: > Vitaly wrote: > >Build system in ALT Linux has strict requires to use rpath and last changes in > >wine conflicts with it. > > Can you explain more about ALT Linux's build system and rpath? > > Does it disallow all use of rpath by applications? > - Dan At least for Debian I think rpath may not be used. But as I understand it, it may be used if the referenced lib. path is completely private to the package, even tho that is discouraged. See the following link and especially the linked mailinglist thread for explanation: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#rpath Jan

March 2, 2006

Re: [PATCH 3/3] [Dnsapi.dll] Tests

by Steven Edwards

On 3/2/06, Steven Edwards <winehacker(a)gmail.com> wrote: > Why don't you break this out in to a function like load_dnsapi() that > way if there are missing symbols from one version to another you can > use GetProcAddress and delay load them and it will all be contained in > one function. Also to make it clear you don't need to do the delay loading of the symbols unless they really differ from one windows to another. Just using the LoadLibrary is fine. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

March 2, 2006

Re: [PATCH 3/3] [Dnsapi.dll] Tests

by Steven Edwards

Hi, Just a matter of style to save moving the code around later if we add more tests. +START_TEST(names) +{ + HMODULE hdnsapi = LoadLibrary("dnsapi.dll"); + char *testname1 = ".bob"; + char *testname2 = ".bOb"; + + trace("Dnsapi.dll is only on Win2k and above.\nChecking...\n"); + if(hdnsapi != NULL) + { + trace("Dnsapi.dll loaded.\nNow unloading...\n"); + FreeLibrary(hdnsapi); + } + else + { + trace("Dnsapi.dll was not loaded or failed to be unloaded.\n"); + return; + } Why don't you break this out in to a function like load_dnsapi() that way if there are missing symbols from one version to another you can use GetProcAddress and delay load them and it will all be contained in one function. + trace("Now testing function: DnsNameCompare_A(LPSTR, LPSTR)\n"); + ok(DnsNameCompare_A(testname1,testname2)==TRUE, + "Comparison failed!\n %s and %s should be equal!\n",testname1,testname2); + trace("%s and %s are equal.\n",testname1,testname2); Also it would be a good idea to break this out in to another function. I tend to do one function per API I am checking so I would stick all of this in to a function called test_DnsNameCompare(); +} Nice work btw. Thanks for being patent with submitting patches and tests. I am not really that great of a programmer and these type of style changes help me follow along and write better tests. Take a look at this test I wrote to get the idea http://cvs.winehq.org/cvsweb/wine/dlls/setupapi/tests/stringtable.c?rev=1.2… It tends to be more lines but I think its much clearer to read. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

March 2, 2006

Re: New d3d8 code and FFXIBench3 - pretty good!

by Stefan Dösinger

Hi, > I own Diablo 2... this would be a good reason to dust it off :) I should get it by today :) I ordered it at Amazon for a cheap price. Usually it takes 3 days until I get things. Snail mail that is :). > I am running fglrx as well, so I could work on getting the performance up > on these cards. I also have contacts at ATI, so if there are specific > problem I could send feedback directly, and hopefully they can fix things > for future releases. Although I'd check glDrawPixels on Windows as well... > I suspect it is just as slow there. Also for glDrawPixels you should turn > off a lot of the GL state (lighting and stuff that you don't need). That > could speed things up a bit. The attached program illustrates the problem: It's a d3d9 app and runs with current Wine CVS. On startup, it shows a black screen. If you press any button(except ESC), it will do a Clear with a solid color based on the key you pressed. If you click anywhere with the left mouse button, it locks the backbuffer, fills it with 0xff, unlocks it and flips. On Mesa radeon this has no effect(image doesn't change), with software rendering it's the same, as well with fglrx. If you change the pixel format to D3DFMT_R8G8B8, then it will work for fglrx. I haven't tested this on Windows, but I was told that it works with Nvidia cards in Wine. I just tested it in some old cvscedega version, and there it works, although I have to click twice. If you change D3DSWAPEFFECT_FLIP to D3DSWAPEFFECT_DISCARD in line 121, the screen will go black on clicks, with a delay of about one secound, so you can see the slowlyness. In some rare cases in games, glDrawPixels writes a dark, solid color, and if it writes to the front buffer, it's possible to see the new color sliding down slowly. I suspect that glDrawPixels isn't really broken, but WineD3D sets up render states which break it. I wanted to do a test with a simple GL app, but I didn't find the time yet. Current DDraw is broken in the same way, but it in the most cases, it draws a textured quad instead of using glDrawPixels, which works fine there.

March 2, 2006

Re: [PATCH 2/3] [Dnsapi.dll] Implement Dnsapi.dll

by Rolf Kalbermatter

Mike McCormack [mike(a)codeweavers.com] wrote: >> + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); >> + return ERROR_CALL_NOT_IMPLEMENTED; >> +} > >You SetLastError or return an error code, not both. This is not always correct. Win32 API has several functions returning an int where the only SDK documentation is that the function returns 0 on success and anything else on failure. What those usually seem to do is retuning the (internal) error code. Relying on such a return value being anything than 0 or !0 of course would be bad programming, since there will be potential differences between different platforms but it does happen. Rolf Kalbermatter

March 2, 2006

re: Alexandre Julliard : configure: Use --rpath if supported when building binaries to point to

by Dan Kegel

Vitaly wrote: >Build system in ALT Linux has strict requires to use rpath and last changes in >wine conflicts with it. Can you explain more about ALT Linux's build system and rpath? Does it disallow all use of rpath by applications? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 2, 2006

Re: [PATCH 2/3] [Dnsapi.dll] Implement Dnsapi.dll

by Mike McCormack

Also, please disable your challenge/response spam "filter". Solving your spam problem by spamming everybody else is not cool. You wrote to us with a patch, you solicited our response, so why are you spamming us back? I'd advise others to not respond to spam from bluebottle.com. Mike

March 2, 2006

Re: [PATCH 2/3] [Dnsapi.dll] Implement Dnsapi.dll

by Dmitry Timoshkov

"MattK" <mekjedi(a)bluebottle.com> wrote: > + if(fdwReason == DLL_THREAD_ATTACH) > + { > + DisableThreadLibraryCalls(hinstDLL); > + return TRUE; > + } This is not an appropriate place to call DisableThreadLibraryCalls, how did you come with it when there are a lot of examples in the Wine tree? -- Dmitry.

March 2, 2006

Re: x11drv fix for bug#4506: page fault on read access

by Dmitry Timoshkov

"Rein Klazes" <wijn(a)wanadoo.nl> wrote: > + srcpixel = (const DWORD*)((int)srcpixel & 0xfffffffc); It would be more readable IMO to use ~3 instead of 0xfffffffc. -- Dmitry.

March 2, 2006

[wined3d] glStencilOpSeparate & glStencilFuncSeparate symbol errors

by Aric Cyr

The recent patch: http://winehq.org/pipermail/wine-patches/2006-February/024656.html can cause linker errors for the two symbols glStencilOpSeparate and glStencilFuncSeparate. The reason being that these are only exported in OpenGL 2.0 compatible libraries, and in particular, are not present in ATI's binary driver. This causes wined3d to fail to build (compiles fine but linking fails). I suspect that Vitaly is already working on fixing this, but thought I'd mention it anyways since other might run into the same problem. Cheers, Aric

March 2, 2006

Re: [PATCH 2/3] [Dnsapi.dll] Implement Dnsapi.dll

by Mike McCormack

MattK wrote: > +BOOL WINAPI DnsNameCompare_A(LPSTR pName1, LPSTR pName2) > +{ > + TRACE("(%s %s)\n",pName1, pName2); > + > + LPSTR name1 = pName1; > + LPSTR name2 = pName2; > + > + RemovePeriods(name1); > + RemovePeriods(name2); > + > + int equal; > + > + equal = lstrcmpiA(name1,name2); > + > + return !equal; > +} This is still not correct. You can't modify name1, and name2 in place. You shouldn't use inline declarations (ie. the "int equal" should be after the bracket.) There's also no in assigning pName1 to name1, it doesn't make a copy of the string as you suspect, it makes a copy of the pointer to the string. > + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); > + return ERROR_CALL_NOT_IMPLEMENTED; > +} You SetLastError or return an error code, not both. > diff -Nu dlls/dnsapi/utils.c dlls/dnsapi/utils.c There's no need to make a seperate file for this. > +LPSTR RemovePeriods(LPSTR string) > +{ > + if(string == NULL) > + return NULL; > + DWORD d = 0; > + > + while(string[d] == '.') > + { > + string--; > + } > + > + return string; > +} This won't work at all... If you wrote some better test cases you would discover these problems. How about testing: DnsNameCompare_A(NULL, NULL) DnsNameCompare_A("", ".") DnsNameCompare_A("..........", "..........") DnsNameCompare_A(".a.b.c.d.e.", "abcde") DnsNameCompare_A("a.com.","a.com") DnsNameCompare_A("A.com", "a.com") DnsNameCompare_A(".A.com", "a.com") DnsNameCompare_A("Acom", "acom") etc. Mike

March 2, 2006

Re: wined3d: Fix compile for older OpenGL headers.

by Raphael

On Wednesday 01 March 2006 11:48, Vitaly Budovski wrote: > H. Verbeet wrote: > > Although #ifdef GL_VERSION_2_0 will make compilation work with older > > OpenGl headers, it's not the way to fix this. Basically, wined3d > > should check for functionallity during runtime with GL_SUPPORT and > > call extensions with GL_EXTCALL. The issue has come up a few times > > before with patches from the same author, and I think he should be > > aware of the issue by now. > > That takes care of functions as part of an OpenGL extension. > What about core functions of a newer GL version? Would all of > those need to be defined in the wined3d_gl.h file? i forget :) We shouldn't have no more built-time checks as example: #if defined(GL_VERSION_1_3) We always must use runtime checks So WineD3D_GL_Info::gl_version must be correctly filled (isn't initialised for now) and used Regards, Rapahel

March 1, 2006

Re: wined3d: Fix compile for older OpenGL headers.

by Raphael

On Wednesday 01 March 2006 11:48, Vitaly Budovski wrote: > H. Verbeet wrote: > > Although #ifdef GL_VERSION_2_0 will make compilation work with older > > OpenGl headers, it's not the way to fix this. Basically, wined3d > > should check for functionallity during runtime with GL_SUPPORT and > > call extensions with GL_EXTCALL. The issue has come up a few times > > before with patches from the same author, and I think he should be > > aware of the issue by now. > > That takes care of functions as part of an OpenGL extension. > What about core functions of a newer GL version? Would all of > those need to be defined in the wined3d_gl.h file? Yes, else will have problems in wine launch if installed OpenGL library not provide this symbols Regards, Raphael

March 1, 2006

Re: Alexandre Julliard : configure: Use --rpath if supported when building binaries to point to

by Mike Hearn

On Wed, 2006-03-01 at 22:21 +0300, Vitaly Lipatov wrote: > Did you mean fix rpm spec? No, fix RPM the program. If the RPM software can't cope with a simple use of RPATH then it is buggy and should be patched. > You are about workaround explained by Alexandre? The workaround is fine for Wine, but it's the general principle I have a problem with. If you asked me to add a --disable-rpath switch to software I maintained I'd say no, because this is not a bug in my software but rather with RPM itself. > Now I think there is bug somewhere. I see in ps strange paths after ran any > program: > /usr/lib/../bin/wine-preloader > /usr/lib/../bin/wine-kthread notepad.exe > /usr/lib/../bin/wineserver Looks OK to me. A bit ugly maybe ...

March 1, 2006

Re: [PATCH 1/4] [WineDbg]: main_loop

by Eric Pouech

Alexandre Julliard wrote: > Eric Pouech <eric.pouech(a)wanadoo.fr> writes: > > >>- split dbg_main_loop in two parts (one for finishing the debuggee >> attachment, the second one really for handling the main loop) >>- removed now longer needed dbg_main_loop > > > Auto mode is still broken with this patch... did you really test it? > yes, at some point, then did some last minute change, which broke it A+ -- Eric Pouech

March 1, 2006

Re: Alexandre Julliard : configure: Use --rpath if supported when building binaries to point to

by Vitaly Lipatov

В сообщении от 1 марта 2006 21:25 Mike Hearn написал(a): > On Wed, 2006-03-01 at 20:50 +0300, Vitaly Lipatov wrote: > > Dear Mike, I asked Alexandre to add _option_ to configure for disable > > rpath but to remove rpath using. > > I understand the request, but the question remains - why are you asking > every single upstream author to add complexity to their build systems, > when you could just fix RPM? Did you mean fix rpm spec? You are about workaround explained by Alexandre? Build system in ALT Linux has strict requires to use rpath and last changes in wine conflicts with it. I guess I do not understand where is problem in RPM you told about. Now I think there is bug somewhere. I see in ps strange paths after ran any program: /usr/lib/../bin/wine-preloader /usr/lib/../bin/wine-kthread notepad.exe /usr/lib/../bin/wineserver -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

March 1, 2006

Re: Alexandre Julliard : configure: Use --rpath if supported when building binaries to point to

by Mike Hearn

On Wed, 2006-03-01 at 20:50 +0300, Vitaly Lipatov wrote: > Dear Mike, I asked Alexandre to add _option_ to configure for disable rpath > but to remove rpath using. I understand the request, but the question remains - why are you asking every single upstream author to add complexity to their build systems, when you could just fix RPM? thanks -mike

March 1, 2006

Re: wined3d: Implemented WINED3DRS_DEPTHBIAS

by H. Verbeet

On 01/03/06, Vitaly Budovski <vbudovsk(a)cs.rmit.edu.au> wrote: > + glPolygonOffset(*((float*)&This->stateBlock->renderState[WINED3DRS_SLOPESCALEDEPTHBIAS]), tmpvalue.f); Does this compile?

March 1, 2006

Re: wined3d: Add function pointers to glSupportOpSeparate and glSupportFuncSeparate

by H. Verbeet

On 01/03/06, Vitaly Budovski <vbudovsk(a)cs.rmit.edu.au> wrote: > wined3d: Add function pointers to glSupportOpSeparate and > glSupportFuncSeparate > That's not going to help much if you don't actually use them. Also, you probably want to be able to detect if the functions are actually available, instead of just dereferencing a NULL pointer if they aren't.

March 1, 2006

Re: Alexandre Julliard : configure: Use --rpath if supported when building binaries to point to

by Vitaly Lipatov

В сообщении от 1 марта 2006 17:23 Mike Hearn написал(a): > On Fri, 24 Feb 2006 21:11:39 +0300, Vitaly Lipatov wrote: > > Sorry for my English. It is useful when we run wine from the source tree. > > It's useful for people distributing Wine binaries as well. Not every > feature is there for the distros you know ... also asking developers to > disable rpath because RPM cannot cope with it is remarkably poor form IMO, > just fix RPM! Dear Mike, I asked Alexandre to add _option_ to configure for disable rpath but to remove rpath using. It is poor way to make comments about distros and RPMs as your one. -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

March 1, 2006