- wine-devel - winehq.org

Re: gdi32/winex11.drv: Change all gdi/opengl declarations to use __cdecl
by Dmitry Timoshkov 17 Dec '08

17 Dec '08

"Maarten Lankhorst" <m.b.lankhorst(a)gmail.com> wrote: > Needed to get +relay working in wine64 You should have used CDECL instead of __cdecl, have a look how it's done in msvcrt.dll. -- Dmitry.

2 1

Re: gdi32/winex11.drv: Change all gdi/opengl declarations to use __cdecl
by Alexandre Julliard 17 Dec '08

17 Dec '08

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > @@ -33,9 +33,9 @@ > WINE_DEFAULT_DEBUG_CHANNEL(bitmap); > > > -static HGDIOBJ BITMAP_SelectObject( HGDIOBJ handle, HDC hdc ); > -static INT BITMAP_GetObject( HGDIOBJ handle, void *obj, INT count, LPVOID buffer ); > -static BOOL BITMAP_DeleteObject( HGDIOBJ handle, void *obj ); > +static HGDIOBJ __cdecl BITMAP_SelectObject( HGDIOBJ handle, HDC hdc ); > +static INT __cdecl BITMAP_GetObject( HGDIOBJ handle, void *obj, INT count, LPVOID buffer ); > +static BOOL __cdecl BITMAP_DeleteObject( HGDIOBJ handle, void *obj ); You shouldn't need to change these. -- Alexandre Julliard julliard(a)winehq.org

1 0

Making the shell32/appbar tests pass on Vista
by Paul Vriens 17 Dec '08

17 Dec '08

Hi Vincent, I was trying to have the appbar tests succeed on Vista. One way I could make it work is with the attached patch. Does this make sense? Or should we have another possible outcome of the test? (or even a broken()?). The change to do_events_until was only for my troubleshooting purposes. (Vista times out without the patch). -- Cheers, Paul. diff --git a/dlls/shell32/tests/appbar.c b/dlls/shell32/tests/appbar.c index d11a999..8dff9a8 100644 --- a/dlls/shell32/tests/appbar.c +++ b/dlls/shell32/tests/appbar.c @@ -128,8 +128,13 @@ static void do_events_until(boolean_function test) TranslateMessage(&msg); DispatchMessageA(&msg); } - if (timedout || test()) + if (test()) break; + else if (timedout) + { + trace("Timed out waiting for condition to become true\n"); + break; + } WaitMessage(); } @@ -333,6 +338,8 @@ static void test_setpos(void) windows[0].registered = FALSE; DestroyWindow(windows[0].hwnd); + testwindow_setpos(windows[1].hwnd); + do_events_until(got_expected_bottom); ok(windows[1].allocated_rect.bottom == expected_bottom, "windows[1]'s bottom is %i, expected %i\n", windows[1].allocated_rect.bottom, expected_bottom);

1 0

Re: wined3d: Implement check for shader creation if hardware supports requested version.
by Paul Vriens 17 Dec '08

17 Dec '08

Pauli Nieminen wrote: > + > + if( version <= caps->VertexShaderVersion ) > + { > + ok(hret == D3D_OK && vshader_ptr != NULL, "Vertex shader (0x%x) creation failed but d3dcaps claim to support it. hret = 0x%x, vshader_ptr = %p", version, hret, vshader_ptr); > + IDirect3DVertexShader9_Release(vshader_ptr); > + } else { > + ok(hret == D3DERR_INVALIDCALL && vshader_ptr == NULL,"Vertex shader (0x%x) creation succesed but d3dcaps claim not to support it. hret = 0x%x, vshader_ptr = %p", version, hret, vshader_ptr); > + } Hi, Just some style issues I've seen. You should be using a: if () { } else { } block to stick with the style. > > +/** > + * checks if shader version supported that is required by new > + * shader. > + */ > +static inline BOOL is_pshader_version_supported(IWineD3DDeviceImpl *deviceImpl, const DWORD *byte_code) > +{ > + struct shader_caps shader_caps; > + const DWORD shader_version = *byte_code; /* First instruction should be shader version */ > + const WineD3D_GL_Info *gl_info = &deviceImpl->adapter->gl_info; > + > + deviceImpl->shader_backend->shader_get_caps(deviceImpl->devType ,gl_info, &shader_caps); > + // Check which shader this is Please use C-style comments, not C++. > + if(shader_is_pshader_version(shader_version)) > + { > + // Check if high enough shader version is supported And there are a few others of those. -- Cheers, Paul.

3 4

Re: wined3d: Reduce and improve error message spam when shader creation fails.
by Henri Verbeet 17 Dec '08

17 Dec '08

These should probably all be WARNs as well.

1 0

Re: wined3d: Implement check for shader creation if hardware supports requested version.
by Henri Verbeet 17 Dec '08

17 Dec '08

2008/12/17 Pauli Nieminen <suokkos(a)gmail.com>: > +static inline BOOL is_pshader_version_supported(IWineD3DDeviceImpl *deviceImpl, const DWORD *byte_code) > +{ > + struct shader_caps shader_caps; > + const DWORD shader_version = *byte_code; /* First instruction should be shader version */ Please don't do that, use the reg_maps.shader_version instead. > + ERR("First instruction in shader isn't correct shader version for pixel shader. (0x%x)\n", shader_version); ERR is for internal errors, this should be a WARN. You probably don't need to print anything at all here though, doing it from the caller makes more sense (and you've got a message there already anyway). > + ERR("No hardware support for pixel shader version (0x%x).\n",*pFunction); Like above, this should be a WARN. That also means you can get rid of the code to only print the message once.

1 0

Re: d3d9/tests: Add missing new lines to ok() and split long lines
by Paul Vriens 17 Dec '08

17 Dec '08

Pauli Nieminen wrote: > --- > dlls/d3d9/tests/shader.c | 16 ++++++++++++---- > 1 files changed, 12 insertions(+), 4 deletions(-) > > diff --git a/dlls/d3d9/tests/shader.c b/dlls/d3d9/tests/shader.c > index 55b414a..caae395 100644 > --- a/dlls/d3d9/tests/shader.c > +++ b/dlls/d3d9/tests/shader.c > @@ -85,10 +85,14 @@ static inline void test_create_vshader_version_check(IDirect3DDevice9 *device_pt > > if( version <= caps->VertexShaderVersion ) > { > - ok(hret == D3D_OK && vshader_ptr != NULL, "Vertex shader (0x%x) creation failed but d3dcaps claim to support it. hret = 0x%x, vshader_ptr = %p", version, hret, vshader_ptr); > + ok(hret == D3D_OK && vshader_ptr != NULL, > + "Vertex shader (0x%x) creation failed but d3dcaps claim to support it. hret = 0x%x, vshader_ptr = %p\n", > + version, hret, vshader_ptr); > IDirect3DVertexShader9_Release(vshader_ptr); > } else { > - ok(hret == D3DERR_INVALIDCALL && vshader_ptr == NULL,"Vertex shader (0x%x) creation succesed but d3dcaps claim not to support it. hret = 0x%x, vshader_ptr = %p", version, hret, vshader_ptr); > + ok(hret == D3DERR_INVALIDCALL && vshader_ptr == NULL, > + "Vertex shader (0x%x) creation succesed but d3dcaps claim not to support it. hret = 0x%x, vshader_ptr = %p\n", > + version, hret, vshader_ptr); > } > > } > @@ -104,10 +108,14 @@ static inline void test_create_pshader_version_check(IDirect3DDevice9 *device_pt > > if( version <= caps->PixelShaderVersion ) > { > - ok(hret == D3D_OK && pshader_ptr != NULL, "Pixel shader (0x%x) creation failed but d3dcaps claim to support it. hret = 0x%x, pshader_ptr = %p", version, hret, pshader_ptr); > + ok(hret == D3D_OK && pshader_ptr != NULL, > + "Pixel shader (0x%x) creation failed but d3dcaps claim to support it. hret = 0x%x, pshader_ptr = %p\n", > + version, hret, pshader_ptr); > IDirect3DPixelShader9_Release(pshader_ptr); > } else { > - ok(hret == D3DERR_INVALIDCALL && pshader_ptr == NULL,"Pixel shader (0x%x) creation succesed but d3dcaps claim not to support it. hret = 0x%x, pshader_ptr = %p", version, hret, pshader_ptr); > + ok(hret == D3DERR_INVALIDCALL && pshader_ptr == NULL, > + "Pixel shader (0x%x) creation succesed but d3dcaps claim not to support it. hret = 0x%x, pshader_ptr = %p\n", > + version, hret, pshader_ptr); > } > > } Hi, These fixes are on top of your previous patch which is not committed). If it's a series of patches you should mark them appropriate ([1/2] and [2/2] for example). In this case it's probably better to incorporate this into the previous patch and resend that one. -- Cheers, Paul.

1 0

[try2] ntoskrnl.exe: Implement Io{Allocate, Get}DriverObjectExtension.
by Alexander Morozov 17 Dec '08

17 Dec '08

Please, use this patch instead of previous "ntoskrnl.exe: Implement Io{Allocate,Get}DriverObjectExtension." From b5441d22fe51640849436b563ca3ab6c9a80c1a5 Mon Sep 17 00:00:00 2001 From: Alexander Morozov <amorozov(a)etersoft.ru> Date: Wed, 17 Dec 2008 12:44:46 +0300 Subject: [PATCH] ntoskrnl.exe: Implement Io{Allocate,Get}DriverObjectExtension. --- dlls/ntoskrnl.exe/ntoskrnl.c | 53 +++++++++++++++++++++++++++++++++++++++-- 1 files changed, 50 insertions(+), 3 deletions(-) diff --git a/dlls/ntoskrnl.exe/ntoskrnl.c b/dlls/ntoskrnl.exe/ntoskrnl.c index a669d3b..73054e3 100644 --- a/dlls/ntoskrnl.exe/ntoskrnl.c +++ b/dlls/ntoskrnl.exe/ntoskrnl.c @@ -63,6 +63,16 @@ struct IrpInstance IRP *irp; }; +static struct list DriverObjExtensions = LIST_INIT(DriverObjExtensions); + +struct DriverObjExtension +{ + struct list entry; + void *ptr; + DRIVER_OBJECT *driver; + void *id_addr; +}; + #ifdef __i386__ #define DEFINE_FASTCALL1_ENTRYPOINT( name ) \ __ASM_GLOBAL_FUNC( name, \ @@ -267,9 +277,28 @@ NTSTATUS WINAPI IoAllocateDriverObjectExtension( PDRIVER_OBJECT DriverObject, ULONG DriverObjectExtensionSize, PVOID *DriverObjectExtension ) { - FIXME( "%p, %p, %u, %p\n", DriverObject, ClientIdentificationAddress, + struct DriverObjExtension *ext; + + TRACE( "%p, %p, %u, %p\n", DriverObject, ClientIdentificationAddress, DriverObjectExtensionSize, DriverObjectExtension ); - return STATUS_NOT_IMPLEMENTED; + + *DriverObjectExtension = NULL; + if (IoGetDriverObjectExtension( DriverObject, ClientIdentificationAddress )) + return STATUS_OBJECT_NAME_COLLISION; + ext = ExAllocatePool( NonPagedPool, sizeof(*ext) ); + if (ext == NULL) + return STATUS_INSUFFICIENT_RESOURCES; + ext->ptr = ExAllocatePool( NonPagedPool, DriverObjectExtensionSize ); + if (ext->ptr == NULL) + { + ExFreePool( ext ); + return STATUS_INSUFFICIENT_RESOURCES; + } + ext->driver = DriverObject; + ext->id_addr = ClientIdentificationAddress; + list_add_tail( &DriverObjExtensions, &ext->entry ); + *DriverObjectExtension = ext->ptr; + return STATUS_SUCCESS; } @@ -279,7 +308,16 @@ NTSTATUS WINAPI IoAllocateDriverObjectExtension( PDRIVER_OBJECT DriverObject, PVOID WINAPI IoGetDriverObjectExtension( PDRIVER_OBJECT DriverObject, PVOID ClientIdentificationAddress ) { - FIXME( "%p, %p\n", DriverObject, ClientIdentificationAddress ); + struct DriverObjExtension *ext; + + TRACE( "%p, %p\n", DriverObject, ClientIdentificationAddress ); + + LIST_FOR_EACH_ENTRY( ext, &DriverObjExtensions, struct DriverObjExtension, entry ) + { + if (DriverObject == ext->driver && + ClientIdentificationAddress == ext->id_addr) + return ext->ptr; + } return NULL; } @@ -1138,6 +1176,7 @@ PVOID WINAPI MmGetSystemRoutineAddress(PUNICODE_STRING SystemRoutineName) BOOL WINAPI DllMain( HINSTANCE inst, DWORD reason, LPVOID reserved ) { LARGE_INTEGER count; + struct DriverObjExtension *ext, *ext2; switch(reason) { @@ -1146,6 +1185,14 @@ BOOL WINAPI DllMain( HINSTANCE inst, DWORD reason, LPVOID reserved ) RtlAddVectoredExceptionHandler( TRUE, vectored_handler ); KeQueryTickCount( &count ); /* initialize the global KeTickCount */ break; + case DLL_PROCESS_DETACH: + LIST_FOR_EACH_ENTRY_SAFE( ext, ext2, &DriverObjExtensions, + struct DriverObjExtension, entry ) + { + list_remove( &ext->entry ); + ExFreePool( ext->ptr ); + ExFreePool( ext ); + } } return TRUE; } -- 1.6.0.2.GIT

2 1

Re: [PATCH] wined3d: Implement check for shader creation if hardware supports requested version.
by Henri Verbeet 17 Dec '08

17 Dec '08

2008/12/17 Pauli Nieminen <suokkos(a)gmail.com>: > +static inline void test_create_vshader_version_check(IDirect3DDevice9 *device_ptr, const D3DCAPS9 *caps, > + const DWORD version, const DWORD *shader_code) > +{ > + IDirect3DVertexShader9 *vshader_ptr = 0; > + HRESULT hret = 0; > + > + hret = IDirect3DDevice9_CreateVertexShader(device_ptr, shader_code, &vshader_ptr); > + > + > + if( version <= caps->VertexShaderVersion ) > + { > + ok(hret == D3D_OK && vshader_ptr != NULL, "Vertex shader (0x%x) creation failed but d3dcaps claim to support it. hret = 0x%x, vshader_ptr = %p", version, hret, vshader_ptr); > + } else { > + ok(hret == D3DERR_INVALIDCALL && vshader_ptr == NULL,"Vertex shader (0x%x) creation succesed but d3dcaps claim not to support it. hret = 0x%x, vshader_ptr = %p", version, hret, vshader_ptr); > + } > + > +} If creation succeeds, you need to Release the shader again. Same goes for the pixel shader version of this function. > - ok(hret == D3D_OK && shader_refcount == i && current_shader_ptr == shader_ptr, > + ok(hret == D3D_OK && shader_refcount == i && current_shader_ptr == shader_ptr, > I don't particularly like the trailing space either, but you shouldn't make unrelated whitespace changes in your patch. > +static inline BOOL is_shader_version_supported(IWineD3DDeviceImpl *deviceImpl, const DWORD *byte_code) > +{ > +// IWineD3DPixelShaderImpl *This = (IWineD3DPixelShaderImpl *)shader; > + struct shader_caps shader_caps; > + const DWORD shader_version = *byte_code; /* First instruction should be shader version */ > + const WineD3D_GL_Info *gl_info = &deviceImpl->adapter->gl_info; Please don't use tabs or C++ style comments. > /* Note that this does not count the loop register > * as an address register. */ > @@ -216,7 +244,27 @@ HRESULT shader_get_registers_used(IWineD3DBaseShader *iface, struct shader_reg_m > memset(reg_maps->bumpmat, 0, sizeof(reg_maps->bumpmat)); > memset(reg_maps->luminanceparams, 0, sizeof(reg_maps->luminanceparams)); > > - /* get_registers_used is called on every compile on some 1.x shaders, which can result > + /* If no hardware support this function should fail */ > + if (!is_shader_version_supported((IWineD3DDeviceImpl*)This->baseShader.device, pToken)) > + { > + static BOOL warned = FALSE; > + if (!warned) > + { > + warned = TRUE; > + ERR("No hardware support for shader version.\n"); > + } > + return WINED3DERR_INVALIDCALL; > + } > + > + > + if (!pToken) > + { > + WARN("Got a NULL pFunction, returning.\n"); > + This->baseShader.functionLength = 0; > + return WINED3D_OK; > + } > + > + /* get_registers_used is called on every compile on some 1.x shaders, which can result > I don't think shader_get_registers_used is the right place for this. The version check should be in IWineD3DVertexShaderImpl_SetFunction() and IWineD3DPixelShaderImpl_SetFunction(), after the call to shader_get_registers_used(). Putting it there means you can use the shader version in reg_maps.shader_version, and you can also check if the shader is actually a vertexshader or pixelshader. Ie, passing a pixel shader to CreateVertexShader() should most likely fail.

2 2

Re: server: implement move/rename change notifications and support for multiple change notification in one reply
by Dan Kegel 17 Dec '08

17 Dec '08

On Tue, Dec 16, 2008 at 5:21 PM, Michael Pujos <pujos.michael(a)laposte.net> wrote: >> I don't see an attachment to >> http://www.winehq.org/pipermail/wine-patches/2008-December/066224.html >> or rather, there's only a zero-length one. > > I just attached (In thunderbird) the file outputted by "git format-patch > --keep-subject origin" > Curiously the link above point to a zero length file but I received it > correctly in my e-mail client from the mailing-list... That archive is a bit finicky. I see the attachment in another archive: http://marc.info/?l=wine-patches&m=122947592925831&w=2 Suggestion: next time use a shorter filename, maybe that's what screwed up the archive. It looks like you're changing the protocol. Will old clients be able to connect successfully? It looks like they won't. you need to support old clients. We're not allowed to break compatibility now that we've released wine-1.0. - Dan

3 4

Re: MSI: fix some NULL checking in MSI_RecordGetStringA
by James Hawkins 16 Dec '08

16 Dec '08

On Tue, Dec 16, 2008 at 9:11 AM, Aric Stewart <aric(a)codeweavers.com> wrote: > --- > dlls/msi/record.c | 7 ++++--- > 1 files changed, 4 insertions(+), 3 deletions(-) > Can you add tests for this please? Thanks, James Hawkins

2 2

Re: jscript: api.js, added test routines for Math functions
by Jacek Caban 16 Dec '08

16 Dec '08

Hi Patrick, First of all, tests must pass on Wine and Windows. Your test won't pass on any of them! When you have a test that passes on Windows, please send one function implementation and tests in one patch. Patrick Rudolph wrote: > From c43e52c3446fb846a760002f0222f697075fad1b Mon Sep 17 00:00:00 2001 > From: Patrick Rudolph <patrick1804(a)web.de> > Date: Thu, 11 Dec 2008 17:48:38 +0100 > Subject: jscript: api.js added test routines for Math functions > > modified: dlls/jscript/tests/api.js > added tests for : > Math.PI > Math.E > Math.SQRT2 > Math.SQRT1_2 > Math.sin > Math.cos > Math.random > Math.tan > Math.atan > Math.asin > Math.acos > Math.log > math.atan2 > > --- > dlls/jscript/tests/api.js | 38 +++++++++++++++----------------------- > 1 files changed, 42 insertions(+), 0 deletions(-) > > diff --git a/dlls/jscript/tests/api.js b/dlls/jscript/tests/api.js > index 6430397..50a28d5 100644 > --- a/dlls/jscript/tests/api.js > +++ b/dlls/jscript/tests/api.js > > +i = (Math.PI()).toString(); > Math.PI is constant, not function so you can't call it. You'd know that if you'd verified that the test passes on Windows. > +ok(i === "3.14159265358979","Math.PI() = " + i); > It's bad idea to compare double values in tests, and comparing strings is strange here. Math.PI already has a test, look there how it's done there. > + > +i = (Math.E()).toString(); > +ok(i === "2.71828182845905","Math.E() = " + i); > Same here. > + > +i = (Math.SQRT2()).toString(); > +ok(i === "1.4142135623731","Math.SQRT2() = " + i); > And here. > +i = (Math.SQRT1_2()).toString(); > +ok(i === "0.707106781186547","Math.SQRT1_2() = " + i); > And here. > +i = Math.sin(0); > +ok(i === 0, "Math.sin(0) = " + i); > + > +i = Math.cos(0); > +ok(i === 1, "Math.cos(0) = " + i); > + > +i = Math.tan(0); > +ok(i === 0, "Math.tan(0) = " + i); > + > +i = Math.log(1); > +ok(i === 0 , "Math.log() = " + i); > + > +i = Math.random(); > +ok(i !== 0 , "Math.random() = " + i); > + > +i = Math.random(); > +ok(i !== 1 , "Math.random() = " + i); > + > +i = Math.atan2(0,1); > +ok(i === 0 , "Math.atan2(0,1) = " + i); > + > +i = Math.atan(0); > +ok(i === 0 , "Math.atan(0) = " + i); > + > +i = (Math.asin(1)).toString(); > +ok(i === "1.5707963267949" , "Math.asin(1) = " + i); > + > +i = (Math.acos(-1)).toString(); > +ok(i === "3.14159265358979" , "Math.acos(-1) = " + i); > There functions should have more tests like passing no argument, testing invalid asin/acos arguments, passing too much arguments (and should be sent in one patch, together with implementation). Also, in other patches, please add comments pointing to specifications of these function when you implement them. It would be good idea to get one patch accepted before resending the whole series. Jacek

1 0

Re: [1/5] jscript: Implement the String.anchor() method (resend).
by Jacek Caban 16 Dec '08

16 Dec '08

Hi Andrew, Andrew Nguyen wrote: > This revision incorporates Jacek Caban's suggestions. > --- > dlls/jscript/string.c | 55 +++++++++++++++++++++++++++++++++++++++++++- > dlls/jscript/tests/api.js | 17 ++++++++++++++ > 2 files changed, 70 insertions(+), 2 deletions(-) > + if(ret) { + sprintfW(ret, attrtagfmtW, tagname, attrname, (attrval ? attrval : undefinedW), string->str, tagname); + + V_VT(retv) = VT_BSTR; + V_BSTR(retv) = ret; + + SysFreeString(attrval); It looks for me much better now, but you leak attrval if retv is NULL or SysAllocStringLen fails. SysFreeString call should be moved just before the last return. Jacek

1 0

winecfg volume serial number
by Hoehle, Joerg-Cyril 16 Dec '08

16 Dec '08

Hi, I just sent a bug-fix to wine-patches to prevent a crash in winecfg when editing the volume serial number input field, together with some unrelated thoughts about winecfg and the device/volume serial number handling. Then I realized that wine-patches is not a good place for discussion. So here are the ideas about winecfg's GUI: - Maybe the serial input field should be initialized with %08X instead of %X to hint at the format? E.g. input of serial numbers like "1122-dacf" as printed by DIR produce 00001122 in winecfg, due to strtoul(). - Possibly the input size should be restricted to 8 characters in the GUI? - Maybe winecfg should echo the hex number it read into the input field, no later than "apply" time? Currently one needs to select another drive, then come back to see what it got. Note that winecmd's DIR prints the number in lower case, while MS-w2k DOS window's DIR prints upper case. BTW, winecfg does not seem to be able to set .windows-label anymore: trace:winecfg:apply_drive_changes warn:winecfg:set_drive_label unable to set volume label for devicename of L"E:\\", label of L"xyz" trace:winecfg:PRINTERROR error: 'Access denied' Looks like http://bugs.winehq.org/show_bug.cgi?id=13273 Regards, Jörg Höhle

1 0

Use show instead of glyphshow: gylphshow very slow on kyocera
by Wolfgang Walter 16 Dec '08

16 Dec '08

Hello, wineps.drv uses the postscript operator glyphshow to print glyphs. This operator is very slow on all Kyocera postscript printers. To get an idea: its generally only 1/6 to 1/10 of the performance compared to the same document printed with the windows xp postscript driver (which does not use glyphsow). I wrote an email hier where I proposed a patch. This patch changes wineps.drv such that it uses the show operator for downloaded fonts (type1 and type42). This change is not trivial as the show operator (and its relatives xshow, yshow, xyshow) operates on character codes and not on glyhpnames. So wineps.drv must generate postscript code define an appropriate encoding. As a font may only have up to 256 characters encoded and as it is not allowed to modify the encoding once defined the font must be cloned if more then 256 characters are used. This is inexpensive, though, as actually all resources but the encoding array are shared. See the patch my earlier mail for a more detailed explanation. This modification brings the performance of the postscript code generated by wine up to windows' postscript driver (if no clipping region is defined - another problem). I tested it on a wide range of kyocera printer models and two hp models. Of course I tested it with ghostscript. I would appreciate any comments and ideas. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts Leiter EDV Leopoldstraße 15 80802 München

1 0

wineps: clipping bug; clipping performance
by Wolfgang Walter 16 Dec '08

16 Dec '08

Hello, as I wrote clipping in wineps.drv has a bug. Wine does only consider the clipping region and not the meta region. It should combine them. This is a bug which hurts us with a real windows application. I sent a patch which which corrects this. My patch also addressed a general performance problem with all postscript printers from Kyocera concerning non trivial clipping regions. Even if you use ghostscripts pxlmono/pxlcolor driver the generated PCL XL code may lead to errors on our Kyocera and HP printers because the clipping path gets to expensive. I have not received any comment yet. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts Leiter EDV Leopoldstraße 15 80802 München

2 2

Canonical and wine
by Dan Kegel 16 Dec '08

16 Dec '08

http://www.technewsworld.com/rsstory/65431.html quotes Gerry Carr, marketing manager at Canonical: "We aren't considering a pitch about using Wine or Parallels like on a Mac. There is no real look at Wine. It doesn't always work well. So this won't win over users to the benefits of Linux," So there you go. Canonical will think about Wine once it always works well.

14 20

Re: [resend5] gdi32/tests: Add a test fot GdiGetCodePage().
by Paul Vriens 16 Dec '08

16 Dec '08

ByeongSik Jeon wrote: > --- > dlls/gdi32/tests/Makefile.in | 2 +- > dlls/gdi32/tests/font.c | 156 ++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 157 insertions(+), 1 deletions(-) > > > ------------------------------------------------------------------------ > > Hi, I applied these tests to my local box (no other patches) and the test fails for me. Or to but it more correct some (all?) of the todo_wine's succeeded. I then removed the todo_wine's from your tests and I don't have failures anymore. The fact that the tests fails for me (and probably for others as well) could mean the patch won't be committed (unless it succeeds on AJ's machine of course). -- Cheers, Paul.

1 0

Re: oleaut32/tests: add tests for OleLoadPictureFile(Ex) and OleLoadPicurePath (resend) [3/3]
by Paul Vriens 16 Dec '08

16 Dec '08

Jeremy Drake wrote: > This integrates the scenarios that I wasn't testing from Nikolay Sivov's > patch to the tests of 12/7. Also works around some issues I was running > into trying to write wide strings as L"foo". > > --- > dlls/oleaut32/tests/olepicture.c | 311 ++++++++++++++++++++++++++++++++++++++ > 1 files changed, 311 insertions(+), 0 deletions(-) > > diff --git a/dlls/oleaut32/tests/olepicture.c b/dlls/oleaut32/tests/olepicture.c > index 2b5b8bb..2929bd7 100644 > --- a/dlls/oleaut32/tests/olepicture.c > +++ b/dlls/oleaut32/tests/olepicture.c > @@ -489,6 +489,315 @@ static void test_OleCreatePictureIndirect(void) > IPicture_Release(pict); > } > > +static void test_VerifyPictureType(IDispatch *pdisp, short expectedtype, int caller_line) > +{ > + IPicture *pict; > + HRESULT hr; > + short type; > + pict = (void*)0xdeadbeef; > + hr = IDispatch_QueryInterface(pdisp, &IID_IPicture, (LPVOID*)&pict); > + ok(hr == S_OK, "hr %08x\n", hr); > + ok(pict != (void*)0xdeadbeef && pict != NULL, "pict ptr, caller line %d\n", caller_line); > + > + if (SUCCEEDED(hr)) > + { > + type = 0xdead; > + hr = IPicture_get_Type(pict, &type); > + ok(hr == S_OK, "hr %08x, caller line %d\n", hr, caller_line); > + ok(type == expectedtype, "type %hd, expected %hd, caller line %d\n", type, expectedtype, caller_line); > + > + IPicture_Release(pict); > + } > +} > + > +static const WCHAR nopath[] = { '\\', 'n', 'o', 'p', 'a', 't', 'h', 0 }; > +static void test_OleLoadPictureFile(void) > +{ > + IDispatch *disp; > + HRESULT hr; > + char filename[MAX_PATH]; > + VARIANT varFilename; > + HANDLE file; > + DWORD written; > + DWORD widestringlen; > + BSTR tmp = NULL, tmp2 = NULL; > + > + GetTempFileNameA(".", "gif", 0, filename); > + file = CreateFileA(filename, GENERIC_READ|GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, 0); > + ok(file != INVALID_HANDLE_VALUE, "file creation error %u\n", GetLastError()); > + if (file == INVALID_HANDLE_VALUE) return; > + WriteFile(file, gif4pixel, sizeof(gif4pixel), &written, NULL); > + ok(written == sizeof(gif4pixel), "write\n"); > + > + VariantInit(&varFilename); > + V_VT(&varFilename) = VT_ERROR; > + V_ERROR(&varFilename) = DISP_E_PARAMNOTFOUND; > + > + todo_wine > + { > + disp = (void*)0xdeadbeef; > + hr = OleLoadPictureFileEx(varFilename, 2, 2, LP_DEFAULT, &disp); > + ok(hr == S_OK, "hr %08x\n", hr); > + ok(disp != (void*)0xdeadbeef, "dispatch ptr\n"); > + > + if (disp != (void*)0xdeadbeef) > + { > + test_VerifyPictureType(disp, PICTYPE_NONE, __LINE__); > + IDispatch_Release(disp); > + } > + } > + > + > + widestringlen = MultiByteToWideChar(CP_ACP, 0, filename, -1, NULL, 0); > + ok(widestringlen != 0, "determining wide string length error %u\n", GetLastError()); > + if (widestringlen == 0) return; > + V_VT(&varFilename) = VT_BSTR; > + V_BSTR(&varFilename) = SysAllocStringLen(NULL, widestringlen - 1); > + ok(MultiByteToWideChar(CP_ACP, 0, filename, -1, V_BSTR(&varFilename), widestringlen), > + "filename to wide string conversion error %u\n", GetLastError()); > + > + disp = (void*)0xdeadbeef; > + todo_wine > + { > + hr = OleLoadPictureFile(varFilename, &disp); > + ok(hr == CTL_E_PERMISSIONDENIED, "hr %08x\n", hr); > + } > + ok(disp == (void*)0xdeadbeef, "dispatch ptr\n"); > + > + CloseHandle(file); > + > + disp = (void*)0xdeadbeef; > + todo_wine > + { > + hr = OleLoadPictureFileEx(varFilename, 2, 2, LP_DEFAULT, &disp); > + ok(hr == S_OK, "hr %08x\n", hr); > + ok(disp != (void*)0xdeadbeef && disp != NULL, "dispatch ptr\n"); > + > + if (SUCCEEDED(hr)) > + { > + test_VerifyPictureType(disp, PICTYPE_BITMAP, __LINE__); > + IDispatch_Release(disp); > + } > + } > + > + todo_wine > + { > + disp = (void*)0xdeadbeef; > + hr = OleLoadPictureFile(varFilename, &disp); > + ok(hr == S_OK, "hr %08x\n", hr); > + ok(disp != (void*)0xdeadbeef && disp != NULL, "dispatch ptr\n"); > + > + if (SUCCEEDED(hr)) > + { > + test_VerifyPictureType(disp, PICTYPE_BITMAP, __LINE__); > + IDispatch_Release(disp); > + } > + } > + > + ok(MoveFileA(filename, "33"), "move file\n"); > + > + file = CreateFileA(filename, GENERIC_READ|GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, 0); > + ok(file != INVALID_HANDLE_VALUE, "file creation error %u\n", GetLastError()); > + if (file != INVALID_HANDLE_VALUE) > + { > + WriteFile(file, "this is not a valid picture", 28, &written, NULL); > + ok(written == 28, "write\n"); > + CloseHandle(file); > + > + disp = (void*)0xdeadbeef; > + todo_wine > + { > + hr = OleLoadPictureFile(varFilename, &disp); > + ok(hr == CTL_E_INVALIDPICTURE, "hr %08x\n", hr); > + ok(disp == NULL, "dispatch ptr\n"); /* XXX this one is not unmodified!! */ > + } > + DeleteFileA(filename); > + } > + > + tmp = SysAllocString(nopath); > + ok(tmp != NULL, "SysAllocString\n"); > + if (tmp != NULL) > + { > + hr = VarBstrCat(V_BSTR(&varFilename), tmp, &tmp2); > + if (SUCCEEDED(hr)) > + { > + SysFreeString(V_BSTR(&varFilename)); > + V_BSTR(&varFilename) = tmp2; > + > + disp = (void*)0xdeadbeef; > + todo_wine > + { > + hr = OleLoadPictureFile(varFilename, &disp); > + ok(hr == CTL_E_PATHNOTFOUND, "hr %08x\n", hr); > + } > + ok(disp == (void*)0xdeadbeef, "dispatch ptr\n"); > + } > + > + SysFreeString(tmp); > + } > + > + VariantClear(&varFilename); > + VariantInit(&varFilename); > + V_VT(&varFilename) = VT_I4; > + V_I4(&varFilename) = 33; > + > + todo_wine > + { > + disp = (void*)0xdeadbeef; > + hr = OleLoadPictureFile(varFilename, &disp); > + ok(hr == S_OK, "hr %08x\n", hr); > + ok(disp != (void*)0xdeadbeef && disp != NULL, "dispatch ptr\n"); > + > + if (SUCCEEDED(hr)) > + { > + test_VerifyPictureType(disp, PICTYPE_BITMAP, __LINE__); > + IDispatch_Release(disp); > + } > + } > + ok(V_VT(&varFilename) == VT_I4 && V_I4(&varFilename) == 33, "variant unmodified\n"); > + > + DeleteFileA("33"); > + > + VariantClear(&varFilename); > +} > + > +static void test_OleLoadPicturePath(void) > +{ > + static const WCHAR fileproto[] = { 'f','i','l','e',':','/','/',0 }; > + IDispatch *disp; > + HRESULT hr; > + char filename[MAX_PATH]; > + char absfile[MAX_PATH]; > + HANDLE file; > + DWORD written; > + DWORD widestringlen; > + BSTR bstrname = NULL; > + BSTR tmp = NULL, tmp2 = NULL; > + > + GetTempFileNameA(".", "gif", 0, filename); > + GetFullPathNameA(filename, MAX_PATH, absfile, NULL); > + file = CreateFileA(filename, GENERIC_READ|GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, 0); > + ok(file != INVALID_HANDLE_VALUE, "file creation error %u\n", GetLastError()); > + if (file == INVALID_HANDLE_VALUE) return; > + WriteFile(file, gif4pixel, sizeof(gif4pixel), &written, NULL); > + ok(written == sizeof(gif4pixel), "write\n"); > + > + widestringlen = MultiByteToWideChar(CP_ACP, 0, absfile, -1, NULL, 0); > + ok(widestringlen != 0, "determining wide string length error %u\n", GetLastError()); > + if (widestringlen == 0) return; > + bstrname = SysAllocStringLen(NULL, widestringlen - 1); > + ok(MultiByteToWideChar(CP_ACP, 0, absfile, -1, bstrname, widestringlen), > + "filename to wide string conversion error %u\n", GetLastError()); > + > + disp = (void*)0xdeadbeef; > + hr = OleLoadPicturePath(bstrname, NULL, 0, 0, &IID_IDispatch, (LPVOID*)&disp); > + if (hr == E_UNEXPECTED) > + { > + /* E_UNEXPECTED is returned from OleLoadPicturePath on win95 without IE installed */ > + win_skip("OleLoadPicturePath seems to not work on this platform. No IE?\n"); > + CloseHandle(file); > + DeleteFileA(filename); > + return; > + } > + ok(hr == INET_E_DATA_NOT_AVAILABLE /*>=XP*/ || > + hr == E_FAIL /*<=2k*/, "hr %08x\n", hr); > + todo_wine ok(disp == NULL, "dispatch ptr\n"); > + > + CloseHandle(file); > + > + disp = (void*)0xdeadbeef; > + todo_wine > + { > + hr = OleLoadPicturePath(bstrname, NULL, 0, 0, &IID_IDispatch, (LPVOID*)&disp); > + ok(hr == S_OK, "hr %08x\n", hr); > + ok(disp != NULL && disp != (void*)0xdeadbeef, "dispatch ptr\n"); > + > + if (SUCCEEDED(hr)) > + { > + test_VerifyPictureType(disp, PICTYPE_BITMAP, __LINE__); > + IDispatch_Release(disp); > + } > + } > + > + disp = (void*)0xdeadbeef; > + todo_wine > + { > + tmp = SysAllocString(fileproto); > + hr = VarBstrCat(tmp, bstrname, &tmp2); > + SysFreeString(tmp); > + tmp = NULL; > + > + > + hr = OleLoadPicturePath(tmp2, NULL, 0, 0, &IID_IDispatch, (LPVOID*)&disp); > + ok(hr == S_OK, "hr %08x\n", hr); > + ok(disp != NULL && disp != (void*)0xdeadbeef, "dispatch ptr\n"); > + > + if (SUCCEEDED(hr)) > + { > + test_VerifyPictureType(disp, PICTYPE_BITMAP, __LINE__); > + IDispatch_Release(disp); > + } > + SysFreeString(tmp2); > + tmp2 = NULL; > + } > + > + > + widestringlen = MultiByteToWideChar(CP_ACP, 0, filename, -1, NULL, 0); > + ok(widestringlen != 0, "determining wide string length error %u\n", GetLastError()); > + if (widestringlen == 0) return; > + tmp = SysAllocStringLen(NULL, widestringlen - 1); > + ok(MultiByteToWideChar(CP_ACP, 0, filename, -1, tmp, widestringlen), > + "filename to wide string conversion error %u\n", GetLastError()); > + > + disp = (void*)0xdeadbeef; > + > + todo_wine > + { > + hr = OleLoadPicturePath(tmp, NULL, 0, 0, &IID_IDispatch, (LPVOID*)&disp); > + ok(hr == INET_E_UNKNOWN_PROTOCOL /*>= XP*/ || > + hr == E_FAIL /*<= 2k*/, "hr %08x\n", hr); > + ok(disp == NULL, "dispatch ptr\n"); > + SysFreeString(tmp); > + tmp = NULL; > + } > + > + file = CreateFileA(filename, GENERIC_READ|GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, 0); > + ok(file != INVALID_HANDLE_VALUE, "file creation error %u\n", GetLastError()); > + if (file != INVALID_HANDLE_VALUE) > + { > + WriteFile(file, "this is not a valid picture", 28, &written, NULL); > + ok(written == 28, "write\n"); > + CloseHandle(file); > + > + disp = (void*)0xdeadbeef; > + todo_wine > + { > + hr = OleLoadPicturePath(bstrname, NULL, 0, 0, &IID_IDispatch, (LPVOID*)&disp); > + ok(hr == E_FAIL, "hr %08x\n", hr); > + ok(disp == NULL, "dispatch ptr\n"); > + } > + } > + > + DeleteFileA(filename); > + > + tmp = SysAllocString(nopath); > + hr = VarBstrCat(bstrname, tmp, &tmp2); > + SysFreeString(bstrname); > + bstrname = tmp2; > + > + disp = (void*)0xdeadbeef; > + todo_wine > + { > + hr = OleLoadPicturePath(bstrname, NULL, 0, 0, &IID_IDispatch, (LPVOID*)&disp); > + ok(hr == INET_E_RESOURCE_NOT_FOUND /*>=XP*/ || > + hr == E_FAIL /*<=2k*/, "hr %08x\n", hr); > + ok(disp == NULL, "dispatch ptr\n"); > + } > + > + SysFreeString(tmp); > + SysFreeString(bstrname); > +} > + > static void test_apm() > { > OLE_HANDLE handle; > @@ -671,6 +980,8 @@ START_TEST(olepicture) > > test_Invoke(); > test_OleCreatePictureIndirect(); > + test_OleLoadPictureFile(); > + test_OleLoadPicturePath(); > test_Render(); > } > Hi Jeremy, Could you please use spaces instead of tabs. I know that this file already has some tabs but please don't add more. -- Cheers, Paul.

1 0

patch to fix bug 8072, but need some help with tests
by ricardo filipe 16 Dec '08

16 Dec '08

hi guys! after many days tinkering on this i managed to make the notification work! (pump fist) now media player classic correctly displays the files when browsing on "Open File" with no native libraries :) i would like some feedback on the patch though because there is some "repeated" code and there is a LPITEMIDLIST cast that i've tried to take out using pointers, but i didn't manage to since the variable is a constant... but you guys might know some other way to not use the cast, no? also i would like some help doing tests for this because i'm sure AJ won't accept this without tests. thanks :) _________________________________________________________________ Receba GRÁTIS as mensagens do Messenger no seu celular quando você estiver offline. Conheça o MSN Mobile! http://mobile.live.com/signup/signup2.aspx?lc=pt-br

1 0

Re: amstream: Some fixes
by Alexandre Julliard 15 Dec '08

15 Dec '08

Christian Costa <titan.costa(a)wanadoo.fr> writes: > commit bb5a3b161d69bb2dc0e5be8cbbc5268dbc7d513f > Author: Christian Costa <titan.costa(a)wanadoo.fr> > Date: Sun Dec 14 00:46:24 2008 +0100 > > Some fixes. Please avoid white space changes, and provide a proper log message, "some fixes" doesn't say anything about the change. -- Alexandre Julliard julliard(a)winehq.org

2 1

RE: d3dxof: Add a test to dump an X object data (enabled when objects.txt and templates.txt are present) (try 2)
by Stefan Dösinger 15 Dec '08

15 Dec '08

Hi all, I just wanted to take the opportunity to draw some attention to Christian's great work on these higher-level DirectX libraries. I didn't really notice it until I accidentally ran some dx8 sdk samples with the builtin d3dxof and it just worked instead of complaining about lots of stubs. His whole work has been pretty silent, but I think Christian deserves lots of credits here. Good work! > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Christian Costa > Sent: Sunday, December 14, 2008 6:53 PM > To: wine-patches(a)winehq.org > Subject: d3dxof: Add a test to dump an X object data (enabled when > objects.txt and templates.txt are present) (try 2) > > Fixed stdio include that broke make dep.

2 1

Re: msi: improve a debugging message
by James Hawkins 15 Dec '08

15 Dec '08

On Mon, Dec 15, 2008 at 1:15 PM, Austin English <austinenglish(a)gmail.com> wrote: > -- > -Austin > Are you adding this because you've been debugging the msi db code? Knowing the row number that we failed to insert is not helpful. In most cases, this message is harmless and should be a warn or removed completely as this is hit if the row already exists in the db (common). Please don't send in a patch for that change, as I'm waiting till I write an exhaustive set of tests for transforms before removing the message. -- James Hawkins

1 0

Re: [4/10] WineD3D: Some GL_EXT_fog_coord prototype fixes
by Henri Verbeet 15 Dec '08

15 Dec '08

2008/12/15 Stefan Dösinger <stefan(a)codeweavers.com>: > -typedef void (WINE_GLAPI * PGLFNGLFOGCOORDFVEXTPROC) (GLfloat intesity); > -typedef void (WINE_GLAPI * PGLFNGLFOGCOORDDEXTPROC) (GLfloat intesity); > -typedef void (WINE_GLAPI * PGLFNGLFOGCOORDDVEXTPROC) (GLfloat intesity); > +typedef void (WINE_GLAPI * PGLFNGLFOGCOORDFVEXTPROC) (const GLfloat *intesity); > +typedef void (WINE_GLAPI * PGLFNGLFOGCOORDDEXTPROC) (GLdouble intesity); > +typedef void (WINE_GLAPI * PGLFNGLFOGCOORDDVEXTPROC) (const GLdouble *intesity); > You might as well fix the parameter names while you're at it :-)

1 0

Re: user32: Sign-compare warnings fix (Try 2)
by James Mckenzie 15 Dec '08

15 Dec '08

-----Original Message----- >From: Alexandre Julliard <julliard(a)winehq.org> >Sent: Dec 15, 2008 5:25 AM >To: Andrew Talbot <andrew.talbot(a)talbotville.com> >Cc: wine-devel(a)winehq.org >Subject: Re: user32: Sign-compare warnings fix (Try 2) > >Andrew Talbot <andrew.talbot(a)talbotville.com> writes: > >> diff --git a/dlls/user32/dialog.c b/dlls/user32/dialog.c >> index 9dd9083..4ea1959 100644 >> --- a/dlls/user32/dialog.c >> +++ b/dlls/user32/dialog.c >> @@ -84,9 +84,9 @@ typedef struct >> /* Radio button group */ >> typedef struct >> { >> - UINT firstID; >> - UINT lastID; >> - UINT checkID; >> + INT firstID; >> + INT lastID; >> + INT checkID; >> } RADIOGROUP; > >This change would need a test case. > Alexandre/Andrew: I don't think this change is necessary, unless there is checking against a -1 somewhere in the code. Also, I would like to see an array of 32K or so radio buttons somewhere in Windows code. James McKenzie

1 0

Re: user32: Sign-compare warnings fix (Try 2)
by Alexandre Julliard 15 Dec '08

15 Dec '08

Andrew Talbot <andrew.talbot(a)talbotville.com> writes: > diff --git a/dlls/user32/dialog.c b/dlls/user32/dialog.c > index 9dd9083..4ea1959 100644 > --- a/dlls/user32/dialog.c > +++ b/dlls/user32/dialog.c > @@ -84,9 +84,9 @@ typedef struct > /* Radio button group */ > typedef struct > { > - UINT firstID; > - UINT lastID; > - UINT checkID; > + INT firstID; > + INT lastID; > + INT checkID; > } RADIOGROUP; This change would need a test case. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: richedit: OpenClipboard doesn't need to be given a window handle.
by Alexandre Julliard 15 Dec '08

15 Dec '08

"Dylan Smith" <dylan.ah.smith(a)gmail.com> writes: > I have been looking to reduce the number of places where window handles > are used, so I did a relay trace to see if native richedit controls gave > a non-null handle when calling OpenClipboard. The relay trace showed > that NULL was being used, even for normal windowed richedit controls. Please don't do that. The calls that native makes are part of the internal workings that you are not supposed to peek into. You should treat native as a black box and only replicate behavior that can be observed through test cases. -- Alexandre Julliard julliard(a)winehq.org

1 0

Wine64 hello world app runs!
by Maarten Lankhorst 15 Dec '08

15 Dec '08

Hi guys, I can finally report success on the first ever win64 program running on wine. The program was a textbook classic, but to make it work gcc had to be changed a lot. This was done by Kai Tietz, who has put a lot of effort in the task of making gcc accept the calling convention. There are still a lot of things which should be done before this will be able to get into mainline though. My repository is at http://repo.or.cz/w/wine/wine64.git , but in order to actually get it working you need gcc checked out from subversion with some experimental patches. They are expected to get merged soon, so until then it is not recommended to even try. :) There are a bunch of things in my tree which are not merged with mainline. A few of them are hacks (disabling SEGV handling for example). There are also some changes which should be accepted, but still need some work. For example wineserver, AJ wants something with regards to fd handling, but I didn't find him clear on what exactly. va_list also is incompatible, and should be replaced with ms_va_list where appropiate. Once again, thanks to Kai Tietz for making this possible. Cheers, Maarten.

2 2

Regression - Photoshop CS3 tryout won't install anymore?
by Dan Kegel 15 Dec '08

15 Dec '08

Bleah: http://bugs.winehq.org/show_bug.cgi?id=15590 Golly. After all the work we put into getting Photoshop running, I hope we don't regress...

1 0

IE, mshtml.dll, oledb32.dll and vulnerability in XML parsing / data binding
by Saulius Krasuckas 14 Dec '08

14 Dec '08

Hello, I noticed article about some IE issue: [1] And couldn't stop smiling at the amount and spectre of the workarounds needed to prevent attacks ;) And maybe Jacek (or some other mshtml guy) could test Wine's html engine against the external test case [2] to see whether we are better at handling [3] such XMLs. [1] http://www.pcmag.com/article2/0,2817,2336831,00.asp [2] http://www.milw0rm.com/exploits/7410 [3] http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4844

1 0

Re: amstream: Some fixes
by Vincent Povirk 14 Dec '08

14 Dec '08

Please send a separate patch for each group of related changes, per http://winehq.org/sending_patches Vincent Povirk On Sun, Dec 14, 2008 at 12:07 PM, Christian Costa <titan.costa(a)wanadoo.fr> wrote: > > > > >

1 0

Re: [resend2] gdi32/tests: Add a test for GdiGetCodePage().
by Peter Oberndorfer 14 Dec '08

14 Dec '08

On Sonntag 14 Dezember 2008, ByeongSik Jeon wrote: > http://bugs.winehq.org/show_bug.cgi?id=16325 > > 2008-12-14 (Sun), 13:34 +0100, Paul Vriens wrote: > > Could you turn the skip in this piece of code: > > > > + if (!pGdiGetCodePage) > > + { > > + skip("GdiGetCodePage not available on this platform\n"); > > + return; > > + } > > > > into a win_skip? That way we fail if the function is not available in Wine. > > > I changed it to the trace(). > > Another thing I'm not sure about though is that in the for() loop you > > don't do a DeleteObject( hfont ). Is that only needed at the end? > > Thanks. > > --- > dlls/gdi32/tests/Makefile.in | 2 +- > dlls/gdi32/tests/font.c | 153 ++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 154 insertions(+), 1 deletions(-) > Hi, some small style notes. > + CHARSETINFO csi; > + > + if ( ( ansi_assoc == -1 || oem_assoc == -1 ) && > + RegOpenKeyA ( HKEY_LOCAL_MACHINE, associated_charset, &hkey) == ERROR_SUCCESS ) > + { > + RegQueryInfoKeyA ( hkey, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, &max_data_len, NULL, NULL ); > + data = HeapAlloc ( GetProcessHeap(), 0, max_data_len ); > + please try to use similar spacing like other parts of the file no space before and after '(' when calling a function. > + case MAC_CHARSET: > + acp = GetACP(); > + cp = ( acp == 932 || acp == 936 || acp == 949 || acp == 950 )? 1252 : CP_ACP; > + break; Please try to avoid trailing whitespace > + JOHAB_CHARSET, > + VISCII_CHARSET, > + TCVN_CHARSET, > + KOI8_CHARSET, > + ISO3_CHARSET, > + ISO4_CHARSET, > + ISO10_CHARSET, > + CELTIC_CHARSET, also some trailing whitespace here. Thanks for you patch. Greetings Peter

1 0

Re: [resend2] gdi32/tests: Add a test for GdiGetCodePage().
by Paul Vriens 14 Dec '08

14 Dec '08

ByeongSik Jeon wrote: > http://bugs.winehq.org/show_bug.cgi?id=16325 > > 2008-12-14 (Sun), 13:34 +0100, Paul Vriens wrote: >> Could you turn the skip in this piece of code: >> >> + if (!pGdiGetCodePage) >> + { >> + skip("GdiGetCodePage not available on this platform\n"); >> + return; >> + } >> >> into a win_skip? That way we fail if the function is not available in Wine. >> > I changed it to the trace(). >> Another thing I'm not sure about though is that in the for() loop you >> don't do a DeleteObject( hfont ). Is that only needed at the end? > > Thanks. > > --- > dlls/gdi32/tests/Makefile.in | 2 +- > dlls/gdi32/tests/font.c | 153 ++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 154 insertions(+), 1 deletions(-) > > > ------------------------------------------------------------------------ > > Hi, The trace() is worse. The first one should be a win_skip() the second one a skip(), so: if (!pGdiGetCodePage) { win_skip("GdiGetCodePage not available on this platform\n"); return; } if (!is_font_installed( "Arial" ) ) { skip("Arial is not installed\n"); return; } The win_skip() means we skip the test on Windows if this function is not present but it will fail on Wine if this function is not there(exported). This will make sure that nobody messes up this function . The skip() will make sure we skip the tests on all platforms if Arial is not available. For that second item. Isn't it enough to put the GetDC() before the for-loop and the ReleaseDC after the for-loop? -- Cheers, Paul.

1 0

Re: [resend] gdi32/tests: Add a test for GdiGetCodePage().
by Paul Vriens 14 Dec '08

14 Dec '08

ByeongSik Jeon wrote: > http://bugs.winehq.org/show_bug.cgi?id=16325 > --- > dlls/gdi32/tests/Makefile.in | 2 +- > dlls/gdi32/tests/font.c | 152 ++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 153 insertions(+), 1 deletions(-) > > > ------------------------------------------------------------------------ > > Hi, Could you turn the skip in this piece of code: + if (!pGdiGetCodePage) + { + skip("GdiGetCodePage not available on this platform\n"); + return; + } into a win_skip? That way we fail if the function is not available in Wine. Another thing I'm not sure about though is that in the for() loop you don't do a DeleteObject( hfont ). Is that only needed at the end? -- Cheers, Paul.

1 0

No response to updated patch for gdi32/StretchDIBits
by Mathias Kosch 13 Dec '08

13 Dec '08

Hallo! About two weeks ago I tried to hand in a (corrected version of my) patch for "StretchDIBits" [1]. However it isn't accepted until now and I didn't yet notice any response. Would someone please tell me what's wrong or if it was just missed out accidentally? [1] http://www.winehq.org/pipermail/wine-patches/2008-September/062221.html -- Mathias Kosch <info(a)mkosch.de> | http://www.mkosch.de/ RSA Public Key: http://www.mkosch.de/pubkey Roboter zum selber bauen: http://www.heise.de/ct/projekte/ct-bot/

2 2

Re: Bugfix-patches for dlls/comdlg32/filedlg.c
by Paul Vriens 13 Dec '08

13 Dec '08

Elias wrote: > - Fix for bugzilla bug 16332 > crash in file dialog if the previous selected folder is deleted > > No checking was done on the selected initial directory for the > open-file dialog, which resulted in a stack overflow if the directory > was not present. > > - Prevent free on NULL values > A typo made the CommDlg32 leak memory and potenially free NULL values. > Checks added/changed in two places. > > > > ------------------------------------------------------------------------ > > Hi, Apart from the remark that Austin made about the 'only one patch per e-mail" I think the part about the 'free on NULL values' can be improved. MemFree is a wrapper around HeapFree and there is no need to check for NULL when calling HeapFree. So it's better to get rid of the whole if() altogether (and correctly indent the MemFree of course). -- Cheers, Paul.

1 0

Re : RFC: Wine Icons
by Hervÿffffe9 Chanal 13 Dec '08

13 Dec '08

> On Friday 14 November 2008 19:13:32 Juan Lang wrote: > > > > I find that a bit alarming. I'm sure he's working very hard, and doing > > > good stuff, but I don't think Wine should be redrawing anything. Not > > > when we have Tango around - it's designed to try create some consistency > > > through standardisation. IMO standards are really good! - we use them if > > > we possibly can. > > > > The trouble is that the Tango icon set doesn't cover all the icons > > Wine needs. There's no Tango icon for regedit, for instance. > > IIRC there's Tango icon sets for specific applications. If we're doing our own > icons anyway, we could try to keep them coherent with the rest of the Tango > look and get the icons upstream to Tango. > > This seems like the most reasonable approach. Of course the only things I > usually paint are walls so I'd have no idea how easy it is to match the Tango > specs when designing icons. > > Cheers, > Kai First of all, sorry to not have answered before and for my poor English, but I was quite busy these past months and I didn't see all these messages since today. I realize that the two patch I sent an hour ago are not the best answer to all these issues (I think these two newer icons look nicer in the open dialog boxes anyway) and that all theses points have to be discussed. When remaking icons, I tried to add a bit of consistency while improving a bit the icons. Obviously, I missed something. Reading all theses remarks, I agree that a better way to handle these icons are to use the Tango ones when they are available. As it was stated, including them is not straightforward and I haven't the skill to work on including these libraries into the wine tree. I hope somebody will work on these issues. In the meanwhile, maybe I'll try to improve the others shell32 icons as the bin or the computer which I found awful in this size but I don't know if it's a good idea. Cheers, Hervé

4 5

Re: Bugfix-patches for dlls/comdlg32/filedlg.c
by Austin English 13 Dec '08

13 Dec '08

On Fri, Dec 12, 2008 at 12:42 PM, Elias <elno0959(a)student.su.se> wrote: > > - Fix for bugzilla bug 16332 > crash in file dialog if the previous selected folder is deleted > > No checking was done on the selected initial directory for the > open-file dialog, which resulted in a stack overflow if the directory > was not present. > > - Prevent free on NULL values > A typo made the CommDlg32 leak memory and potenially free NULL values. > Checks added/changed in two places. > > -- > Fortune-of-the-Mail: > Lady, lady, should you meet > One whose ways are all discreet, > One who murmurs that his wife > Is the lodestar of his life, > One who keeps assuring you > That he never was untrue, > Never loved another one... > Lady, lady, better run! > -- Dorothy Parker, "Social Note" > > > > Please only patch per e-mail. -- -Austin

1 1

Re: Add DIB Test for Polyline
by Austin English 13 Dec '08

13 Dec '08

2008/12/12 Sergey Novosyolov <chi(a)etersoft.ru>: > > > > > You need to add this file to the list of tests in dlls/gdi32/tests/Makefile.in. -- -Austin

1 0

Where to put new (vfw32) compatibility tests that wine fails?
by Hoehle, Joerg-Cyril 13 Dec '08

13 Dec '08

Hi, I have attached to http://bugs.winehq.org/show_bug.cgi?id=15915#c3 ("Cinepak reportedly not installed") the skeleton of a test that wine fails but win2k passes. I could turn this into a format that git and wine-patches understands, if I knew the answer to these questions: o Is it "right" to add compatibility tests that wine is known to fail now (people are already complaining that a wine build does not pass all tests), or are the tests considered more like regression aids and should be added only when they succeed for the first time? o What directory to add this test specific to vfw32 (or rather iccvid) ? winmm seems to test sound only, although in principle, it could be there as well. o Which files to change (beside Makefile.in and testlist.c) so that the patch builds and becomes fully integrated into the wine source tree if it were located in a new file, instead of e.g. being added to tests/mmio.c? Thank you, Jörg Höhle

2 1

Serial Fixes
by Uwe Bonnes 12 Dec '08

12 Dec '08

Hello Wolfgang, nice findings and fixes around the serial driver! What application do you test against? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

RE: winmm: Sign-compare warning fix (Resend)
by James Mckenzie 12 Dec '08

12 Dec '08

Michael Karcher <wine(a)mkarcher.dialup.fu-berlin.de> at: Dec 12, 2008 9:23 AM (MST) wrote about: RE: winmm: Sign-compare warning fix (Resend) > >Am Freitag, den 12.12.2008, 09:07 -0700 schrieb James Mckenzie: >> > unsigned int i; >> > >> > ... >> > >> > for (i = sizeof(foo) / sizeof(foo[0]) - 1; ~i; --i) >> > >> >Tested? No. >> >Readable? Don't ask me... :-) >> I understood it, but is not the goal to avoid the use of C++ constructs in WINE code? >There is no C++ construct in that code. Still i-- would do the same and >is more idiomatic C. > >> The real question is why convert a for loop to a while loop? >After the last iteration, the --i (or i--) overflows. In a for loop, the >step statement (the third statement in the loop head) is always executed >before the test (the second statement in the loop head), so there is no >way to prevent the overflow. While this is not a problem per se, as >overflow of unsigned variables is well-defined, testing for "overflow >just happended" tends to be more confusing to the readers than testing >for "is at the end". > >If you use a while loop instead, you can arrange the test to be executed >*before* the step is performed, so you have to abort on "i == 0 just >finished" insted of "i == ~0U is next", the former being easier to >understand. > This is a definite improvement. Glad you caught it and thank you for the lesson in the use of structures vice arrays. I'll take a close look at the code and your change this weekend. I was caught by the use of sizeof(array[0]) vice sizeof(struct[0]), which do yeild different results. James McKenzie

1 0

RE: winmm: Sign-compare warning fix (Resend)
by James Mckenzie 12 Dec '08

12 Dec '08

Peter Rosin <peda(a)axentia.se> at: Dec 12, 2008 4:27 AM wrote about: RE: winmm: Sign-compare warning fix (Resend) > >> But how would you then fix the sign-compare violation, or >> would you just let this one go? > >If you want it to be more compact: > > unsigned int i; > > ... > > for (i = sizeof(foo) / sizeof(foo[0]) - 1; ~i; --i) > >Tested? No. >Readable? Don't ask me... :-) I understood it, but is not the goal to avoid the use of C++ constructs in WINE code? The real question is why convert a for loop to a while loop? My guess is to avoid a possible empty or zero length foo. Of course, there should be a check before this for an empty or misformed foo[0] avoiding a divide by zero error. James McKenzie

2 1

Re: [1\3] setupapi: add CM_Locate_DevNodeA\W stubs
by Stefan Leichter 12 Dec '08

12 Dec '08

Am Friday 12 December 2008 01:42 schrieb ricardo filipe: >--- a/dlls/setupapi/setupapi.spec >+++ b/dlls/setupapi/setupapi.spec >@@ -53,7 +53,7 @@ > @ stub CM_Free_Res_Des > @ stub CM_Free_Res_Des_Ex > @ stub CM_Free_Res_Des_Handle >-@ stub CM_Get_Child >+@ stdcall CM_Get_Child(ptr long long) > @ stub CM_Get_Child_Ex > @ stub CM_Get_Class_Key_NameA > @ stub CM_Get_Class_Key_NameW this part is wrong here as it is in the second patch too .. Stefan

2 1

Re: mshtml: Add some interfaces in mshtml.idl (try 2) (resend)
by Konstantin Kondratyuk 12 Dec '08

12 Dec '08

On Thursday 11 December 2008 17:28:03 Konstantin Kondratyuk wrote: > Add: > ILineInfo > IDisplayPointer > IDisplayPointer > IHTMLComputedStyle > IDisplayServices > IMarkupServices This patch is wrong. Please, ignore it. -- Best regards, Konstantin Kondratyuk.

1 0

Re: winmm: Sign-compare warning fix (Resend)
by Andrew Talbot 12 Dec '08

12 Dec '08

On Fri Dec 12 10:29 , Michael Stefaniuc <mstefani(a)redhat.com> sent: >Andrew Talbot wrote: >> But how would you then fix the sign-compare violation, or would you just let this >> one go? >I had to look twice as the initial warning was in a for loop above: >Either leave it as is for now as the warning is bogus or at least add >the decrement directly to the while like this: > i = sizeof(MMDrvs) / sizeof(MMDrvs[0]); > while (i-- > 0) > { > MMDRV_ExitPerType(&MMDrvs[i], MMDRV_AUX); > >Though the later would still have to pass Alexandre's review. > >bye > michael Come to think of it, I believe Alexandre did improve one of my earlier efforts in this latter way, so I might retry with the slimmer while loop you suggest. Thanks, Michael (and Chris and Peter)! -- Andy.

1 0

Re: A nicer icon for shell32 folder
by Alexandre Julliard 12 Dec '08

12 Dec '08

Hervÿffffe9 Chanal <chanal_herve(a)yahoo.fr> writes: > It's (may) be a nicer icon for the "folder icon" of shell32. comments are welcome. I think you should keep the yellow color scheme, that's what all other folder-style icons use. > Sorry for all the mess I seem to have done. I'll try to revert my old > icons patch to the previous ones as soon as I have the time. You haven't done any mess, the svg icons are a nice improvement. The reason they don't look as good as they should is because Wine doesn't support the alpha channel, we need to fix that. -- Alexandre Julliard julliard(a)winehq.org

4 3

Re: winmm: Sign-compare warning fix (Resend)
by Andrew Talbot 12 Dec '08

12 Dec '08

On Fri Dec 12 0:58 , Michael Stefaniuc sent: >Andrew Talbot wrote: >> What is wrong with this patch, please? >If I may venture a guess: You have replaced a nice and concise for loop >into and ugly 4 line while loop. > >bye > michael > Hi Michael, Ugly? Andrew Koenig and Barbara Moo show a similar construct in their book "Accelerated C++". ;) But how would you then fix the sign-compare violation, or would you just let this one go? -- Andy.

4 3

Re: kernel32: Remove _hread16() as it is not used. Move _hwrite16() next to the other related functions.
by Alexandre Julliard 12 Dec '08

12 Dec '08

Francois Gouget <fgouget(a)free.fr> writes: > The krnl386.exe.spec file points _hread() to WIN16_hread() so that this > _hread16() function is unused. > > The naming of these implementations is a bit inconsistent but it may not > be worth a patch to fix it (but if it is I'll gladly send one). The reason for the inconsistent naming is that the xxx16 functions are 16-bit implementations usable from normal Wine code, while the WIN16_xxx ones have different calling sequences and are for use by the relay code only. That's why we had both WIN16_hread and hread16. Of course at this point we shouldn't be calling 16-bit functions from Wine code, so it no longer matters. -- Alexandre Julliard julliard(a)winehq.org

1 0

Translating to winehq.org
by Maik Schulz 12 Dec '08

12 Dec '08

Hi, I just started translating the new winehq.org to German. How would you like to receive the git patches for the translated template files? One at a time whenever I have them ready, or at the end in one batch? Also, what about obsolete content? E.g. contributing.template still lists Wine 1.x tasks (with a link to an empty Bugzilla list) as well as an empty Wine 0.9.x tasks list. Cheers, -Maik

3 2

Re: winmm: Sign-compare warning fix (Resend)
by Michael Stefaniuc 12 Dec '08

12 Dec '08

Andrew Talbot wrote: > What is wrong with this patch, please? If I may venture a guess: You have replaced a nice and concise for loop into and ugly 4 line while loop. bye michael > --- > Changelog: > winmm: Sign-compare warning fix. > > diff --git a/dlls/winmm/lolvldrv.c b/dlls/winmm/lolvldrv.c > index 794c117..946d0d0 100644 > --- a/dlls/winmm/lolvldrv.c > +++ b/dlls/winmm/lolvldrv.c > @@ -737,7 +737,7 @@ static BOOL MMDRV_ExitPerType(LPWINE_MM_DRIVER lpDrv, UINT type) > */ > void MMDRV_Exit(void) > { > - int i; > + unsigned int i; > TRACE("()\n"); > > for (i = 0; i < sizeof(MM_MLDrvs) / sizeof(MM_MLDrvs[0]); i++) > @@ -753,8 +753,11 @@ void MMDRV_Exit(void) > } > > /* unload driver, in reverse order of loading */ > - for (i = sizeof(MMDrvs) / sizeof(MMDrvs[0]) - 1; i >= 0; i--) > + i = sizeof(MMDrvs) / sizeof(MMDrvs[0]); > + while (i > 0) > { > + --i; > + > MMDRV_ExitPerType(&MMDrvs[i], MMDRV_AUX); > MMDRV_ExitPerType(&MMDrvs[i], MMDRV_MIXER); > MMDRV_ExitPerType(&MMDrvs[i], MMDRV_MIDIIN); > > -- Michael Stefaniuc Tel.: +49-711-96437-199 Consulting Communications Engineer Fax.: +49-711-96437-111 -------------------------------------------------------------------- Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei Muenchen Handelsregister: Amtsgericht Muenchen HRB 153243 Geschäftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Werner Knoblich

1 0

compiling Windows code with g++ on Linux using msvcrt - good idea? if so, how do you do it?
by foobarbaz biffblaff 11 Dec '08

11 Dec '08

Hi, I have a huge amount of Windows code that I'm porting to Linux. Wine is turning out to be a read godsend, thank you guys! Anyway, I've had tons of luck including the directory <wine_dir>/include/wine/windows in my include path. All my Windows types are there and everything is wonderful. I've even been able to link against the libraries by renaming, for example, foo.dll.so to libfoo.so and using -lfoo on the g++ command line. I actually haven't got all my functions defined so I don't know if this will actually run yet because the link isn't complete yet. My first question is whether this will work. Will all my Windows functions with function declarations defined in the windows directory and code compiled into foo.dll.so actually run? Second, I see that some of the functions I want to use are actually defined by headers in the msvcrt directory. However, this directory contains tons of header files that my system (and gcc) also have under /usr/include and gcc's own directories. I understand that msvcrt is Windows lib c, but I wonder how I'm supposed to use it with gcc to compile? I've tried -nostdinc to gcc, but the number of errors I get is enormous. It's not the end of the world if I can't use Wine's msvcrt, but if I could use it, it would define dozens more functions on which my program relies, or if its use was mandatory in order to get the functions implemented in foo.dll.so to work, then obviously I wonder how I'm supposed to compile my Windows code with Wine to make everything work? I'm sorry if this is a dumb question. I can't find a way to search the wine-devel mailing list other than with google and I can't find anything on there or other docs that answer this question, which I'm sure has been asked a million times and has a simple answer. Thank you thank you, Jeff _________________________________________________________________ Send e-mail faster without improving your typing skills. http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_speed_…

3 3

website : http://www.winehq.org/site/who gives a 404
by Paul Vriens 11 Dec '08

11 Dec '08

Hi, Just noticed that the Who is Who page is still referenced (from http://www.winehq.org/acknowledgement for example) as being on winehq.org. Wasn't this moved to the wiki? -- Cheers, Paul.

3 3

Re: wintrust: Sign-compare warnings fix
by Juan Lang 11 Dec '08

11 Dec '08

Hi Andy, - if (pbEncoded[1] + 1 > cbEncoded) + if (pbEncoded[1] + 1U > cbEncoded) Is this change necessary? The resulting code is less clear than the original, IMO. It's clearly a spurious warning: a BYTE (max value 255) + 1 can't yield a value that overflows an unsigned int, so this comparison will always do what's wanted. Same with the change here: - else if (lenLen + 2 > cbEncoded) + else if (lenLen + 2U > cbEncoded) Otherwise, this patch looks fine to me. --Juan

2 3

re: compiling Windows code with g++ on Linux using msvcrt - good idea? if so, how do you do it?
by Dan Kegel 11 Dec '08

11 Dec '08

Glad Wine is being helpful to you. If you're targeting plain old 32 bit intel-compatible linux or unix, have you considered simply using wine to run your windows binaries? That plus a very few tweaks in your source tree could get you what you want with potentially less effort. - Dan

1 0

Re: German translation for winehq.org
by Jeremy Newman 11 Dec '08

11 Dec '08

Excellent work! -Newman Maik Schulz wrote: > Hi, > > please find attached a patch for the beginning of a German translation > of the new winehq.org. More patches to follow as I go through the > remaining templates. > > Cheers, > -Maik > > > ------------------------------------------------------------------------ > >

1 0

RE: [2/4] WineD3D: Set up the shaders when delaying fixed func applying
by Stefan Dösinger 11 Dec '08

11 Dec '08

Here's an updated patch that fixes the compile issues > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Stefan Dösinger > Sent: Thursday, December 11, 2008 11:53 AM > To: wine-patches(a)winehq.org > Subject: [2/4] WineD3D: Set up the shaders when delaying fixed func > applying > > I skipped the original 2/5 patch because I found a last minute bug in > it. It should not affect the other patches though. > > Just fyi, this is my roadmap for cleaning up the fog mess this patch is > related to: > 1) Get rid of the GL_EXT_fog_coord-is-not-supported fallback and fake > the GL extension > 2) Remove the different pixel shader fog start and end optimization(and > probably reintroduce it in a cleaner way once the state_fog function is > sane) > 3) Separate the current fog state block into > fogenable+fogvertexmode+fogtablemode and fogstart-fogend > 4) Move the separated fog states into the fragment pipeline(since GLSL > and ARBfp override fog) > 5) Put the fog mode into the ps_compile_args structure to generate > shaders that can disable fog properly and support exponential fog > 6) Find some way to deal with glFogi(GL_FOG_COORDINATE_SOURCE_EXT, ...). > That part still belongs into the vertex pipe I think. > 7) the optimization removed in (2) is only needed for GLSL. We can > easilly reintroduce it once we have a full GLSL pipeline because then > the fog start and end stays independent of the pixel shader.

1 0

RE: [2/5] wined3d: baseShader.functionLength should be 0 when a NULL pFunction is passed.
by Stefan Dösinger 11 Dec '08

11 Dec '08

Do we still have a case where a shader is created with a NULL function? I think we filter that in d3d8 now and just create a vdecl > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Henri Verbeet > Sent: Thursday, December 11, 2008 11:58 AM > To: wine-patches(a)winehq.org > Subject: [2/5] wined3d: baseShader.functionLength should be 0 when a > NULL pFunction is passed. >

2 2

RE: [2/4] WineD3D: Set up the shaders when delaying fixed func applying
by Stefan Dösinger 11 Dec '08

11 Dec '08

Don't apply this patch, it has a bug and will cause a compile error > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Stefan Dösinger > Sent: Thursday, December 11, 2008 11:53 AM > To: wine-patches(a)winehq.org > Subject: [2/4] WineD3D: Set up the shaders when delaying fixed func > applying > > I skipped the original 2/5 patch because I found a last minute bug in > it. It should not affect the other patches though. > > Just fyi, this is my roadmap for cleaning up the fog mess this patch is > related to: > 1) Get rid of the GL_EXT_fog_coord-is-not-supported fallback and fake > the GL extension > 2) Remove the different pixel shader fog start and end optimization(and > probably reintroduce it in a cleaner way once the state_fog function is > sane) > 3) Separate the current fog state block into > fogenable+fogvertexmode+fogtablemode and fogstart-fogend > 4) Move the separated fog states into the fragment pipeline(since GLSL > and ARBfp override fog) > 5) Put the fog mode into the ps_compile_args structure to generate > shaders that can disable fog properly and support exponential fog > 6) Find some way to deal with glFogi(GL_FOG_COORDINATE_SOURCE_EXT, ...). > That part still belongs into the vertex pipe I think. > 7) the optimization removed in (2) is only needed for GLSL. We can > easilly reintroduce it once we have a full GLSL pipeline because then > the fog start and end stays independent of the pixel shader.

1 0

Re: jscript: Implement multiple Math functions.
by Jacek Caban 11 Dec '08

11 Dec '08

Hi Patrick, Patrick Rudolph wrote: > From 0903060f5acac3bcadc4198bd59eb2ef87f78818 Mon Sep 17 00:00:00 2001 > From: Patrick Rudolph <patrick1804(a)web.de> > Date: Wed, 10 Dec 2008 16:51:19 +0100 > Subject: jscript: Implement multiple Math functions. > > modified: math.c > modified: tests/api.js > --- > dlls/jscript/math.c | 293 +++++++++++++++++++++++++++++++++++++++------ > dlls/jscript/tests/api.js | 32 +++++ > 2 files changed, 287 insertions(+), 38 deletions(-) > > diff --git a/dlls/jscript/math.c b/dlls/jscript/math.c > index e6b7202..56ba9cf 100644 > --- a/dlls/jscript/math.c > +++ b/dlls/jscript/math.c > @@ -20,6 +20,7 @@ > #include "wine/port.h" > > #include <math.h> > +#include <sys/time.h> > > #include "jscript.h" > > @@ -57,57 +58,105 @@ static const WCHAR tanW[] = {'t','a','n',0}; > static HRESULT Math_E(DispatchEx *dispex, LCID lcid, WORD flags, DISPPARAMS *dp, > VARIANT *retv, jsexcept_t *ei, IServiceProvider *sp) > { > - FIXME("\n"); > - return E_NOTIMPL; > + if(arg_cnt(dp) > 0) { > + FIXME("invalid arg_cnt %d\n", arg_cnt(dp)); > + return E_NOTIMPL; > + } > + > + if(retv) > + num_set_val(retv, exp(1)); > + return S_OK; > } > It's a JavaScript constant, not a function (and you've implemented it as if it would be a function). The same for other constants. [...] Please send smaller patches, preferable one patch per function, and add more tests. And first of all, make sure that tests are correct... > diff --git a/dlls/jscript/tests/api.js b/dlls/jscript/tests/api.js > index 2868c0f..6430397 100644 > --- a/dlls/jscript/tests/api.js > +++ b/dlls/jscript/tests/api.js > @@ -585,6 +585,38 @@ ok(tmp === 2, "Math.pow(2, 2) = " + tmp); > tmp = Math.pow(2, 2, 3); > ok(tmp === 4, "Math.pow(2, 2, 3) = " + tmp); > > +tmp = Math.PI(); > What makes you think this test will work? Jacek

1 0

Coverity Telco coming up
by Kai Blin 11 Dec '08

11 Dec '08

Hi folks, Coverity is hosting a telco tomorrow about some new technology they're going to roll out to projects. I'm planning to attend, and would like to bring up any issues we're currently having in the Q&A session. Issues I'm currently seeing with our Coverity experience: - Adding new developers to the access list is painfully slow - Builds are pretty outdated (They seem to be working on this) Anything else? Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

5 5

(no subject)
by foobarbaz biffblaff 11 Dec '08

11 Dec '08

Hi, I have a huge amount of Windows code that I'm porting to Linux. Wine is turning out to be a read godsend, thank you guys! Anyway, I've had tons of luck including the directory <wine_dir>/include/wine/windows in my include path. All my Windows types are there and everything is wonderful. I've even been able to link against the libraries by renaming, for example, foo.dll.so to libfoo.so and using -lfoo on the g++ command line. I actually haven't got all my functions defined so I don't know if this will actually run yet because the link isn't complete yet. My first question is whether this will work. Will all my Windows functions with function declarations defined in the windows directory and code compiled into foo.dll.so actually run? Second, I see that some of the functions I want to use are actually defined by headers in the msvcrt directory. However, this directory contains tons of header files that my system (and gcc) also have under /usr/include and gcc's own directories. I understand that msvcrt is Windows lib c, but I wonder how I'm supposed to use it with gcc to compile? I've tried -nostdinc to gcc, but the number of errors I get is enormous. It's not the end of the world if I can't use Wine's msvcrt, but if I could use it, it would define dozens more functions on which my program relies, or if its use was mandatory in order to get the functions implemented in foo.dll.so to work, then obviously I wonder how I'm supposed to compile my Windows code with Wine to make everything work? I'm sorry if this is a dumb question. I can't find a way to search the wine-devel mailing list other than with google and I can't find anything on there or other docs that answer this question, which I'm sure has been asked a million times and has a simple answer. Thank you thank you, Jeff _________________________________________________________________ Send e-mail faster without improving your typing skills. http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_speed_…

1 0

Re: wininet/tests: Use new test URLs on test.winehq.org.
by Paul Vriens 10 Dec '08

10 Dec '08

Hi Alexandre, These changes introduce 15 errors on all platforms. -- Cheers, Paul.

1 0

Re: [PATCH 14/14] msi: Add tests for MsiGetProductProperty.
by Paul Vriens 10 Dec '08

10 Dec '08

James Hawkins wrote: > --- > dlls/msi/tests/package.c | 232 ++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 232 insertions(+), 0 deletions(-) > > > ------------------------------------------------------------------------ > > Hi James, These fail on Win9x as we are relying on some registry keys that are NT+ specific: 9574 lstrcpyA(keypath, "Software\\Microsoft\\Windows\\CurrentVersion\\"); 9575 lstrcatA(keypath, "Installer\\UserData\\S-1-5-18\\Products\\"); 9576 lstrcatA(keypath, prod_squashed); Can we skip these tests, like we do with some others: scm = OpenSCManager(NULL, NULL, GENERIC_ALL); if (!scm && (GetLastError() == ERROR_CALL_NOT_IMPLEMENTED)) { win_skip("Different registry keys on Win9x and WinMe\n"); return; } -- Cheers, Paul.

2 1

Re: [5/8] jscript: Implement the String.anchor() method.
by Jacek Caban 10 Dec '08

10 Dec '08

Hi Andrew, Andrew Nguyen wrote: > --- > dlls/jscript/string.c | 58 ++++++++++++++++++++++++++++++++++++++++++ > dlls/jscript/tests/api.js | 17 +++++++++++++ > 2 files changed, 73 insertions(+), 2 deletions(-) > +static HRESULT do_attribute_tag_format(DispatchEx *dispex, LCID lcid, WORD flags, DISPPARAMS *dp, + VARIANT *retv, jsexcept_t *ei, IServiceProvider *sp, const WCHAR *tagname, const WCHAR *attrname) +{ + static const WCHAR attrtagfmtW[] = {'<','%','s',' ','%','s','=','"','%','s','"','>','%','s','<','/','%','s','>',0}; + static const WCHAR undefinedW[] = {'u','n','d','e','f','i','n','e','d',0}; + StringInstance *string; + BSTR ret; + BSTR attrval = NULL; + DWORD len; + HRESULT hres = S_OK; + + TRACE("\n"); IMO it would be better to change FIXME to TRACE in String_anchor instead of adding TRACE here. You use this function in a few places, and this TRACE doesn't tell us, which function is called. + + if(!is_class(dispex, JSCLASS_STRING)) { + WARN("this is not a string object\n"); + hres = E_NOTIMPL; + goto cleanup; You may just return E_NOTIMPL here. + } + + string = (StringInstance*)dispex; + + if(retv) { + if(arg_cnt(dp)) { + hres = to_string(dispex->ctx, get_arg(dp, 0), ei, &attrval); You should call to_string even if retv is NULL. Although it looks like a nice optimization, we can't do this. Eg, if to_string throws exception, we have to throw it here. + if (FAILED(hres)) + goto cleanup; You may just return hres here. + } + + len = string->length + 2*strlenW(tagname) + strlenW(attrname) + 9; + + if (attrval) + len += SysStringLen(attrval); + else + len += sizeof(undefinedW)/sizeof(WCHAR) - 1; + + ret = SysAllocStringLen(NULL, len); + + if(!ret) + { + hres = E_OUTOFMEMORY; + goto cleanup; Perhaps it's just me, but in cases that don't make the code cleaner by using gotos, I'd avoid them. How about: if(ret) { sprintfW(ret, attrtagfmtW, tagname, attrname, (attrval ? attrval : undefinedW), string->str, tagname); V_VT(retv) = VT_BSTR; V_BSTR(retv) = ret; }else { hres = E_OUTOFMEMORY; } + } + + sprintfW(ret, attrtagfmtW, tagname, attrname, (attrval ? attrval : undefinedW), string->str, tagname); + + V_VT(retv) = VT_BSTR; + V_BSTR(retv) = ret; + } + cleanup: + SysFreeString(attrval); + return hres; +} Jacek

1 0

Re: [5/8] jscript: Implement the String.anchor() method.
by Jacek Caban 10 Dec '08

10 Dec '08

Hi Andrew, Andrew Nguyen wrote: > --- > dlls/jscript/string.c | 58 ++++++++++++++++++++++++++++++++++++++++++ > dlls/jscript/tests/api.js | 17 +++++++++++++ > 2 files changed, 73 insertions(+), 2 deletions(-) > +static HRESULT do_attribute_tag_format(DispatchEx *dispex, LCID lcid, WORD flags, DISPPARAMS *dp, + VARIANT *retv, jsexcept_t *ei, IServiceProvider *sp, const WCHAR *tagname, const WCHAR *attrname) +{ + static const WCHAR attrtagfmtW[] = {'<','%','s',' ','%','s','=','"','%','s','"','>','%','s','<','/','%','s','>',0}; + static const WCHAR undefinedW[] = {'u','n','d','e','f','i','n','e','d',0}; + StringInstance *string; + BSTR ret; + BSTR attrval = NULL; + DWORD len; + HRESULT hres = S_OK; + + TRACE("\n"); IMO it would be better to change FIXME to TRACE in String_anchor instead of adding TRACE here. You use this function in a few places, and this TRACE doesn't tell us, which function is called. + + if(!is_class(dispex, JSCLASS_STRING)) { + WARN("this is not a string object\n"); + hres = E_NOTIMPL; + goto cleanup; You may just return E_NOTIMPL here. + } + + string = (StringInstance*)dispex; + + if(retv) { + if(arg_cnt(dp)) { + hres = to_string(dispex->ctx, get_arg(dp, 0), ei, &attrval); You should call to_string even if retv is NULL. Although it looks like a nice optimization, we can't do this. Eg, if to_string throws exception, we have to throw it here. + if (FAILED(hres)) + goto cleanup; You may just return hres here. + } + + len = string->length + 2*strlenW(tagname) + strlenW(attrname) + 9; + + if (attrval) + len += SysStringLen(attrval); + else + len += sizeof(undefinedW)/sizeof(WCHAR) - 1; + + ret = SysAllocStringLen(NULL, len); + + if(!ret) + { + hres = E_OUTOFMEMORY; + goto cleanup; Perhaps it's just me, but in cases that don't make the code cleaner by using gotos, I'd avoid them. How about: if(ret) { sprintfW(ret, attrtagfmtW, tagname, attrname, (attrval ? attrval : undefinedW), string->str, tagname); V_VT(retv) = VT_BSTR; V_BSTR(retv) = ret; }else { hres = E_OUTOFMEMORY; } + } + + sprintfW(ret, attrtagfmtW, tagname, attrname, (attrval ? attrval : undefinedW), string->str, tagname); + + V_VT(retv) = VT_BSTR; + V_BSTR(retv) = ret; + } + cleanup: + SysFreeString(attrval); + return hres; +}

1 0

Re: oleaut32: added PICTYPE_NONE and PICTYPE_UNINITIALIZED to IPicture::Render with test (try3)
by Paul Vriens 10 Dec '08

10 Dec '08

Nikolay Sivov wrote: > Changelog(try3): > - fixed identation in testlist > Changelog(try2): > - added PICTYPE_NONE and PICTYPE_UNINITIALIZED to IPicture::Render with test > - added test for zero dimensions > > P.S. Render with this types spotted in traces of bugs 6799 and 10050 > >>From 3386e8674380390c3b60c6247443c605ffe6ff6a Mon Sep 17 00:00:00 2001 > From: Nikolay Sivov <bunglehead(a)gmail.com> > Date: Wed, 10 Dec 2008 13:41:09 +0300 > Subject: added PICTYPE_NONE and PICTYPE_UNINITIALIZED to IPicture::Render > > --- > dlls/oleaut32/olepicture.c | 8 +++++ > dlls/oleaut32/tests/olepicture.c | 64 ++++++++++++++++++++++++++++++++++++++ > 2 files changed, 72 insertions(+), 0 deletions(-) > > diff --git a/dlls/oleaut32/olepicture.c b/dlls/oleaut32/olepicture.c > index 498ee53..bdce729 100644 > --- a/dlls/oleaut32/olepicture.c > +++ b/dlls/oleaut32/olepicture.c > @@ -637,6 +637,10 @@ static HRESULT WINAPI OLEPictureImpl_Render(IPicture *iface, HDC hdc, > TRACE("prcWBounds (%d,%d) - (%d,%d)\n", prcWBounds->left, prcWBounds->top, > prcWBounds->right, prcWBounds->bottom); > > + if(cx == 0 || cy == 0 || cxSrc == 0 || cySrc == 0){ > + return CTL_E_INVALIDPROPERTYVALUE; > + } > + > /* > * While the documentation suggests this to be here (or after rendering?) > * it does cause an endless recursion in my sample app. -MM 20010804 > @@ -644,6 +648,10 @@ static HRESULT WINAPI OLEPictureImpl_Render(IPicture *iface, HDC hdc, > */ > > switch(This->desc.picType) { > + case PICTYPE_UNINITIALIZED: > + case PICTYPE_NONE: > + /* nothing to do */ > + return S_OK; > case PICTYPE_BITMAP: > { > HBITMAP hbmpOld; > diff --git a/dlls/oleaut32/tests/olepicture.c b/dlls/oleaut32/tests/olepicture.c > index f81c419..9e33121 100644 > --- a/dlls/oleaut32/tests/olepicture.c > +++ b/dlls/oleaut32/tests/olepicture.c > @@ -25,6 +25,7 @@ > #include <float.h> > > #define COBJMACROS > +#define NONAMELESSUNION > > #include "wine/test.h" > #include <windef.h> > @@ -587,6 +588,68 @@ static void test_enhmetafile(void) > GlobalFree(hglob); > } > > +static void test_Render(void) > +{ > + IPicture *pic; > + HRESULT hres; > + short type; > + PICTDESC desc; > + HDC hdc = GetDC(0); > + > + /* test IPicture::Render return code on uninitialized picture */ > + OleCreatePictureIndirect(NULL, &IID_IPicture, TRUE, (VOID**)&pic); > + hres = IPicture_get_Type(pic, &type); > + ok(hres == S_OK, "IPicture_get_Type does not return S_OK, but 0x%08x\n", hres); > + ok(type == PICTYPE_UNINITIALIZED, "Expected type = PICTYPE_UNINITIALIZED, got = %d\n", type); > + /* zero dimensions */ > + hres = IPicture_Render(pic, hdc, 0, 0, 0, 0, 0, 0, 0, 0, NULL); > + ole_expect(hres, CTL_E_INVALIDPROPERTYVALUE); > + hres = IPicture_Render(pic, hdc, 0, 0, 10, 10, 0, 0, 10, 0, NULL); > + ole_expect(hres, CTL_E_INVALIDPROPERTYVALUE); > + hres = IPicture_Render(pic, hdc, 0, 0, 10, 10, 0, 0, 0, 10, NULL); > + ole_expect(hres, CTL_E_INVALIDPROPERTYVALUE); > + hres = IPicture_Render(pic, hdc, 0, 0, 10, 10, 0, 0, 0, 0, NULL); > + ole_expect(hres, CTL_E_INVALIDPROPERTYVALUE); > + hres = IPicture_Render(pic, hdc, 0, 0, 0, 10, 0, 0, 10, 10, NULL); > + ole_expect(hres, CTL_E_INVALIDPROPERTYVALUE); > + hres = IPicture_Render(pic, hdc, 0, 0, 10, 0, 0, 0, 10, 10, NULL); > + ole_expect(hres, CTL_E_INVALIDPROPERTYVALUE); > + hres = IPicture_Render(pic, hdc, 0, 0, 0, 0, 0, 0, 10, 10, NULL); > + ole_expect(hres, CTL_E_INVALIDPROPERTYVALUE); > + /* nonzero dimensions, PICTYPE_UNINITIALIZED */ > + hres = IPicture_Render(pic, hdc, 0, 0, 10, 10, 0, 0, 10, 10, NULL); > + ole_expect(hres, S_OK); > + IPicture_Release(pic); > + > + desc.cbSizeofstruct = sizeof(PICTDESC); > + desc.picType = PICTYPE_ICON; > + desc.u.icon.hicon = LoadIcon(NULL, IDI_APPLICATION); > + if(!desc.u.icon.hicon){ > + win_skip("LoadIcon failed. Skipping...\n"); Shouldn't you also use ReleaseDC() here for consistency sake? > + return; > + } > + > + OleCreatePictureIndirect(&desc, &IID_IPicture, TRUE, (VOID**)&pic); > + /* zero dimensions, PICTYPE_ICON */ > + hres = IPicture_Render(pic, hdc, 0, 0, 0, 0, 0, 0, 0, 0, NULL); > + ole_expect(hres, CTL_E_INVALIDPROPERTYVALUE); > + hres = IPicture_Render(pic, hdc, 0, 0, 10, 10, 0, 0, 10, 0, NULL); > + ole_expect(hres, CTL_E_INVALIDPROPERTYVALUE); > + hres = IPicture_Render(pic, hdc, 0, 0, 10, 10, 0, 0, 0, 10, NULL); > + ole_expect(hres, CTL_E_INVALIDPROPERTYVALUE); > + hres = IPicture_Render(pic, hdc, 0, 0, 10, 10, 0, 0, 0, 0, NULL); > + ole_expect(hres, CTL_E_INVALIDPROPERTYVALUE); > + hres = IPicture_Render(pic, hdc, 0, 0, 0, 10, 0, 0, 10, 10, NULL); > + ole_expect(hres, CTL_E_INVALIDPROPERTYVALUE); > + hres = IPicture_Render(pic, hdc, 0, 0, 10, 0, 0, 0, 10, 10, NULL); > + ole_expect(hres, CTL_E_INVALIDPROPERTYVALUE); > + hres = IPicture_Render(pic, hdc, 0, 0, 0, 0, 0, 0, 10, 10, NULL); > + ole_expect(hres, CTL_E_INVALIDPROPERTYVALUE); > + IPicture_Release(pic); > + > + ReleaseDC(NULL, hdc); -- Cheers, Paul.

2 1

Re: oleaut32: added PICTYPE_NONE and PICTYPE_UNINITIALIZED to IPicture::Render with test
by Alexandre Julliard 10 Dec '08

10 Dec '08

Nikolay Sivov <bunglehead(a)gmail.com> writes: > Changelog: > - added PICTYPE_NONE and PICTYPE_UNINITIALIZED to IPicture::Render with test > - added test for zero dimensions > - remove some tabs from testfile Please don't change formatting, especially with an incorrect tab size. -- Alexandre Julliard julliard(a)winehq.org

3 3

Re: [5/5] winex11.drv: Fix color conversion for 16 bpp cursors.
by Alexandre Julliard 10 Dec '08

10 Dec '08

Henri Verbeet <hverbeet(a)codeweavers.com> writes: > case 16: > - /* BGR, 5 red, 6 green, 5 blue */ > - *pixel_ptr = *xor_ptr * 0x1f; > - *pixel_ptr |= (*xor_ptr & 0xe0) << 3; > + /* [gggbbbbb][rrrrrggg] -> [xxxxxxxx][rrrrr000][gggggg00][bbbbb000] */ It seems to me that zero-padding isn't quite right, you should expand the values linearly. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winetest: fix a compiler warning
by Vincent Povirk 10 Dec '08

10 Dec '08

These are addressing some very weird cases. They should be an improvement, but I wonder if we can't do better. > void xprintf (const char *fmt, ...) > { > va_list ap; >- size_t size; >+ size_t size = 0; > DWORD written; It would make more sense, IMO, to update the vstrfmtmake function to also set *lenp to 0, if lenp is set, when it runs out of memory. Winetest uses that function indirectly in other places, and one has a similar problem. (Of course, if we did run out of memory, it's a pretty dismal situation, and the returned string will be NULL, but at least xprintf will silently fail instead of crashing.) > extract_test (struct wine_test *test, const char *dir, LPTSTR res_name) > { > BYTE* code; >- DWORD size; >+ DWORD size = 0; For this to matter, the extract_rcdata call has to fail. This is, again, a pretty dismal situation. In this case, we'll later be writing data starting at NULL, and of an undefined, or with this change 0, length. I don't know if that actually works, and it may be better to give up early. Vincent Povirk

1 0

Patchwatcher status: offline
by Dan Kegel 10 Dec '08

10 Dec '08

My house is being rewired, so Patchwatcher is offline for a day.

1 0

re: App hang on creating modal dialog
by Dan Kegel 10 Dec '08

10 Dec '08

Jeff wrote: >I'm trying to solve my bug 16346 >http://bugs.winehq.org/show_bug.cgi?id=16346 >... >I'm trying to figure out where in the wine code I should look for a >system that might be eating all of the messages intended for my >application. Can anyone point me in the right direction? I dunno, but that test case is nice and small. Can you turn it into a wine conformance test? That will make it even more likely somebody helps find a solution... - Dan

2 2

Re: Одговор: Regression in 'Environment Bump Mapping' test (3DMark2001SE) with wine-1.1.10
by Henri Verbeet 09 Dec '08

09 Dec '08

2008/12/9 Milan Kostić <smoki00790(a)gmail.com>: > Henry, with this patch 'Environment Bump Mapping' test is looking good, but > 'fixme:d3d_shader:register_for_arg Unknown source argument 255' is > still there - continous in many cases, not just in 3DMark2001SE... Is > this fixme useless, when this works? > Stefan has a fix for that.

2 1

Re: WineHQ redesign
by Jeremy Newman 09 Dec '08

09 Dec '08

I have committed my work for the WineHQ redesign. I've also updated the AppDB and Bugzilla codebases with the new theme. The site still has not gone live at this time. I wanted to allow a bit more time for the community to review the changes before I cut them live. Other than the skin itself, the other big change is the new URL scheme. The URLs will no longer have /site in them. I will have redirects so the old URLs still work. But, I would appreciate help updating all external links. WineHQ.org can be translated. If you want to translate WineHQ it is pretty straight forward. Simply copy the templates in templates/en to templates/<lang code>, and then build a patch. We have a start on the Spanish translation. -Newman Jeremy Newman wrote: > Module: website > Branch: master > Commit: eab5cc1e6dc6f36339018b11d97e47135b3dde45 > URL: http://source.winehq.org/git/website.git/?a=commit;h=eab5cc1e6dc6f36339018b… > > Author: Jeremy Newman <jnewman(a)codeweavers.com> > Date: Fri Dec 5 16:21:48 2008 -0600 > > WineHQ redesign > * new skin for the webite > * updated website template engine for new URL stucture > * moved wwn,news,interviews to plugins > * dropped sidebar navigation code, no longer used on main site > * other cleanup and removal of dead code > > --- > > favicon.ico | Bin 3638 -> 1406 bytes > images/classic_top_logo.png | Bin 15430 -> 0 bytes > images/ppdonate.gif | Bin 2700 -> 0 bytes > images/ppdonate.png | Bin 2498 -> 0 bytes > images/top_logo.xcf | Bin 39690 -> 0 bytes > images/winehq_border_bottom_left.gif | Bin 125 -> 0 bytes > images/winehq_border_bottom_right.gif | Bin 105 -> 0 bytes > images/winehq_border_dot_left.gif | Bin 114 -> 0 bytes > images/winehq_border_dot_right.gif | Bin 114 -> 0 bytes > images/winehq_border_top_left.gif | Bin 125 -> 0 bytes > images/winehq_border_top_right.gif | Bin 105 -> 0 bytes > images/winehq_top_logo.gif | Bin 6679 -> 0 bytes > images/winehq_top_logo.png | Bin 5934 -> 0 bytes > include/XMLToArray.php | 96 -- > include/config.php | 102 +- > include/globals.conf.sample | 7 +- > include/html.php | 1401 +++++++++++++------- > include/incl.php | 54 +- > include/menu.php | 193 --- > include/plugin.php | 16 +- > include/themes/winehq/box.template | 10 - > include/themes/winehq/box_title.template | 37 - > include/themes/winehq/content.template | 112 +- > include/themes/winehq/content_nobox.template | 72 + > include/themes/winehq/home_page.template | 18 - > include/themes/winehq/menu.template | 9 - > include/themes/winehq/menu_item_row.template | 10 - > include/themes/winehq/menu_lang_row.template | 12 - > include/themes/winehq/menu_search_row.template | 21 - > include/themes/winehq/menu_spacer_row.template | 7 - > include/themes/winehq/menu_top_row.template | 17 - > include/utils.php | 172 +++- > include/winehq.php | 18 - > include/wwn.php | 153 ++- > jquery.js | 32 + > jquery.pngfix.js | 126 ++ > site | 442 +------ > styles.css | 332 +++++ > templates/en/404.template | 24 - > templates/en/about.template | 27 +- > templates/en/acknowledgement.template | 17 +- > templates/en/ads.template | 13 - > templates/en/contributing.template | 5 +- > templates/en/cvs.template | 3 +- > templates/en/devel.template | 143 ++ > templates/en/developer-cheatsheet.template | 3 +- > templates/en/download.template | 96 +- > .../deb.template} | 3 +- > .../deblenny.template} | 3 +- > templates/en/forums.template | 7 +- > templates/en/fun_projects.template | 15 +- > templates/en/global/404.template | 18 + > .../en/{getting_help.template => help.template} | 29 +- > templates/en/help_wanted.template | 7 - > templates/en/history.template | 7 +- > templates/en/home_about.template | 30 - > templates/en/howto.template | 168 --- > templates/en/irc.template | 3 +- > templates/en/license.template | 4 +- > templates/en/menu.xml | 58 - > templates/en/myths.template | 7 +- > templates/en/news_row.template | 8 +- > templates/en/pr-09betarelease.template | 76 -- > templates/en/press.template | 212 --- > templates/en/quotes.template | 6 - > templates/en/resources.template | 3 +- > templates/en/screenshots.template | 76 -- > templates/en/search.template | 3 +- > templates/en/sponsor.template | 27 - > templates/en/status.template | 35 +- > .../changelog.template} | 3 +- > .../directx.template} | 135 +- > .../{status_dlls.template => status/dlls.template} | 291 ++-- > .../multimedia.template} | 73 +- > .../options.template} | 3 + > .../porting.template} | 3 + > .../{status_todo.template => status/todo.template} | 3 +- > .../en/{status_ui.template => status/ui.template} | 3 +- > templates/en/status/wine.template | 624 +++++++++ > templates/en/status_wine.template | 622 --------- > templates/en/supported_applications.template | 11 - > templates/en/who.template | 643 --------- > templates/en/why.template | 7 +- > templates/en/wine_features.template | 7 +- > templates/en/wine_release.template | 11 - > templates/en/winelib.template | 3 +- > templates/en/wwn.template | 42 +- > templates/en/wwn_content.template | 24 + > templates/en/wwn_interview.template | 38 +- > templates/es/download-deb.template | 3 +- > templates/es/{ => global}/404.template | 12 +- > templates/es/help_wanted.template | 7 - > templates/es/home_about.template | 33 - > templates/es/irc.template | 4 +- > templates/es/menu.xml | 58 - > templates/es/news_row.template | 5 - > templates/es/quotes.template | 6 - > templates/es/sending_patches.template | 9 +- > templates/es/supported_applications.template | 13 - > templates/es/wine_release.template | 11 - > templates/es/wwn_interview.template | 29 - > utils.js | 23 + > 102 files changed, 3217 insertions(+), 4147 deletions(-) > > Diff: http://source.winehq.org/git/website.git/?a=commitdiff;h=eab5cc1e6dc6f36339… > >

15 30

Re: oleaut32: add PICTYPE_NONE and PICTYPE_UNINITIALIZED to IPicture::Render
by Jeremy Drake 09 Dec '08

09 Dec '08

On Tue, 9 Dec 2008, Nikolay Sivov wrote: > + case PICTYPE_NONE: > + case PICTYPE_UNINITIALIZED: > + /* undocumented code */ > + return 0x800A017C; This code looks suspiciously like CTL_E_INVALIDPROPERTYVALUE (from olectl.h) to me...

2 1

appdb sidebar has issues
by ricardo filipe 09 Dec '08

09 Dec '08

http://img186.imageshack.us/my.php?image=semttulojh9.jpg some links do not fit the appdb sidebar and there are blank spaces o.0 also, shouldn't the background extend to all site? now it's confined to the homepage size.... _________________________________________________________________ Conheça o Windows Live Spaces, a rede de relacionamentos do Messenger! http://www.amigosdomessenger.com.br/

3 3

Re: defwnd: implement handling of WM_INPUTLANGCHANGE
by Paul Chitescu 09 Dec '08

09 Dec '08

On Tuesday 09 December 2008 21:17:32 Aric Stewart wrote: [...] + while (win_array[count]) + SendMessageA( win_array[count], WM_INPUTLANGCHANGE, wParam, lParam); Missing a ++ here ?

2 1

new web design takes too much space on left
by Dan Kegel 09 Dec '08

09 Dec '08

When working on a notebook computer, I find myself resenting the amount of real estate taken by the left hand navbar in bugzilla. I bet we could shave 20% of that space without bothering anyone...

3 2

Re: [PATCH] gdi32: Use font substitution for source font when linking fonts.
by Lei Zhang 09 Dec '08

09 Dec '08

On Fri, Dec 5, 2008 at 4:46 PM, Lei Zhang <thestig(a)google.com> wrote: > Hi, > > This is sort of related to bug 16325. I've noticed some applications > use the "MS Shell Dlg" font to display CJK text and fails. > > In HKLM\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes, > MS Shell Dlg is set to Tahoma. > > I tried adding a font link for Tahoma in > HKLM\Software\Microsoft\Windows NT\CurrentVersion\FontLink\Systemlink, > but that didn't seem to help. I then tried adding a font link for MS > Shell Dlg, but that didn't have any effect either. > > Taking a closer look, in init_system_links(), both the Tahoma and MS > Shell Dlg entries in Systemlink create a Tahoma entry in memory, due > to the MS Shell Dlg -> Tahoma font substitution. However, in > create_child_font_list(), we check the in-memory list for MS Shell > Dlg, which can never be found. > > With this additional font substitution, create_child_font_list() looks > for Tahoma instead, and the CJK text gets displayed properly. > Anything wrong with this patch?

1 0

Re: uxtheme: fix a compiler warning
by Michael Karcher 09 Dec '08

09 Dec '08

Am Dienstag, den 09.12.2008, 00:39 -0600 schrieb Austin English: > - MSSTYLES_GetNextInteger(lpValue, lpValueEnd, &lpValue, &g); > - if(MSSTYLES_GetNextInteger(lpValue, lpValueEnd, &lpValue, &b)) { > + if(MSSTYLES_GetNextInteger(lpValue, lpValueEnd, &lpValue, &r) && > + MSSTYLES_GetNextInteger(lpValue, lpValueEnd, &lpValue, &g) && > + MSSTYLES_GetNextInteger(lpValue, lpValueEnd, &lpValue, &b)) { I would like to see the last two lines indented more than the "if" line. Take a look at line 748 in msstyles.c to find a precedence case in the file you are patching. In short, that would mean + if(MSSTYLES_GetNextInteger(...) && + MSSTYLES_GetNextInteger(...) && + MSSTYLES_GetNextInteger(...)) + { Regards, Michael Karcher

2 1

Re: Alexandre Julliard : include: Added some definitions for x86_64 exception handling.
by Steven Edwards 09 Dec '08

09 Dec '08

On Tue, Dec 9, 2008 at 7:23 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Mon Dec 8 19:27:59 2008 +0100 > > include: Added some definitions for x86_64 exception handling. was this a typo? You also added ia64/itanium stuff on this commit. -- 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

2 1

Re: [msi/tests] Run tests again on Win9x and NT4
by James Hawkins 09 Dec '08

09 Dec '08

On Tue, Dec 9, 2008 at 9:32 AM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Hi, > > MsiEnumPatchesExA is not implemented below NT4. > > Changelog > Run tests again on Win9x and NT4 > - r = MsiEnumPatchesExA("", usersid, MSIINSTALLCONTEXT_USERUNMANAGED, + r = pMsiEnumPatchesExA("", usersid, MSIINSTALLCONTEXT_USERUNMANAGED, MSIPATCHSTATE_ALL, 0, patchcode, targetprod, &context, targetsid, &size); Please align the extra parameter lines with the extra character in the first line. -- James Hawkins

2 1

Regression in 'Environment Bump Mapping' test (3DMark2001SE) with wine-1.1.10
by Milan Kostić 09 Dec '08

09 Dec '08

Console says: fixme:d3d_shader:register_for_arg Unknown source argument 255 And picture is odd with 1.1.10, in 1.1.9<= it was good i think. I don't know exactly, but this regression can be due changes in ati_fragment_shader.c. http://i263.photobucket.com/albums/ii149/smokidungeon/wine-1110.jpg http://i263.photobucket.com/albums/ii149/smokidungeon/wine-119.jpg Xorg-1.5.3 Mesa-7.2 (r200) ATI 9250

2 1

Re: Huw Davies : opengl/tests: Skip tests if we can't find a pixel format.
by Huw Davies 09 Dec '08

09 Dec '08

On Fri, Dec 05, 2008 at 11:04:07AM -0600, Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: e86ff2a3128f4a0157ecfa10fee31d1416312c71 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=e86ff2a3128f4a0157ecfa10f… > > Author: Huw Davies <huw(a)codeweavers.com> > Date: Fri Dec 5 14:19:25 2008 +0000 > > opengl/tests: Skip tests if we can't find a pixel format. > > --- > > dlls/opengl32/tests/opengl.c | 9 ++++++++- > 1 files changed, 8 insertions(+), 1 deletions(-) > > diff --git a/dlls/opengl32/tests/opengl.c b/dlls/opengl32/tests/opengl.c > index 35eb8ae..a3ac3af 100644 > --- a/dlls/opengl32/tests/opengl.c > +++ b/dlls/opengl32/tests/opengl.c > @@ -555,7 +555,12 @@ START_TEST(opengl) > hdc = GetDC(hwnd); > > iPixelFormat = ChoosePixelFormat(hdc, &pfd); > - ok(iPixelFormat > 0, "No pixelformat found!\n"); /* This should never happen as ChoosePixelFormat always returns a closest match */ > + if(iPixelFormat == 0) > + { > + /* This should never happen as ChoosePixelFormat always returns a closest match, but currently this fails in Wine if we don't have glX */ > + win_skip("Unable to find pixel format.\n"); > + goto cleanup; > + } > > /* We shouldn't be able to create a context from a hdc which doesn't have a pixel format set */ > hglrc = wglCreateContext(hdc); Hi Alexandre, This wasn't what I intended my patch to do. The problem is that Wine's ChoosePixelFormat() rets 0 on XServers without glX. The win_skip results in a test failure. My patch was intended to mark this as a todo_wine. Huw. -- huw(a)codeweavers.com

2 3

Re: Regression in 'Environment Bump Mapping' test (3DMark2001SE) with wine-1.1.10
by James Mckenzie 09 Dec '08

09 Dec '08

Milan Kostić <smoki00790(a)gmail.com> at Dec 9, 2008 7:27 AM (MST) wrote about: Regression in 'Environment Bump Mapping' test (3DMark2001SE) with wine-1.1.10 > > Console says: > > fixme:d3d_shader:register_for_arg Unknown source argument 255 > > And picture is odd with 1.1.10, in 1.1.9<= it was good i think. I >don't know exactly, but this regression can be due changes in >ati_fragment_shader.c. > > Xorg-1.5.3 > Mesa-7.2 (r200) > ATI 9250 > Can you run a regression test to discover where Wine broke this? James McKenzie

1 0

Re: [3/4]
by Henri Verbeet 09 Dec '08

09 Dec '08

2008/12/8 Stefan Dösinger <stefan(a)codeweavers.com>: > + /* TODO: If we're called by shader_glsl_select, we know that both we get past both checks. > + * is it cheaper to have a wrapper function check those? Inline some common code? Extra > + * parameter? > + */ > if (!prog) { > /* No GLSL program set - nothing to do. */ > return; > + } else if(isStateDirty(context, STATE_PIXELSHADER) || > + isStateDirty(context, STATE_VDECL) || > + isStateDirty(context, STATE_PIXELSHADERCONSTANT) || > + isStateDirty(context, STATE_VERTEXSHADERCONSTANT)) { > + /* Will be called again later */ > + return; If you're going to introduce a dependency on state management in the shader backends anyway, you don't need to export constant loading functions from the shader backends at all. You might as well just call shader_select(), and let that figure out if it needs to change the shader or load any constants. That would also avoid this not-so-pretty code here.

2 9

re: Gecko package
by Dan Kegel 09 Dec '08

09 Dec '08

marco meijer wrote: > I have a question about wine_gecko-0.1.0.cab >This package is from 2007-05-30 11:42 and in the mean time firefox > had a lot of security updates. > Is it still save to distribute wine_gecko-0.1.0.cab ? We'd like to move to a newer one. See http://bugs.winehq.org/show_bug.cgi?id=16198 - Dan

4 4

Re: hal: add stub for ExAcquireFastMutex
by Alexander Morozov 09 Dec '08

09 Dec '08

On Tuesday 09 December 2008 03:52:01 ricardo filipe wrote: > this is for http://bugs.winehq.org/show_bug.cgi?id=12628 This is fastcall function. It should be defined like KfAcquireSpinLock.

1 0

comdlg32: includeobject needs to notify window with CDN_INCLUDEITEM
by ricardo filipe 08 Dec '08

08 Dec '08

this is related to http://bugs.winehq.org/show_bug.cgi?id=8072 so... i decided to investigate why didn't media player classic show the files when browsing... i've been debugging this for some days but found the problem, although it's not quite solved, so if anyone has any idea please share. the good thing was that mpc source code is available so i could see how it was implemented. i found out that includeObject is supposed to notify the browsing window with CDN_INCLUDEITEM that wasn't yet declared in wine. the problem is that i get: err:pidl:_ILSimpleGetTextW -- no text err:pidl:_ILSimpleGetTextW -- no text trace:commdlg:SendCustomDlgNotificationMessage RET NOTIFY trace:commdlg:SendCustomDlgNotificationMessage Retval: 0x00000000 and the notify isn't successful :\ any ideas? patch in attachment... _________________________________________________________________ Conheça o Windows Live Spaces, a rede de relacionamentos do Messenger! http://www.amigosdomessenger.com.br/

1 1

winex11.drv: Remove unneeded address-of operators from array names
by Andrew Talbot 08 Dec '08

08 Dec '08

Please do not apply this patch, it is wrong. -- Andy.

1 0

Re: shell32.dll: Return SE_ERR_FNF if file not found before checking for associations
by Paul Vriens 08 Dec '08

08 Dec '08

Paul Chitescu wrote: > Changelog: > shell32.dll: Return SE_ERR_FNF if file not found before checking for > associations (which will fail anyway but with SE_ERR_NOASSOC). > > This fixes 6 out of the 12 shlexec test failures. > > > ------------------------------------------------------------------------ > > Hi Paul. Not sure if Patchwatcher has sent you an email: http://kegel.com/wine/patchwatcher/results/971/1.log You have to fix the tests if you fix something in wine that removes the need for a todo_wine in those tests. -- Cheers, Paul.

2 1

Re: kernel32/tests: Added some tests for behavior of 64-bit kernel handles.
by Paul Vriens 08 Dec '08

08 Dec '08

Hi Alexandre, This new test fails on Win9x as GetCurrentProcess() returns 7FFFFFFF on those platforms. I'm not sure how to fix/change/adjust the test. -- Cheers, Paul.

1 0

Re: [PATCH 5/5] msi: Add tests for MsiEnumPatchesEx.
by Alexandre Julliard 08 Dec '08

08 Dec '08

"James Hawkins" <jhawkins(a)codeweavers.com> writes: > --- > dlls/msi/tests/msi.c | 1672 ++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 1672 insertions(+), 0 deletions(-) The test fails here: ../../../tools/runtest -q -P wine -M msi.dll -T ../../.. -p msi_test.exe.so msi.c && touch msi.ok msi.c:8027: Test failed: Expected ERROR_NO_MORE_ITEMS, got 0 msi.c:8028: Test failed: Expected patchcode to be unchanged, got {77687AD2-C53D-11DD-5D85-001A923592CB} msi.c:8030: Test failed: Expected targetprod to be unchanged, got {77687A96-C53D-11DD-5D85-001A923592CB} msi.c:8032: Test failed: Expected context to be unchanged, got 1 msi.c:8034: Test failed: Expected targetsid to be unchanged, got S-1-5-4 msi.c:8036: Test failed: Expected size to be unchanged, got 7 msi.c:8050: Test failed: Expected ERROR_NO_MORE_ITEMS, got 0 msi.c:8051: Test failed: Expected patchcode to be unchanged, got {77687AD2-C53D-11DD-5D85-001A923592CB} msi.c:8053: Test failed: Expected targetprod to be unchanged, got {77687A96-C53D-11DD-5D85-001A923592CB} msi.c:8055: Test failed: Expected context to be unchanged, got 1 msi.c:8057: Test failed: Expected targetsid to be unchanged, got S-1-5-4 msi.c:8059: Test failed: Expected size to be unchanged, got 7 msi.c:8456: Test failed: Expected ERROR_NO_MORE_ITEMS, got 0 msi.c:8457: Test failed: Expected patchcode to be unchanged, got {77687AD2-C53D-11DD-5D85-001A923592CB} msi.c:8459: Test failed: Expected targetprod to be unchanged, got {77687A96-C53D-11DD-5D85-001A923592CB} msi.c:8461: Test failed: Expected context to be unchanged, got 2 msi.c:8463: Test failed: Expected targetsid to be unchanged, got S-1-5-4 msi.c:8465: Test failed: Expected size to be unchanged, got 7 msi.c:8479: Test failed: Expected ERROR_NO_MORE_ITEMS, got 0 msi.c:8480: Test failed: Expected patchcode to be unchanged, got {77687AD2-C53D-11DD-5D85-001A923592CB} msi.c:8482: Test failed: Expected targetprod to be unchanged, got {77687A96-C53D-11DD-5D85-001A923592CB} msi.c:8484: Test failed: Expected context to be unchanged, got 2 msi.c:8486: Test failed: Expected targetsid to be unchanged, got S-1-5-4 msi.c:8488: Test failed: Expected size to be unchanged, got 7 make: *** [msi.ok] Error 24 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winebrowser: Educated guess if the DDE data is CHAR or WCHAR (try 2)
by Dmitry Timoshkov 08 Dec '08

08 Dec '08

"Paul Chitescu" <paulc(a)voip.null.ro> wrote: > Changelog: > winebrowser: Educated guess if the DDE data is CHAR or WCHAR > > Our shell32 dde_connect implementation sends a CHAR buffer for if operating > system version is set to ANSI based and WCHAR if the system is set for > Unicode. > > This patch makes winebrowser assume the same about the data it receives via > XTYP_EXECUTE. However, if the string starts with a quote (which normally > always happens) an extra effort is made to detect if the data is UTF-16 by > checking if the upper byte of the 1st WCHAR is zero. > > This should fix bug #13891 for good (bugzilla describes a workaround that > avoids using DDE). You should add a test case to find out what NT based/Win9x do in that case. -- Dmitry.

2 2

Gecko package
by marco meijer 08 Dec '08

08 Dec '08

Hi All, I'm the packager of the Mandriva package. And I have a question about wine_gecko-0.1.0.cab This package is from 2007-05-30 11:42 and in the mean time firefox had a lot of security updates. Is it still save to distribute wine_gecko-0.1.0.cab ? Kind regards, Marco

1 0

Re: [kernel32/tests] Kill a debug process to make sure we can cleanup
by Paul Vriens 08 Dec '08

08 Dec '08

Paul Vriens wrote: > Hi, > > For some reason (yet to find out what) one of the tests keeps a > kernel32.exe process running on W2K and below. This prevents cleanup at > the end of winetest. > > Changelog > Kill a debug process to make sure we can cleanup > Ignore this one. -- Cheers, Paul.

1 0

Re: [1/4] D3D9: Document a Microsoft header bug
by Henri Verbeet 08 Dec '08

08 Dec '08

2008/12/8 Stefan Dösinger <stefan(a)codeweavers.com>: > This patch was already applied.

2 1

Re: [4/4] ntdll: print the SYSTEM_PERFORMANCE_INFORMATION only once
by Henri Verbeet 08 Dec '08

08 Dec '08

The actual patch is missing.

1 0

Re: explorer: improve ABM_GETTASKBARPOS stub
by Dmitry Timoshkov 08 Dec '08

08 Dec '08

"Vincent Povirk" <madewokherd+8cd9(a)gmail.com> wrote: > Fixes http://bugs.winehq.org/show_bug.cgi?id=15835 That's not hard to implement this properly using monitor info. -- Dmitry.

3 9

WineHQ - web development and graphics help
by Guillaume Pelletier 08 Dec '08

08 Dec '08

To whom it may concern, Hello! I am interested in working on the WINE website. I am an 18 years old pre-med student currently employed as a web dev and graphics designer in a small company. I was thinking of making a few aesthetic changes to the current WINE website. I am also skilled at graphics, and I think some of the graphical elements could be polished. If I could help out in any way, or if you would like to see samples of my recent work, please let me know. Sincerely, Guillaume Pelletier

2 1

Re: oleaut32: Fix OleLoadPicturePath behavior on wrong path (bug 14710)
by Jeremy Drake 07 Dec '08

07 Dec '08

On Sun, 7 Dec 2008, Nikolay Sivov wrote: > Changelog: > - fix OleLoadPicturePath behavior on wrong path > - some cosmetic changes on module and test (spaces, tabs, ..) Cool, this is related to what I was trying to get done. Please take a look at the more complete tests for OleLoadPicutrePath I wrote that have not been applied yet, and perhaps we both can get our patches in. I ran them against several Windows versions, and I think they do not agree 100% with your tests. http://www.winehq.org/pipermail/wine-patches/2008-November/064929.html Thanks, Jeremy

2 1

winecfg: Updated Swedish translation
by Daniel Nylander 07 Dec '08

07 Dec '08

1 0

Re: d3d9 : do not proceed reset or release from another thread than the one which created the device.
by Henri Verbeet 07 Dec '08

07 Dec '08

2008/11/30 Jérôme Gardou <jerome.gardou(a)gmail.com>: > - if (ref == 0) { > + if (ref <= 0) { This doesn't work, of course. ref is an ULONG. The check for Reset should probably go into wined3d.

2 5

Wrong SP definition in wine.inf.in
by Mirek Slugeň 07 Dec '08

07 Dec '08

Hi, Windows XP doesn't have Service Pack 4, this is bug from rewrite of default OS from Windows 2000 (which has SP 4) to Windows XP. This patch should fix wrong SP definition when creating new .wine tree. Mirek Slugen

1 0

Use show instead of glyphshow because glyphshow is very slow on kyocera
by Wolfgang Walter 06 Dec '08

06 Dec '08

Hello, this is is a proposed change to the wineps driver. Problem: wine uses the postscript command glyphshow to print characters. At least all Postscript Printers from Kyocera are very slow when showglyph is used. Even simple pages with only one downloaded truetype font slow down fast printers as the Kyocera FS-4000DN or FS-9520DN so that they print not more then 3 pages/minute - often only one to two. I can only speculate why glyphshow is such bad for performance. The generic windows postscript printer driver does usually not use showglyph. Nor do the driver from Kyocera. Applications as OpenOffice don't do either. The following patch changes wineps.drv such that it uses show (for downloaded truetype fonts). It still contains code which inserts postscript comments in its output for debugging purpose. It's meant for discussion. Regards, Wolfgang Walter -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts Leiter EDV Leopoldstraße 15 80802 München From e3cfd6d376bb397f8378fe65127496d7b30b4826 Mon Sep 17 00:00:00 2001 From: Wolfgang Walter <wine(a)stwm.de> Date: Sat, 6 Dec 2008 17:43:35 +0100 Subject: Use show instead of glyphshow On many postscript printers glyphshow is slow. Especially all Kyocera models from FS-1020 up to FS-4000DN or FS-9520DN are very slow when glyphshow is used with downloaded truetype fonts. Even simple text-only pages are rendered at 1/6 to 1/10 of the usual time (i.e. reached under windows with the generic window postscript driver). I don't know why glyphshow is slow but I suppose that its usage is not optimised as the eneric windows postscript printer driver seems not to use glyphshow. Nor do the driver from Kyocera. Applications as OpenOffice don't do either. This change modifies wineps.drv such that it uses show for downloaded fonts as other the window printer drivers do. Show accesses glyphs of base fonts by there character code in the encoding array of the font. Only 256 glyphs may be encoded. Therefor I clone the font if necessary. As the clones share all resources but their encoding array with the original font this is not expensive. Actually I limit the number of clones (by undefining older ones) but it's probably not worth the code: * the gylphs themselves are the really expensive part * all fonts are released when a page is rendered I had to modify how font setting works as I have to set the clone with the correct encoding for each character. With this modification printing perfomance is up to what one would expect. I tested this on several Kyocera laser printers (FS-1010, FS-1030, FS-1300, FS-C5025, FS-4000DN, FS-9520DN) and also on a HP Laserjet and a Minolta Laserprinter. And of course with ghostscript. This patch still contains code which creates comments in the generated postscript file for debugging purpose. --- dlls/wineps.drv/download.c | 337 +++++++++++++++++++++++++++++++++++++++----- dlls/wineps.drv/font.c | 4 +- dlls/wineps.drv/ps.c | 14 ++ dlls/wineps.drv/psdrv.h | 16 ++ dlls/wineps.drv/type1.c | 27 +--- dlls/wineps.drv/type42.c | 27 +--- 6 files changed, 347 insertions(+), 78 deletions(-) diff --git a/dlls/wineps.drv/download.c b/dlls/wineps.drv/download.c index e794af6..bd40ef0 100644 --- a/dlls/wineps.drv/download.c +++ b/dlls/wineps.drv/download.c @@ -42,6 +42,23 @@ WINE_DEFAULT_DEBUG_CHANNEL(psdrv); #define GET_BE_DWORD(ptr) ((DWORD)MAKELONG( GET_BE_WORD(&((WORD *)(ptr))[1]), \ GET_BE_WORD(&((WORD *)(ptr))[0]) )) +#define GLYPH_SENT_INC 128 +#define MAX_ENC_PER_FONT 16 /* must be <= 0xfe */ +#define OPT_ENC_PER_FONT 10 /* when we should start to undefine clones */ +#define MIN_ENC_PER_FONT 4 /* when we undefine: how agressive */ + +static const char fontname[] = "%s_wine_%04X"; +static const char undefinefont[] = "/%s_wine_%04X undefinefont\n"; +static const char setdeffont[] = "/%s findfont 40 scalefont setfont\n"; + + +#if DOWNLOAD_SPOOLBUF_MINPLUS <= 1000 +#error "DOWNLOAD_SPOOLBUF_MINPLUS must be greater then 1000" +#endif +#if MAX_ENC_PER_FONT > 0xfe +#error "MAX_ENC_PER_FONT must not exceed 0xfe" +#endif + /**************************************************************************** * get_download_name */ @@ -192,7 +209,7 @@ static BOOL get_bbox(PSDRV_PDEVICE *physDev, RECT *rc, UINT *emsize) */ BOOL PSDRV_SelectDownloadFont(PSDRV_PDEVICE *physDev) { - char *ps_name; + char *ps_name = NULL; LPOUTLINETEXTMETRICA potm; DWORD len = GetOutlineTextMetricsA(physDev->hdc, 0, NULL); @@ -219,6 +236,44 @@ BOOL PSDRV_SelectDownloadFont(PSDRV_PDEVICE *physDev) } /**************************************************************************** + * Download_WriteSetFont + * + * If <force> == TRUE or <g_enc> != pdl->glyph_enc_last_used: + * write postscript code to select the clone of font <pdl> + * where encoding g_enc is mapped as character code (<g_enc> & 0xff) + * + */ +static BOOL Download_WriteSetFont(PSDRV_PDEVICE *physDev, DOWNLOAD *pdl, + WORD g_enc, BOOL force) +{ + BOOL ret; + + UINT fontnr = (g_enc & 0xff00); + + if(!force && pdl->glyph_enc_last_used == fontnr) + return TRUE; + + sprintf(pdl->spoolbuf, fontname, pdl->ps_name, fontnr); + ret = PSDRV_WriteSetFont(physDev, pdl->spoolbuf, physDev->font.size, + physDev->font.escapement); + if (ret) + pdl->glyph_enc_last_used = fontnr; + + return ret; +} + +/**************************************************************************** + * Download_WriteUndefineFont + * + */ +static BOOL Download_WriteUndefineFont(PSDRV_PDEVICE *physDev, DOWNLOAD *pdl, + WORD fontnr) +{ + sprintf(pdl->spoolbuf, undefinefont, pdl->ps_name, fontnr); + return PSDRV_WriteSpool(physDev, pdl->spoolbuf, strlen(pdl->spoolbuf)); +} + +/**************************************************************************** * PSDRV_WriteSetDownloadFont * * Write setfont for download font. @@ -226,24 +281,24 @@ BOOL PSDRV_SelectDownloadFont(PSDRV_PDEVICE *physDev) */ BOOL PSDRV_WriteSetDownloadFont(PSDRV_PDEVICE *physDev) { - char *ps_name; - LPOUTLINETEXTMETRICA potm; - DWORD len = GetOutlineTextMetricsA(physDev->hdc, 0, NULL); DOWNLOAD *pdl; assert(physDev->font.fontloc == Download); - potm = HeapAlloc(GetProcessHeap(), 0, len); - GetOutlineTextMetricsA(physDev->hdc, len, potm); - - get_download_name(physDev, potm, &ps_name); - if(physDev->font.fontinfo.Download == NULL) { + char *ps_name; + DWORD len = GetOutlineTextMetricsA(physDev->hdc, 0, NULL); + LPOUTLINETEXTMETRICA potm; RECT bbox; UINT emsize; + potm = HeapAlloc(GetProcessHeap(), 0, len); + GetOutlineTextMetricsA(physDev->hdc, len, potm); + get_download_name(physDev, potm, &ps_name); + if (!get_bbox(physDev, &bbox, &emsize)) { HeapFree(GetProcessHeap(), 0, potm); + HeapFree(GetProcessHeap(), 0, ps_name); return FALSE; } if(!is_room_for_font(physDev)) @@ -254,6 +309,15 @@ BOOL PSDRV_WriteSetDownloadFont(PSDRV_PDEVICE *physDev) strcpy(pdl->ps_name, ps_name); pdl->next = NULL; + pdl->spoolbuf_len = 2*strlen(ps_name) + DOWNLOAD_SPOOLBUF_MINPLUS; + pdl->spoolbuf = HeapAlloc(GetProcessHeap(), 0, pdl->spoolbuf_len); + pdl->glyph_sent_size = GLYPH_SENT_INC; + pdl->glyph_sent = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, + pdl->glyph_sent_size * sizeof(*(pdl->glyph_sent))); + pdl->glyph_enc_first_valid = 0x100; + pdl->glyph_enc_next_free = 0x100; + pdl->glyph_enc_last_used = 0; + if(physDev->pi->ppd->TTRasterizer == RO_Type42) { pdl->typeinfo.Type42 = T42_download_header(physDev, ps_name, &bbox, emsize); pdl->type = Type42; @@ -271,14 +335,18 @@ BOOL PSDRV_WriteSetDownloadFont(PSDRV_PDEVICE *physDev) get_glyph_name(physDev->hdc, 0, g_name); T42_download_glyph(physDev, pdl, 0, g_name); } + HeapFree(GetProcessHeap(), 0, ps_name); + HeapFree(GetProcessHeap(), 0, potm); + PSDRV_WriteSpool(physDev, "% servus1a\n", strlen("% servus1a\n")); + } else { + PSDRV_WriteSpool(physDev, "% servus1a\n", strlen("% servus1b\n")); + pdl = physDev->font.fontinfo.Download; + assert(physDev->font.fontinfo.Download); } + PSDRV_WriteSpool(physDev, "% servus2\n", strlen("% servus1\n")); + Download_WriteSetFont(physDev, pdl, 0, TRUE); - PSDRV_WriteSetFont(physDev, ps_name, physDev->font.size, - physDev->font.escapement); - - HeapFree(GetProcessHeap(), 0, ps_name); - HeapFree(GetProcessHeap(), 0, potm); return TRUE; } @@ -289,6 +357,191 @@ void get_glyph_name(HDC hdc, WORD index, char *name) return; } +/* + * download_glyph + * + * Downloads the glyph <index> of font <pdl> if necessary and naming it + * <glyph_name>. + * + * Defines an encoding for <glyph_name>. + * + * As a base font in postscript may only have up to 256 entries it clones the + * font if necessary. The name of the font will be <pdl->ps_name>_wine_<XX>00 + * where 0x<XX>00 == <return value> & 0xff00 + * The character code is <return value> & 0xff + * + * If it fails it returns (<return value> & 0xffff) <= 0xff + * or in other words <XX> == 0. + * + * As font <pdl->ps_name>_wine_0000 always exists and every character code of + * it is mapped to .notdef you may ignore errors and print then the undefined + * symbol of the font. + * + * If you call download_glyph with <may_free_encs> = TRUE earlier encodings you + * got for this font may not be valid any more because download_glyph may + * undefine older clones when more than OPT_ENC_PER_FONT clones exist. + * + * As long as you call it with <may_free_encs> = FALSE older encodings beginning + * with the last call with <may_free_encs> = TRUE remain valid. + * But download_glyph will not make more then MAX_ENC_PER_FONT clones and may + * fail then with <return value> == 1 + * + * But you can be sure that + * If you got 0x<XX><YY> + * and you get next 0x<XX><ZZ> or 0x00<WW> + * then 0x<XX><YY> is still valid + * + */ +static WORD download_glyph(PSDRV_PDEVICE *physDev, DOWNLOAD *pdl, DWORD index, + char *glyph_name, BOOL may_free_encs) +{ + DWORD encoding = 0; + DWORD first_valid; + DWORD next_free; + DWORD used; + BOOL ret; + + const char glyph_enc[] = + "/%s_wine_%04X findfont /Encoding get\n" + "dup %u /%s put\n" + "pop\n"; + + const char font_clone[] = + "/%s_wine_0000 findfont\n" + "dup length dict begin\n" + "{ 1 index /FID ne\n" + " {def} {pop pop} ifelse\n" + "} forall\n" + "/Encoding 256 array 0 1 255 {1 index exch /.notdef put} for def\n" + "currentdict\n" + "end\n" + "/%s_wine_%04X exch definefont pop\n"; + + TRACE("%d %s\n", index, glyph_name); + + first_valid = pdl->glyph_enc_first_valid; + next_free = pdl->glyph_enc_next_free; + assert(first_valid <= next_free); + assert( (first_valid & 0xff00) != 0); + + used = ((next_free - first_valid) & 0xff00)>>8; + if (next_free > 0xffff) + used--; + + if(index < pdl->glyph_sent_size) { + encoding = pdl->glyph_sent[index]; + assert(encoding < next_free); + if( encoding >= 0x100 && + ( first_valid <= encoding || first_valid < (next_free & 0x10000) + encoding)) + goto encset; + } + + if( used > MAX_ENC_PER_FONT && !may_free_encs) { + /* we need a new clone of the font but we must not create one */ + return 1; + } + + PSDRV_WriteSpool(physDev, "% hallo1\n", strlen("% hallo1\n")); + if(index >= pdl->glyph_sent_size) { + pdl->glyph_sent_size = (index / GLYPH_SENT_INC + 1) * GLYPH_SENT_INC; + pdl->glyph_sent = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, + pdl->glyph_sent, + pdl->glyph_sent_size * sizeof(*(pdl->glyph_sent))); + encoding = 0; + PSDRV_WriteSpool(physDev, "% hallo1a\n", strlen("% hallo1a\n")); + } + + PSDRV_WriteSpool(physDev, "% hallo2\n", strlen("% hallo2\n")); + if(!encoding) { + /* download glyph */ + switch(pdl->type) { + case Type42: + ret = T42_download_glyph(physDev, pdl, index, glyph_name); + break; + + case Type1: + ret = T1_download_glyph(physDev, pdl, index, glyph_name); + break; + + default: + ERR("Type = %d\n", pdl->type); + assert(0); + } + if (! ret) + return 0; + /* we never assign 0x0000 through 0x00ff as valid encoding. + * If we fail to assign a valid encoding later on we + * still know that we downloaded the glyph already and + * only need to assign an encoding. + */ + pdl->glyph_sent[index] = 1; + PSDRV_WriteSpool(physDev, "% hallo2c\n", strlen("% hallo2c\n")); + } + + PSDRV_WriteSpool(physDev, "% hallo3\n", strlen("% hallo3\n")); + if( (next_free & 0xff) == 0) { + PSDRV_WriteSpool(physDev, "% hallo3a\n", strlen("% hallo3a\n")); + /* we need a new clone of the font */ + if ( (next_free & 0xffff) == 0) { + /* we overflow: we must mark encodings < first_valid as + downloaded but unencoded */ + DWORD i; + for(i = 0; i < pdl->glyph_sent_size; i++) { + if (pdl->glyph_sent[i] < first_valid) + pdl->glyph_sent[i] = 1; + } + next_free += 0x100; + PSDRV_WriteSpool(physDev, "% hallo3b\n", strlen("% hallo3b\n")); + } + /* now clone the font */ + sprintf(pdl->spoolbuf, font_clone, pdl->ps_name, pdl->ps_name, next_free & 0xff00); + PSDRV_WriteSpool(physDev, pdl->spoolbuf, strlen(pdl->spoolbuf)); + + /* reserve character 0 for .notdef */ + next_free++; + } + encoding = next_free++; + used++; + + PSDRV_WriteSpool(physDev, "% hallo4\n", strlen("% hallo4\n")); + pdl->glyph_enc_next_free = next_free; + pdl->glyph_sent[index] = encoding; + /* define encoding */ + sprintf(pdl->spoolbuf, glyph_enc, pdl->ps_name, + (encoding & 0xff00), (encoding & 0xff), glyph_name); + PSDRV_WriteSpool(physDev, pdl->spoolbuf, strlen(pdl->spoolbuf)); + +encset: + PSDRV_WriteSpool(physDev, "% hallo5\n", strlen("% hallo5\n")); + if (used > OPT_ENC_PER_FONT && !may_free_encs) { + int i; + + PSDRV_WriteSpool(physDev, "% hallo5a\n", strlen("% hallo5a\n")); + Download_WriteSetFont(physDev, pdl, 0, TRUE); + + used += (next_free > 0xffff); + for(i = 0; i < used - MIN_ENC_PER_FONT; i++) { + DWORD fontnr = (first_valid & 0xff00); + if (fontnr == (encoding & 0xff00)) + break; + if (fontnr) + Download_WriteUndefineFont(physDev, pdl, fontnr); + first_valid += 0x100; + PSDRV_WriteSpool(physDev, "% hallo5b\n", strlen("% hallo5b\n")); + } + if (first_valid > 0xffff) { + first_valid = 0x100; + next_free &= 0xffff; + pdl->glyph_enc_next_free = next_free; + PSDRV_WriteSpool(physDev, "% hallo5c\n", strlen("% hallo5c\n")); + } + pdl->glyph_enc_first_valid = first_valid; + } + + PSDRV_WriteSpool(physDev, "% hallo6\n", strlen("% hallo6\n")); + return encoding; +} + /**************************************************************************** * PSDRV_WriteDownloadGlyphShow * @@ -298,36 +551,26 @@ void get_glyph_name(HDC hdc, WORD index, char *name) BOOL PSDRV_WriteDownloadGlyphShow(PSDRV_PDEVICE *physDev, WORD *glyphs, UINT count) { + DOWNLOAD *pdl; UINT i; char g_name[MAX_G_NAME + 1]; + DWORD g_enc; + assert(physDev->font.fontloc == Download); - switch(physDev->font.fontinfo.Download->type) { - case Type42: - for(i = 0; i < count; i++) { - get_glyph_name(physDev->hdc, glyphs[i], g_name); - T42_download_glyph(physDev, physDev->font.fontinfo.Download, - glyphs[i], g_name); - PSDRV_WriteGlyphShow(physDev, g_name); - } - break; + pdl = physDev->font.fontinfo.Download; + assert(pdl); - case Type1: for(i = 0; i < count; i++) { get_glyph_name(physDev->hdc, glyphs[i], g_name); - T1_download_glyph(physDev, physDev->font.fontinfo.Download, - glyphs[i], g_name); - PSDRV_WriteGlyphShow(physDev, g_name); - } - break; - - default: - ERR("Type = %d\n", physDev->font.fontinfo.Download->type); - assert(0); + g_enc = download_glyph(physDev, pdl, glyphs[i], g_name, TRUE) & 0xffff; + Download_WriteSetFont(physDev, pdl, g_enc, FALSE); + PSDRV_WriteShow1(physDev, (g_enc & 0xff)); } return TRUE; } + /**************************************************************************** * PSDRV_EmptyDownloadList * @@ -337,8 +580,7 @@ BOOL PSDRV_WriteDownloadGlyphShow(PSDRV_PDEVICE *physDev, WORD *glyphs, BOOL PSDRV_EmptyDownloadList(PSDRV_PDEVICE *physDev, BOOL write_undef) { DOWNLOAD *pdl, *old; - static const char undef[] = "/%s findfont 40 scalefont setfont /%s undefinefont\n"; - char buf[sizeof(undef) + 200]; + const char *default_font = physDev->pi->ppd->DefaultFont ? physDev->pi->ppd->DefaultFont : "Courier"; @@ -349,11 +591,30 @@ BOOL PSDRV_EmptyDownloadList(PSDRV_PDEVICE *physDev, BOOL write_undef) pdl = physDev->downloaded_fonts; physDev->downloaded_fonts = NULL; + + if (write_undef) { + pdl->spoolbuf[pdl->spoolbuf_len-1] = '\0'; + snprintf(pdl->spoolbuf, pdl->spoolbuf_len, setdeffont, default_font); + if (pdl->spoolbuf[pdl->spoolbuf_len-1]) { + default_font = "Courier"; + sprintf(pdl->spoolbuf, setdeffont, default_font); + } + PSDRV_WriteSpool(physDev, pdl->spoolbuf, strlen(pdl->spoolbuf)); + } + while(pdl) { if(write_undef) { - sprintf(buf, undef, default_font, pdl->ps_name); - PSDRV_WriteSpool(physDev, buf, strlen(buf)); + DWORD i; + /* free derived fonts */ + for(i = pdl->glyph_enc_first_valid; i < pdl->glyph_enc_next_free; i += 0x0100) { + int fontnr = (i & 0xff00); + if (fontnr) { + Download_WriteUndefineFont(physDev, pdl, fontnr); + } + } + Download_WriteUndefineFont(physDev, pdl, 0); } + HeapFree(GetProcessHeap(), 0, pdl->glyph_sent); switch(pdl->type) { case Type42: @@ -370,6 +631,8 @@ BOOL PSDRV_EmptyDownloadList(PSDRV_PDEVICE *physDev, BOOL write_undef) } HeapFree(GetProcessHeap(), 0, pdl->ps_name); + HeapFree(GetProcessHeap(), 0, pdl->glyph_sent); + HeapFree(GetProcessHeap(), 0, pdl->spoolbuf); old = pdl; pdl = pdl->next; HeapFree(GetProcessHeap(), 0, old); diff --git a/dlls/wineps.drv/font.c b/dlls/wineps.drv/font.c index 9e0ae39..1a6bf8e 100644 --- a/dlls/wineps.drv/font.c +++ b/dlls/wineps.drv/font.c @@ -125,11 +125,14 @@ HFONT PSDRV_SelectFont( PSDRV_PDEVICE *physDev, HFONT hfont, HANDLE gdiFont ) BOOL PSDRV_SetFont( PSDRV_PDEVICE *physDev ) { PSDRV_WriteSetColor(physDev, &physDev->font.color); + PSDRV_WriteSpool(physDev, "% salve1\n", strlen("% salve1\n")); if(physDev->font.set) return TRUE; + PSDRV_WriteSpool(physDev, "% salve2\n", strlen("% salve2\n")); switch(physDev->font.fontloc) { case Builtin: PSDRV_WriteSetBuiltinFont(physDev); + physDev->font.set = TRUE; break; case Download: PSDRV_WriteSetDownloadFont(physDev); @@ -139,6 +142,5 @@ BOOL PSDRV_SetFont( PSDRV_PDEVICE *physDev ) assert(1); break; } - physDev->font.set = TRUE; return TRUE; } diff --git a/dlls/wineps.drv/ps.c b/dlls/wineps.drv/ps.c index fdebf46..4d7769a 100644 --- a/dlls/wineps.drv/ps.c +++ b/dlls/wineps.drv/ps.c @@ -122,6 +122,9 @@ static const char psrrectangle[] = /* x, y, width, height, -width */ static const char psglyphshow[] = /* glyph name */ "/%s glyphshow\n"; +static const char psshow[] = /* encoding name */ +"<%02X> show\n"; + static const char pssetfont[] = /* fontname, xscale, yscale, ascent, escapement */ "/%s findfont\n" "[%d 0 0 %d 0 0]\n" @@ -611,6 +614,17 @@ BOOL PSDRV_WriteGlyphShow(PSDRV_PDEVICE *physDev, LPCSTR g_name) return TRUE; } +BOOL PSDRV_WriteShow1(PSDRV_PDEVICE *physDev, BYTE g_encoding) +{ + char buf[128]; + int l; + + l = sprintf(buf, psshow, g_encoding); + + PSDRV_WriteSpool(physDev, buf, l); + return TRUE; +} + BOOL PSDRV_WriteFill(PSDRV_PDEVICE *physDev) { return PSDRV_WriteSpool(physDev, psfill, sizeof(psfill)-1); diff --git a/dlls/wineps.drv/psdrv.h b/dlls/wineps.drv/psdrv.h index fcdc78d..4e30238 100644 --- a/dlls/wineps.drv/psdrv.h +++ b/dlls/wineps.drv/psdrv.h @@ -292,8 +292,23 @@ typedef struct _tagDOWNLOAD { TYPE42 *Type42; } typeinfo; char *ps_name; + char *spoolbuf; + size_t spoolbuf_len; + DWORD glyph_sent_size; + WORD *glyph_sent; + WORD glyph_enc_first_valid; + DWORD glyph_enc_next_free; + WORD glyph_enc_last_used; struct _tagDOWNLOAD *next; } DOWNLOAD; +#define DOWNLOAD_SPOOLBUF_MINPLUS 1001 +/* tmp_spool_buf is quaranteed to hold at least + 2*strlen(psname) + DOWNLOAD_TMPBUF_MINPLUS bytes + Attention: + spoolbuf may be changed by any function + of WINE BUT those from ps.c + Never give it as parameter to a WINE function + but those from ps.c */ enum fontloc { Builtin, Download @@ -444,6 +459,7 @@ extern BOOL PSDRV_WriteRRectangle(PSDRV_PDEVICE *physDev, INT x, INT y, INT widt extern BOOL PSDRV_WriteSetFont(PSDRV_PDEVICE *physDev, const char *name, INT size, INT escapement); extern BOOL PSDRV_WriteGlyphShow(PSDRV_PDEVICE *physDev, LPCSTR g_name); +extern BOOL PSDRV_WriteShow1(PSDRV_PDEVICE *physDev, BYTE g_encoding); extern BOOL PSDRV_WriteSetPen(PSDRV_PDEVICE *physDev); extern BOOL PSDRV_WriteArc(PSDRV_PDEVICE *physDev, INT x, INT y, INT w, INT h, double ang1, double ang2); diff --git a/dlls/wineps.drv/type1.c b/dlls/wineps.drv/type1.c index fe8c8ba..c74bb88 100644 --- a/dlls/wineps.drv/type1.c +++ b/dlls/wineps.drv/type1.c @@ -37,8 +37,6 @@ WINE_DEFAULT_DEBUG_CHANNEL(psdrv); struct tagTYPE1 { - DWORD glyph_sent_size; - BOOL *glyph_sent; DWORD emsize; }; @@ -62,7 +60,7 @@ TYPE1 *T1_download_header(PSDRV_PDEVICE *physDev, char *ps_name, RECT *bbox, UIN char dict[] = /* name, emsquare, fontbbox */ "25 dict begin\n" - " /FontName /%s def\n" + " /FontName /%s_wine_0000 def\n" " /Encoding 256 array 0 1 255{1 index exch /.notdef put} for def\n" " /PaintType 0 def\n" " /FontMatrix [1 %d div 0 0 1 %d div 0 0] def\n" @@ -87,11 +85,6 @@ TYPE1 *T1_download_header(PSDRV_PDEVICE *physDev, char *ps_name, RECT *bbox, UIN t1 = HeapAlloc(GetProcessHeap(), 0, sizeof(*t1)); t1->emsize = emsize; - t1->glyph_sent_size = GLYPH_SENT_INC; - t1->glyph_sent = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, - t1->glyph_sent_size * - sizeof(*(t1->glyph_sent))); - buf = HeapAlloc(GetProcessHeap(), 0, sizeof(dict) + strlen(ps_name) + 100); @@ -194,7 +187,7 @@ BOOL T1_download_glyph(PSDRV_PDEVICE *physDev, DOWNLOAD *pdl, DWORD index, RECT rc; static const char glyph_def_begin[] = - "/%s findfont dup\n" + "/%s_wine_0000 findfont dup\n" "/Private get begin\n" "/CharStrings get begin\n" "/%s %d RD\n"; @@ -206,15 +199,10 @@ BOOL T1_download_glyph(PSDRV_PDEVICE *physDev, DOWNLOAD *pdl, DWORD index, assert(pdl->type == Type1); t1 = pdl->typeinfo.Type1; - if(index < t1->glyph_sent_size) { - if(t1->glyph_sent[index]) - return TRUE; - } else { - t1->glyph_sent_size = (index / GLYPH_SENT_INC + 1) * GLYPH_SENT_INC; - t1->glyph_sent = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, - t1->glyph_sent, - t1->glyph_sent_size * sizeof(*(t1->glyph_sent))); - } + if(index >= pdl->glyph_sent_size) + return FALSE; + if(pdl->glyph_sent[index]) + return TRUE; GetObjectW(GetCurrentObject(physDev->hdc, OBJ_FONT), sizeof(lf), &lf); rc.left = rc.right = rc.bottom = 0; @@ -295,7 +283,7 @@ BOOL T1_download_glyph(PSDRV_PDEVICE *physDev, DOWNLOAD *pdl, DWORD index, PSDRV_WriteSpool(physDev, buf, strlen(buf)); str_free(charstring); - t1->glyph_sent[index] = TRUE; + pdl->glyph_sent[index] = 1; HeapFree(GetProcessHeap(), 0, glyph_buf); HeapFree(GetProcessHeap(), 0, buf); return TRUE; @@ -303,7 +291,6 @@ BOOL T1_download_glyph(PSDRV_PDEVICE *physDev, DOWNLOAD *pdl, DWORD index, void T1_free(TYPE1 *t1) { - HeapFree(GetProcessHeap(), 0, t1->glyph_sent); HeapFree(GetProcessHeap(), 0, t1); return; } diff --git a/dlls/wineps.drv/type42.c b/dlls/wineps.drv/type42.c index 172072e..a6c7f8a 100644 --- a/dlls/wineps.drv/type42.c +++ b/dlls/wineps.drv/type42.c @@ -74,8 +74,6 @@ struct tagTYPE42 { int glyf_tab, loca_tab, head_tab; /* indices of glyf, loca and head tables */ int hmtx_tab, maxp_tab; int num_of_written_tables; - DWORD glyph_sent_size; - BOOL *glyph_sent; DWORD emsize; DWORD *glyf_blocks; }; @@ -143,7 +141,7 @@ TYPE42 *T42_download_header(PSDRV_PDEVICE *physDev, char *ps_name, TYPE42 *t42; static const char start[] = /* name, fontbbox */ "25 dict begin\n" - " /FontName /%s def\n" + " /FontName /%s_wine_0000 def\n" " /Encoding 256 array 0 1 255{1 index exch /.notdef put} for\n" " def\n" " /PaintType 0 def\n" @@ -193,11 +191,6 @@ TYPE42 *T42_download_header(PSDRV_PDEVICE *physDev, char *ps_name, return NULL; } - t42->glyph_sent_size = GLYPH_SENT_INC; - t42->glyph_sent = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, - t42->glyph_sent_size * - sizeof(*(t42->glyph_sent))); - buf = HeapAlloc(GetProcessHeap(), 0, sizeof(start) + strlen(ps_name) + 100); @@ -287,7 +280,7 @@ BOOL T42_download_glyph(PSDRV_PDEVICE *physDev, DOWNLOAD *pdl, DWORD index, TYPE42 *t42; const char glyph_def[] = - "/%s findfont exch 1 index\n" + "/%s_wine_0000 findfont exch 1 index\n" "havetype42gdir\n" "{/GlyphDirectory get begin %d exch def end}\n" "{/sfnts get 4 index get 3 index 2 index putinterval pop}\n" @@ -302,15 +295,10 @@ BOOL T42_download_glyph(PSDRV_PDEVICE *physDev, DOWNLOAD *pdl, DWORD index, assert(pdl->type == Type42); t42 = pdl->typeinfo.Type42; - if(index < t42->glyph_sent_size) { - if(t42->glyph_sent[index]) - return TRUE; - } else { - t42->glyph_sent_size = (index / GLYPH_SENT_INC + 1) * GLYPH_SENT_INC; - t42->glyph_sent = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, - t42->glyph_sent, - t42->glyph_sent_size * sizeof(*(t42->glyph_sent))); - } + if(index >= pdl->glyph_sent_size) + return FALSE; + if(pdl->glyph_sent[index]) + return TRUE; if(!get_glyf_pos(t42, index, &start, &end)) return FALSE; TRACE("start = %x end = %x\n", start, end); @@ -364,7 +352,7 @@ BOOL T42_download_glyph(PSDRV_PDEVICE *physDev, DOWNLOAD *pdl, DWORD index, sprintf(buf, glyph_def, pdl->ps_name, index, glyph_name, index); PSDRV_WriteSpool(physDev, buf, strlen(buf)); - t42->glyph_sent[index] = TRUE; + pdl->glyph_sent[index] = 1; HeapFree(GetProcessHeap(), 0, buf); return TRUE; } @@ -374,7 +362,6 @@ void T42_free(TYPE42 *t42) OTTable *table; for(table = t42->tables; table->MS_tag; table++) HeapFree(GetProcessHeap(), 0, table->data); - HeapFree(GetProcessHeap(), 0, t42->glyph_sent); HeapFree(GetProcessHeap(), 0, t42->glyf_blocks); HeapFree(GetProcessHeap(), 0, t42); return; -- 1.5.6.5

1 0

Package repository discussion
by Dan Kegel 06 Dec '08

06 Dec '08

Ubuntu is having a meeting next week to discuss how to more easily grant users access to third party repositories (like wine's, perhaps). I've got a meeting wiki up at http://wiki.winehq.org/TrustingThirdPartyRepositories It already lists the big issues that need discussing. If you're interested in the topic, please have a look and put your two cents in! - Dan

4 7

Re: mshtml: Removed the reference counting of the DLL.
by Austin English 05 Dec '08

05 Dec '08

On Fri, Dec 5, 2008 at 2:36 PM, Alexandru Balut <alexandru.balut(a)gmail.com> wrote: > Hi, > > This is a fix for: http://bugs.winehq.org/show_bug.cgi?id=16164 > > > > + // We never unload the dll, so we just ignore this call. + // See DllCanUnloadNow(). You've got C++ style comments, only use straight C /* comment */ -- -Austin

1 0

App hang on creating modal dialog
by Jeff Miller 05 Dec '08

05 Dec '08

I'm trying to solve my bug 16346 http://bugs.winehq.org/show_bug.cgi?id=16346 Whenever an application pops up a modal dialog in response to a WM_ACTIVATEAPP message, the entire app permanently hangs. The dialog comes up and is usually rendered the first time, but then no more messages are ever received by the app. I'm trying to figure out where in the wine code I should look for a system that might be eating all of the messages intended for my application. Can anyone point me in the right direction? My best guess is that there is a race between the application becoming the active window and the dialog taking over as the active window, and the message system is arriving at an inconsistent state. Jeff

1 0

Re: winebrowser: Interpret the DDE data as CHAR or WCHAR just like the shell32 dde_connect helper sends it
by Hans Leidekker 05 Dec '08

05 Dec '08

On Friday 05 December 2008 14:05:08 Paul Chitescu wrote: > Shell32 sends either 8 bit or 16 bit strings in XTYP_EXECUTE depending on the > highest bit of "operating system version" - ASCII based or Unicode based. > When the data is used in winebrowser it must be interpreted the same. The impression I get from reading MSDN is that the character set depends on whether the client called DdeInitializeA or DdeInitializeW, and it can be overridden too by setting iCodePage in the CONVCONTEXT structure. -Hans

2 3

Re: opengl/tests: Skip tests if we can't find a pixel format.
by Paul Vriens 05 Dec '08

05 Dec '08

Huw Davies wrote: > --- > dlls/opengl32/tests/opengl.c | 8 ++++++++ > 1 files changed, 8 insertions(+), 0 deletions(-) > > > ------------------------------------------------------------------------ > > Hi Huw, This looks a bit strange: + if(iPixelFormat == 0) + { + todo_wine ok(iPixelFormat > 0, Is it your intention to just throw up a failed message in all cases? -- Cheers, Paul.

2 1

Re: Alexandre Julliard : wintab32: Make a function static.
by Francois Gouget 05 Dec '08

05 Dec '08

On Thu, 4 Dec 2008, Alexandre Julliard wrote: [...] > -UINT WINAPI WTInfoT(UINT wCategory, UINT nIndex, LPVOID lpOutput, BOOL bUnicode) > +static UINT WTInfoT(UINT wCategory, UINT nIndex, LPVOID lpOutput, BOOL bUnicode) So how do you know which functions to make static? I guess you don't just mark them all static and see if it causes compilation errors. Is it a script parsing the 'nm -D' output and then grepping for them in the spec file and in object files? I guess there's better way. Is it something that can be automated? I'm thinking either patchwatcher or my weekly scripts here. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Computers are like airconditioners They stop working properly if you open WINDOWS

2 1

Re: inetcomm: possible null pointer dereferences
by Hans Leidekker 05 Dec '08

05 Dec '08

On Thursday 04 December 2008 21:32:37 Gregor Schneider wrote: > - TRACE("(%s)\n", pszEmailFrom); > - > if (!pszEmailFrom) > return E_INVALIDARG; > > + TRACE("(%s)\n", pszEmailFrom); > + > + len = sizeof(szCommandFormat) - 2 /* "%s" */ + strlen(pszEmailFrom); > + Instead of moving the trace down you should use debugstr_a(), which handles the NULL pointer for you. -Hans

1 0

Re: wineconsole: Wait on events in curses backend using select instead of poll
by James McKenzie 05 Dec '08

05 Dec '08

Martin Storsjö wrote: > > poll can't handle terminal devices on Darwin, since Tiger. See the > following discussion: > http://lists.apple.com/archives/Darwin-dev/2006/Apr/msg00066.html > This will have to be setup so that it only works for Macs. Maybe this can be a static patch in the Darwine code but it does not belong in the Wine code stack. I'll look at what the Darwine code can and cannot do. James McKenzie

2 2

Re: [PATCH] comdlg32: Avoid passing NULL to FILEDLG95_LOOKIN_InsertItemAfterParent.
by Vincent Povirk 05 Dec '08

05 Dec '08

Hi, I think you need to free the pidl you get from SHGetSpecialFolderLocation. Vincent Povirk On Thu, Dec 4, 2008 at 4:57 PM, Lei Zhang <thestig(a)google.com> wrote: > Hi, > > This is my second attempt to fix bug 16332. We can make sure > FILEDLG95_LOOKIN_InsertItemAfterParent() doesn't infinite loop by > always giving it a non-null pidl. The Desktop folder seems like a > sensible default. > > > >

1 0

Re: patch for gdi32
by Dan Kegel 04 Dec '08

04 Dec '08

On Wed, Dec 3, 2008 at 1:24 PM, Dan Kegel <dank(a)kegel.com> wrote: > Hi Xiangrong, > you forgot to attach the patch, I think. Aha. You attached the wrong format. We want a plain text file, i.e. not .odt, but .txt. The nice description in your .odt/.pdf belongs in a bug report in http://bugs.winehq.org. (And, as somebody mentioned, there may be related bugs already, e.g. http://bugs.winehq.org/show_bug.cgi?id=4065 ) If you don't want to use "git diff" to generate the patch, use 'diff -u'. See http://kegel.com/academy/opensource.html#patches Good luck, and welcome to Wine development! - Dan

3 3

re: wineconsole: Wait on events in curses backend using select instead of poll
by Dan Kegel 04 Dec '08

04 Dec '08

James McKenzie wrote: > This will have to be setup so that it only works for Macs. > ... it does not belong in the Wine code stack. Why? Select is a perfectly reasonable choice -- and arguably preferable to poll -- when you are absolutely sure that no file descriptor higher than 1023 can be passed to it. (e.g. when you're using it in a program that does not open many file descriptors, or when you're using it with no file descriptors, as a nice sleep). I think wineconsole is an example of an app that does not open many file descriptors, so select is fine there. - Dan

1 0

Re: dsound: fix remaining ds3d, dsound, dsound8 test failures shown on test.winehq.org
by Paul Vriens 04 Dec '08

04 Dec '08

Jeff Zaroyko wrote: > This should clear up the remaining dsound test failures shown for the > Win98 and WinME test results. > > > ------------------------------------------------------------------------ > > Hi Jeff, Would be a nice-to-have if you could add the platforms as comments to the different return values. -- Cheers, Paul.

2 2

Any problems with these wineconsole patches?
by Martin Storsjö 04 Dec '08

04 Dec '08

Hi, In addition to the select vs poll patch to wineconsole, I sent two other unrelated minor patches for wineconsole last Friday (attached here); are there any obvious problems with these, prohibiting them from getting merged? The first one simply makes fallbacks from the curses to the user backend work if the curses library isn't found; not only in the case when the curses backend isn't compiled in at all. The second one makes --use-event not resetting the backend to user, since that's already the default. By setting the environment variable WINECONSOLE="wineconsole --backend=curses", the user could make all implicitly opened consoles be curses based consoles -- if --use-event wouldn't reset the backend back to user as it does at the moment. Regards, // Martin

1 0

Re: wineconsole: Wait on events in curses backend using select instead of poll
by Kai Blin 04 Dec '08

04 Dec '08

On Sunday 30 November 2008 00:52:57 Martin Storsjö wrote: > poll can't handle terminal devices on Darwin, since Tiger. See the > following discussion: > http://lists.apple.com/archives/Darwin-dev/2006/Apr/msg00066.html There's reasons we switched from select to poll. You can't just switch back to select to work around a OSX _bug_. If Apple can't get their act together to fix this, this needs to go behind a configure check/ifdef. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

3 3

Re: patch for gdi32
by Henri Verbeet 03 Dec '08

03 Dec '08

Isn't this the same issue a bug 4065? (http://bugs.winehq.org/show_bug.cgi?id=4065)

1 0

Mono integration to Wine
by Kornél Pál 03 Dec '08

03 Dec '08

Hi, Wine is still using Mono by creating a new process altough it has support for _CorExeMain and _CorDllMain. There is a MonoFixupCorEE method exported by mono.dll that could be used. I also did some research on executing exe assemblies without creating a mono.exe process on MS Windows by injecting code to the new process before initialization to load Mono. Note that because mscoree.dll is loaded at a very early process initilization stage no side-by-side manifests can be used that is required by newer MSVCRTs so I'll most likely create a separate DLL that will load mono.dll later in _CorExeMain or _CorDllMain. For the above mentioned reason it may be better not to use MonoFixupCorEE yet. I would like to receive comments on mixed-mode assembly support of Mono on Wine and if there are people willing to update the Loader to call _CorValidateImage, _CorExeMain (real entry point is not called for EXEs) and _CorImageUnloading for managed images. MSVCRT also should call CorExitProcess on exit. Kornél

2 1

Re: [2/2] gdiplus: fix a warning in GdipMultiplyTextureTransform
by Henri Verbeet 03 Dec '08

03 Dec '08

2008/12/3 Nikolay Sivov <bunglehead(a)gmail.com>: > - return GdipMultiplyMatrix(brush->transform, matrix, order); > + return GdipMultiplyMatrix(brush->transform, (GpMatrix*)matrix, order); I don't think casting const away makes it much better. Considering what the function does, and the fact that the matrix *is* const in the prototype for Matrix::Multiply(), I'd say it would be better to just change the prototype for GdipMultiplyMatrix. MS doesn't seem to care a whole lot about their plain C interfaces these days. Slightly OT, the code in matrix_multiply() isn't quite the most efficient way to multiply two 2x3 matrices, although if you're lucky the compiler will unroll the loop for you and fold the constants.

2 2

IServiceProvider::QueryService tests
by Konstantin Kondratyuk 03 Dec '08

03 Dec '08

In dlls/mshtml/tests/htmldoc.c there is a comment: /* * Services used by HTMLDocument: * * IOleUndoManager * IInternetSecurityManager * ITargetFrame * {D5F78C80-5252-11CF-90FA-00AA0042106E} * HTMLFrameBase * IShellObject * {3050F312-98B5-11CF-BB82-00AA00BDCE0B} * {53A2D5B1-D2FC-11D0-84E0-006097C9987D} * {AD7F6C62-F6BD-11D2-959B-006097C553C8} * DefView (?) * {6D12FE80-7911-11CF-9534-0000C05BAE0B} * IElementBehaviorFactory * {3050F429-98B5-11CF-BB82-00AA00BDCE0B} * STopLevelBrowser * IHTMLWindow2 * IInternetProtocol * IWebBrowserApp * UrlHostory * IHTMLEditHost * IHlinkFrame */ It is confirmed by tests? I have not found. It seems to me, also there should be IHTMLEditServices interface support. How it is correct to add the test on IServiceProvider::QueryService? Thanks. -- Best regards, Konstantin Kondratyuk.

1 0

Re: Alexandre Julliard : ole32: Register interfaces through dlldata. c as far as possible.
by Rob Shearman 03 Dec '08

03 Dec '08

2008/12/3 Alexandre Julliard <julliard(a)winehq.org>: > /* from dlldata.c */ > +extern HINSTANCE hProxyDll DECLSPEC_HIDDEN; > +extern BOOL WINAPI OLE32_DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID fImpLoad) DECLSPEC_HIDDEN; Why declare OLE32_DllMain when it isn't used? > extern HRESULT WINAPI OLE32_DllGetClassObject(REFCLSID rclsid, REFIID iid,LPVOID *ppv) DECLSPEC_HIDDEN; > +extern HRESULT WINAPI OLE32_DllRegisterServer(void) DECLSPEC_HIDDEN; > +extern HRESULT WINAPI OLE32_DllUnregisterServer(void) DECLSPEC_HIDDEN; -- Rob Shearman

2 1

Re: cryptdlg: Implement FormatVerisignExtension (resend)
by Alexandre Julliard 03 Dec '08

03 Dec '08

"Juan Lang" <juan.lang(a)gmail.com> writes: > Aside from the size, is there anything wrong with this one? You are still wasting lots of space by storing copies of string resources. There's no need to do that. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [4/5] wined3d: Use a bitmask to store which bool and int constants are set.
by Ivan Gyurdiev 03 Dec '08

03 Dec '08

> Re: [4/5] wined3d: Use a bitmask to store which bool and int constants are set. Why is this a good thing - this just artificially caps your constants at 32. If I remember correctly I had to change shaders to do the exact opposite change, because newer versions introduced more than 32 constants. Ivan

4 4

Re: today's git does not compile with yesterday's new gcc -- regression test results
by Susan Cragin 02 Dec '08

02 Dec '08

>>> I did the regression test. But how legitimate are the results if the problem is the new gcc that I downloaded recently, and not wine? This problem was an Ubuntu linux bug, and has been fixed in headers for kernel 2.6.28-2.2. See Ubuntu bug 303711. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/303711

1 0

Patchwatcher status
by Dan Kegel 02 Dec '08

02 Dec '08

Patchwatcher is down for the moment - I mistakenly tried using proprietary nvidia drivers, forgetting that my nvidia card is too old to be supported, and don't have time this morning to recover. I'll fix it tonight.

1 0

Status of 64 bit Wine
by Michael Ost 02 Dec '08

02 Dec '08

Hi list, Every once in a while my boss asks me about 64 bit wine. And today was the day. So what's the status? From my understanding there are two parts to the question. First, is anyone using a 64 bit build of Wine? How successfully? Does it pass the internal wine tests? And second, is there any progress on loading 64 bit windows binaries in Wine? My understanding was that changes were needed to gcc to make that happen. Is that correct? Is there any progress on that score? And please correct any misunderstandings I may have. Thanks... mo

3 3

Re: wineoss.drv: Eliminate all 64-bits warnings
by Alexandre Julliard 02 Dec '08

02 Dec '08

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > sizeof is defined as int on 32-bits, and long on 64-bits. To keep this > working I'm casting all sizeofs to longs Please don't add casts, simply get rid of sizeof in traces like we did in the rest of the code. And please do it as a separate patch. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wineoss.drv: Eliminate all 64-bits warnings
by Austin English 02 Dec '08

02 Dec '08

On Tue, Dec 2, 2008 at 3:19 AM, Maarten Lankhorst <m.b.lankhorst(a)gmail.com> wrote: > sizeof is defined as int on 32-bits, and long on 64-bits. To keep this > working I'm casting all sizeofs to longs > --- > Minor, but you've got a few extraneous whitespace changes: diff --git a/dlls/wineoss.drv/audio.c b/dlls/wineoss.drv/audio.c index 460c1f5..1828320 100644 --- a/dlls/wineoss.drv/audio.c +++ b/dlls/wineoss.drv/audio.c @@ -1923,7 +1923,6 @@ static DWORD CALLBACK wodPlayer(LPVOID pmt) dwNextFeedTime = dwNextNotifyTime = INFINITE; } } - return 0; } diff --git a/dlls/wineoss.drv/mmaux.c b/dlls/wineoss.drv/mmaux.c index b48ea6b..44e22b7 100644 --- a/dlls/wineoss.drv/mmaux.c +++ b/dlls/wineoss.drv/mmaux.c @@ -219,10 +219,10 @@ static DWORD AUX_SetVolume(WORD wDevID, DWORD dwParam) /************************************************************************** * auxMessage (WINEOSS.2) */ -DWORD WINAPI OSS_auxMessage(UINT wDevID, UINT wMsg, DWORD dwUser, - DWORD dwParam1, DWORD dwParam2) +DWORD WINAPI OSS_auxMessage(UINT wDevID, UINT wMsg, DWORD_PTR dwUser, + DWORD_PTR dwParam1, DWORD_PTR dwParam2) { - TRACE("(%04X, %04X, %08X, %08X, %08X);\n", + TRACE("(%04X, %04X, %08lX, %08lX, %08lX);\n", wDevID, wMsg, dwUser, dwParam1, dwParam2); #ifdef HAVE_OSS @@ -250,3 +250,4 @@ DWORD WINAPI OSS_auxMessage(UINT wDevID, UINT wMsg, DWORD dwUser, return MMSYSERR_NOTENABLED; #endif } + -- -Austin

2 1

winetest.exe now available on test.winehq.org
by Paul Vriens 01 Dec '08

01 Dec '08

Hi, Test.winehq.org is the new home of the cross compiled winetest.exe. Alexandre put in some magic to create the new winetest.exe on winehq. The new link: http://test.winehq.org/builds/winetest-latest.exe The link can also be found at the bottom of the test.winehq.org index page. I already changed the wiki to reflect these changes. This also means that Paul Millars winetest is no longer available. I'd like to thank Paul for all the hard work he did with keeping up that site and providing us for years with a cross compiled version of winetest. I also like to thank the people that provided the necessary MinGW patches in the past to get that winetest compiled again. -- Cheers, Paul.

2 1

Re: [08/12] msxml3: Add an internal IUnknown object for xmlnode
by Michael Karcher 01 Dec '08

01 Dec '08

Am Samstag, den 29.11.2008, 10:52 +0100 schrieb Michael Karcher: > This makes the xmlnode structures kind-of aggregatable COM objects. > The explanation of the new reference management is in the rather verbose > comment at the top of the new node_unk.c file. For reference, the comment explaining the proposed reference counting scheme is at the end of this mail. This patch got the comment on IRC: "julliard: mkarcher: the comment explaining that COM rules are not followed rings an alarm bell". So, let me first explain the problem I'm trying to solve. In libxml2, the application is responsible for lifetime management, whereas in msxml3, lifetime management is done by reference counting. The XML documents are highly cyclic data structures: There is one real root, called the "document node". In XML documents, it has a single child, the so called "document element". The document element is the root of the so called DOM tree. Every node in the DOM tree has a get_parent and a get_ownerDocument method. Also, each non-leaf node has a get_children method. This is opposed to the standard container-containee model, where the container owns a reference on the containees, but the containees do not know about being in a container. Reference counting in that case is straightforward. Currently, msxml3 implements reference counting in the following way: As soon as an interface object for any DOM node is requested, the reference count of the document is increased by one, and as soon as the interface looses its final reference, the document's reference count is decremented. If the document's reference count reaches zero, no pointer to any object in the DOM tree is out anymore, so the document can be deleted. This seems to work nicely, but has two major catches, that made me do this rewrite of the reference management: a) msxml3 has methods to splice subtrees. b) msxml3 can create nodes nodes owned by a document, that are not in the DOM tree Point a) means that the document a node belongs to is not constant over the lifetime of the node. As in the current model, the node needs to take a reference on its current document, reference counts have to be adjusted. The xmldoc_release and xmldoc_add_ref function calls in removeChild, insertBefore (and alike) seem to take care of this. But as the bullet already said, it is not just splicing the node passed into the splicing function, but a whole subtree! That means that all interface objects to child nodes have to move their reference to the new document. Alas, there is *no* *way* in current wine to find all interface objects for a given node, so there is no way to tell these interface objects to move their references. As there is also no way just to know *how* *many* interface objects are out for a given node, let alone for a whole subtree, reference-correct moving is impossible. Point b) means that just freeing the nodes in the DOM tree on document destruction does not get all the nodes belonging to the document. This is taken care of in the orphan list. The (benign) problem with the orphan list approach is that the so called orphan subtrees, i.e. subtrees that are not part of the document get not freed as soon as no references to the subtree are out anymore, but not until there are no references to any node that is associated with the document. Think put_documentElement, that replaces the whole DOM tree, making the old tree orphan. This might be quite a lot of wasted memory. Now, lets look at what can be done. To solve the important issue in part a, there are two possible approaches: a1) Move to a concept that doesn't need the missing information a2) Make the missing information available. My patch went the route of a1), but I think a2) is also possible: We might count reference to a node in the _private element of the node, so the number of references to a node is at hand. If a subtree is spliced, we would have to traverse the whole subtree to collect the number of references in the subtree to move from the old document to the new document. Another a2) approach is to count the number of references to the whole subtree inside the _private element. This makes obtaining the number of references to the subtree an O(1) operation, but updating the interface object count of one node means the interface count of all parents has to be updated, too. While this is not as expensive as a subtree traversal, updating interface object counts is a very common operation that ought to be O(1) too, and not O(depth). To solve the issue of b), the same things are imaginable. If a node gets orphan, check whether the whole subtree is orphan, and nuke it if it is. If it is not, add it to the orphan list. If later the last reference into that subtree is freed, one has to detect that the subtree is orphan. One could do that by checking on every interface release whether the subtree is now orphan. As this is a "is there any reference to the subtree" question, the first a2 approach is out immediately. The second one can do. The up-traversal will stop either at the document element or at the root of the orphan subtree, and the information whether there is any reference left is immediately at hand. Now, there is the a1 thing left. Throw the old concept of "everyone refs the document" away (which is only band-aided by the orphan list and the expensive sub-tree counts or up-traversals, IMHO) and try to find a clean way to get what we need. This is what this patch is about. The first choice about reference counting in cyclic structures is the choice of reference direction. The choice that the parent node owns its child nodes is tempting, as it seems to resemble the simple container-owns-containee concept. But it breaks down as soon as there are references to the child nodes out, and the parent node looses its last reference, as the parent node would get freed in that case. It would be possible for a parent node to wait for all children to be released before it gets freed itself. But this again needs non-local information. A node has to stay alive as long as *any* descendant of that node, however deep in the hierarchy it might be, is alive. On the other hand, if the explicit references are from child to parent, the crucial operation is no longer to find out whether any child node is still in use (we do have that info in the node's reference count now), the difficult operation is now to find out whether the parent is still in use. This operation is unneeded however, as freeing is delegated to the root node of the subtrees, so a node doesn't care whether there might be new reference obtained to it by use of its parent node, as it can be sure, the parent won't destroy it until it is sure that references can no longer be obtained through it. This finally leads to the solution I implemented. (I won't explain it here again in detail, see below the PS for the explanation of that system) Now, my question is how to proceed. The patches I posted seem to be working fine and seem to clean up the reference management, for example, they do away with the orphan list I introduced but still looks like a hack to me. On the other hand, there are concerns that the new reference management does not follow COM rules (although I couldn't find definitive COM rules for cyclic structures, just the usual info that reference cycles have to be avoided in some way). As I really want problem a) to get fixed, I ask for advice. Thanks for reading this quite long mail. I would be grateful for suggestions. Regards, Michael Karcher PS: This mail does not cover the second, independent topic that we need an IUnknown pointer with node lifetime stability. A basis for that is also introduced in the new reference counting system. While lifetime IUnknown and reference counting are two different things, it looked like a good idea to have both things solved at once. To make use of the provided lifetime IUnknown, the upper layer classes like XMLDOMNode, XMLDOMDocument and the like have to be adjusted too, but I postponed that part of work. The node_unk object serves two purposes: a) it provides a lifetime stable IUnknown for an XML node b) it manages references each xmlNode can carry a node_unk reference in its _private member. If there is an interface pointer to the node floating around, the node does have an associated node_unk object which is created and destroyed lazily. Lazy allocation means: node_unk objects are created when first needed, not at XML document creation time. The main advantage of it is that one does not need to manually create the node_unk objects at each place a xmlNode could be created. Lazy destruction means that the node_unk object is *not* freed as soon as its reference count drops down to zero, because purpose a) wouldn't be fulfilled that way. A node_unk with no references are said to be in "standby mode". Reference counting is done this way: 1) Parents do *not* hold references on their children 2a) If the child is not in standby mode, a reference is held in the parent. 2b) If there is no parent, a reference on the document is held instead. 2c) The document node is exempt from rule 2b), it doesn't hold a reference. Rule 1 is obvious to prevent cyclic references. As children do not destroy themselves on their own, there is no danger of stale child pointers. Each node needs to indirectly reference its document, as strings like node names can be stored in per-document dictionaries in libxml2. For nodes being part of the document tree, this is accomplished by each node referencing its parent via 2a, up to the root element, whose parent is the document itself. There is a complication: A document is fact is not a tree, but a forest! The forest has one main tree, its root being the "document element", but can have many further trees consisting of nodes created by createElement, createText and alike functions, or by removing some subtrees from the document tree, for example by removeChild or replaceChild. These trees are called orphan trees, as they don't have a parent, opposed to the "document element" whose parent is the document itself. The root node of the orphan tree (having no parent) is holding a reference on the document by rule 2b. As there is no way to get a reference to a node in an orphan tree except for having a reference to another node in the same orphan tree, orphan trees can be destroyed as soon as its root node enters standby mode. This has the consequence that the document doesn't need to know about the orphan trees itself, it just needs to know whether there are any of them to prevent early destruction. This is implemented by the reference from rule 2b. On the other hand, one can not free the main document tree as long as any orphan tree is alive, as each orphan tree provides a reference to the document which in turn provides a reference to its main tree. Finally, all nodes you can access from the document node are members of the main document tree, which is kept alive as subtree of the document node, so the document node does not have to hold the reference on anything. So, the implementation works like this: As soon, as the windows program asks for an interface pointer into some XML document (we don't care about the source here), the node is equipped with its node_unk structure, and so get all its parents. While it would be possible to delay the allocation to the AddRef call, the AddRef call has no way to indicate failure in the out-of-memory case. If the application asks for further interface pointers into the same document, chains of node_unk objects are created until a branch is met that already has them; at that point, the reference count is just increased by one on that level without further up-propagation. The document itself (the parent of the document element) keeps out of standby mode until all interface pointers to the document vanished. At that point, the document frees itself and all children. Root node of orphan trees work the same way. The most interesting points are not covered yet: Subtrees can be spliced from one document into another one, like with IXMLDOMNode::appendChild or IXMLDOMNode::replaceChild. In that case, the simple old approach where each IXMLDOMFoo interface held a reference on its document breaks down, as it is unknown how many IXMLDOMFoo pointers are out there that get moved to a different document behind their back. With this model, it is quite simple. A tree that gets spliced out has either zero or one reference on its direct parent, depending on whether it is in standby mode or not. A tree that gets spliced in takes exactly one reference if it is not in standby mode. As an added bonus, we get orphan tracking and early freeing of orphans (a feature we didn't have in the old model) for free.

1 0

Bugzilla's down again
by Austin English 01 Dec '08

01 Dec '08

Different error than usual though: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>500 Internal Server Error</title> </head><body> <h1>Internal Server Error</h1> <p>The server encountered an internal error or misconfiguration and was unable to complete your request.</p> <p>Please contact the server administrator, bugs-admin(a)winehq.org and inform them of the time the error occurred, and anything you might have done that may have caused the error.</p> <p>More information about this error may be available in the server error log.</p> </body></html> Is there anything we can do to prevent it from going down so much? -- -Austin

3 3

Patchwatcher locked up?
by Michael Stefaniuc 01 Dec '08

01 Dec '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Dan, did the patchwatcher look up? The last patch it shows is from 30-Nov-2008 14:01. bye michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org iD8DBQFJNCYg08alQ5mXm14RAnsPAJ44C2vVFmSnD5OknaoMGPkSuB+VFQCfbb6J PhbFmQ4U1nOrHIw5JycPWbc= =005q -----END PGP SIGNATURE-----

1 0

Re: Did anyone have any trouble compiling wine today? Or was it just me ....
by Susan Cragin 01 Dec '08

01 Dec '08

>On Mon, Dec 1, 2008 at 9:06 AM, Susan Cragin <susancragin(a)earthlink.net> wrote: >>>>I don't know off hand then. I'd say run a regression test. As a guess, >>>>you might try removing: >>>>#ifdef HAVE_LINUX_SERIAL_H >>>>#include <linux/serial.h> >>>>#endif >>>> >>>>but that would just be a kludgy workaround. >>>> >>>>-- >>>>-Austin >>> >>>Will try both tomorrow. >>>Thanks. >> >> Austin: >> Did not see above section, but did see this, so removed it. >> #ifdef HAVE_LINUX_INPUT_H >> #include <linux/input.h> >> #endif >> Did not work. Got same error. :( > >Regression test? As Detleft said, it may be kernel related. > >-- >-Austin Found something similar to what Detlef found, so filed a Ubuntu bug against the kernel. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/303711 Also tried new kernel, 2.6.28-1-ub, but got same result. Susan

1 0

netapi32: Why my patch is ignored?
by Vitaly Perov 01 Dec '08

01 Dec '08

What is wrong with my patch? I have fixed all errors found by Juan Lang. I resent this patch several times, but hasn't received any answer. Why my patch is ignored? Maybe something is still wrong, but why somebody just tell me about it? "Juan Lang" <juan.lang(a)gmail.com> wrote: >Hi Vitaliy, overall your patch looks pretty good. A few minor points: > >+ FIXME("(%s %d %p) partially implemented\n", >debugstr_w(servername), level, buf); >Because you add a more specific FIXME for every unimplemented path, it >seems to me this would be better as a TRACE. > >+ result = RegCreateKeyExA(HKEY_LOCAL_MACHINE, regKey, 0, NULL, 0, >KEY_WRITE, >+ NULL, &hKey, &disposition); >+ if (result != ERROR_SUCCESS) >+ { >+ FIXME("Unable to open/create key 'HKLM\\%s'\n", regKey); >+ return result; >This shouldn't be a FIXME, as there's nothing to "fix" in the code: >if the key couldn't be created, there's a setup problem or some other >unrecoverable error. A TRACE is fine. >+ /* FIXME: A duplicate patch checking should be implemented here */ >Do you mean a duplicate path? -- Best wishes, Vitaly Perov Russia, Saint-Petersburg. www.etersoft.ru

3 3

Re: mshtml: suppress module unloading while gecko is loaded
by Paul Bryan Roberts 01 Dec '08

01 Dec '08

> Dan Kegel wrote: > Thanks to Mike Hearn for pointing out that mshtml reference > counting was wrong, and Jacek for pointing out how to fix > it for now. > > Once gecko is loaded, don't let mshtml unload. > This fixes a crash in starting Sketchup (bug 16164), > and probably fixes a number of other apps that > went pear-shaped after unloading mshtml... > Bug 14065 is another instance of the same thing. I did a quick survey of DllCanUnloadNow() on the Wine 1.1.8 code base a couple of weeks ago ... 55 DllCanUnloadNow routines (in some 272 dll subdirectories) 11 FIXME stubs return S_FALSE 7 FIXME stubs return S_OK 3 without FIXME return S_FALSE 2 without FIXME return S_OK 32 appear to be real implementations However, the first in the list (alphabetically) is in astream/main.c. It's reference counter (ddl_ref) is not incremented or decremented anywhere. I count four pairs of inc/dec omissions. In mshtml, I count 7 dll reference count inc/dec pairs, including the server lock pair, in main.c, htmldoc.c and protocol.c I count 28 pairs of InterlockedDecrement / InterlockedIncrement calls around the creation / destruction of active objects throughout the dll. That would seem to imply 22 missing reference count inc/dec pairs. If I finish my script, it will report how many pairs are missing for which dlls and in which source files, which might help make a decision whether the take up Mike Hearn's suggestion of never unloading anything. Even that should involve work taking out the reference counts that are already there. I do not see how the classic WinAPI regression tests can catch this kind of bug other than being a tautologous test of the creation/destruction all the known active objects. If Mike Hearn's suggestion is not taken up, the script might also be useful for regression test purposes. Cheers,

2 1

Re: [1/4] winemenubuilder: move path normalization to Process_Link and Process_URL
by Francois Gouget 01 Dec '08

01 Dec '08

On Sun, 30 Nov 2008, Ambroz Bizjak wrote: [...] > To allow that, I've modified winemenubuilder to record created shortcuts to > registry, and my service will obtain and maintain the list of .lnk/url files > from there. The general idea is good, but I don't think you should store these paths in the registry. Instead the daemon should ask for file change notifications for the relevant special folders (CSIDL_STARTMENU, etc) and act accordingly when a .lnk or .url file gets added / deleted somewhere in thes directories. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Advice is what we ask for when we already know the answer but wish we didn't -- Eric Jong

2 1

Re: Did anyone have any trouble compiling wine today? Or was it just me ....
by Susan Cragin 01 Dec '08

01 Dec '08

>>I don't know off hand then. I'd say run a regression test. As a guess, >>you might try removing: >>#ifdef HAVE_LINUX_SERIAL_H >>#include <linux/serial.h> >>#endif >> >>but that would just be a kludgy workaround. >> >>-- >>-Austin > >Will try both tomorrow. >Thanks. Austin: Did not see above section, but did see this, so removed it. #ifdef HAVE_LINUX_INPUT_H #include <linux/input.h> #endif Did not work. Got same error. :(

1 0

Re: [2/2] shell32/autocomplete: add unit tests for autocomplete
by Paul Vriens 01 Dec '08

01 Dec '08

Jan de Mooij wrote: > Tests pass on 98, XP and Wine (after applying my previous patch) > > > ------------------------------------------------------------------------ > > There is an unrelated change to shelllink.c in this patch. -- Cheers, Paul.

2 2

Fwd: [1/2] shell32/autocomplete: fix handling of WM_KILLFOCUS messages (try 2)
by Jan de Mooij 01 Dec '08

01 Dec '08

Hello, Anybody knows why this patch was rejected? Thanks in advance. ---------- Forwarded message ---------- From: Jan de Mooij <jandemooij(a)gmail.com> Date: Sat, Nov 29, 2008 at 8:57 PM Subject: [1/2] shell32/autocomplete: fix handling of WM_KILLFOCUS messages (try 2) To: wine-patches(a)winehq.org

1 0

Re: wined3d: Sign-compare warnings fix
by Austin English 01 Dec '08

01 Dec '08

On Sat, Nov 29, 2008 at 11:42 AM, Andrew Talbot <andrew.talbot(a)talbotville.com> wrote: > Changelog: > wined3d: Sign-compare warnings fix. > > @@ -504,7 +504,7 @@ static void shader_generate_glsl_declarations(IWineD3DBaseShader *iface, const s > IWineD3DBaseShaderImpl* This = (IWineD3DBaseShaderImpl*) iface; > IWineD3DDeviceImpl *device = (IWineD3DDeviceImpl *) This->baseShader.device; > int i; > - unsigned int extra_constants_needed = 0; > + unsigned int i, extra_constants_needed = 0; > const local_constant *lconst; > > /* There are some minor differences between pixel and vertex shaders */ > > > You forgot to remove 'int i' here. -- -Austin

2 1

USB device drivers support
by Alexander Morozov 01 Dec '08

01 Dec '08

Hello, I sent patch "Add support of WDM drivers for USB devices." in October and received such reply from Alexandre Julliard: > Your design needs a lot more thought. You can't add all these > Wine-specific modules, or make winedevice special-case usb devices, or > poll the server for the add_device request like you do. All this needs > to be properly integrated in the existing infrastructure. I`d like to ask about better way of modifying patches which add USB device drivers support before doing something. Wineusb and wineusbhub can be moved to usbhub.sys. This driver creates a device which is used as second argument for AddDevice on Windows XP. So no wine-specific modules will be added. Using wineserver to call AddDevice can be avoided if move code which loads device drivers and code which enumerates devices and call AddDevice to one process. This can be made if use one winedevice process for all drivers. This will allow every driver to use IRP, DEVICE_OBJECTs and other structures created by other driver and will help to implement such functions as IoGetDeviceObjectPointer. Can I do so? Or there are some reasons which do not allow? Thanks, Alexander

1 0

Re: [advapi32/tests] Fix some crashes on NT4 (Try2)
by Paul Vriens 01 Dec '08

01 Dec '08

On Sat, Nov 29, 2008 at 12:52 PM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Hi, > > (Try2 removes some useless LocalFree's when NewAcl is NULL, duh). > > NT4 crashes at 3 distinct places. The first two we can get rid of by > removing > the LocalFree on failure. The third one we can skip as we can detect NT4 > easily. > Just to be a little bit more precise. NT4 doesn't crash at those LocalFree's but leaving either of them in will make sure the test crashes a bit later. -- Cheers, Paul.

1 0

Error Message and Office 2000
by SWEETSKY＠ROCKETMAIL.COM 01 Dec '08

01 Dec '08

Hi, I'm in Southern California. I did a search for the event when my Office 2000 Professional gave me an error message. It won't setup. The event was 1000 and the fault address is the same as a read out of your computer that you posted online. http://www.winehq.org/pipermail/wine-devel/2003-July/018313.html Did you ever figure out how to get it to work? Thanks! Ciao! Connie

2 1

Re: ole32: implement CoGetCallContext and CoSwitchCallContext
by Rob Shearman 01 Dec '08

01 Dec '08

2008/11/30 Austin English <austinenglish(a)gmail.com>: > + if( !ppv) > + return E_INVALIDARG; > + > + /* get COM tls */ > + info = COM_CurrentInfo(); > + if( !info) Please try to keep the style consistent here. The style that the rest of the file uses is a space after the "if" and no space inside the brackets. > + return E_OUTOFMEMORY; > + > + hr = RPC_E_CALL_COMPLETE; > + if( info->ctx_call) > + { > + hr = IUnknown_QueryInterface( info->ctx_call, riid, ppv); > + } > + > + if (FAILED(hr)) ... > + /* Receives a pointer to the call context object of the call currently > + in progress. This value is returned so that the original call context > + can be restored by the custom marshaller. > + The returned pointer will be NULL if there was no call in progress. */ > + *ppOldObject = info->ctx_call; > + > + /* It may be NULL if you are calling CoSwitchCallContext to switch back > + to the original call context and there was no original call context. */ > + info->ctx_call = pNewObject; You don't take a reference to the object that is passed-in. This is against COM semantics and so requires a test case to prove that this is indeed what the function does. -- Rob Shearman

1 0

Re: X11DRV: GetKeyNameTextW returns a wrong length
by Vincent Povirk 01 Dec '08

01 Dec '08

I don't think "lpBuffer[nSize - 1] = 0;" is safe to remove. If nSize is too small, the resulting string may not be NULL-terminated. Patch-sending guidelines are at http://www.winehq.org/site/sending_patches. Your patch is more likely to be committed if you write a conformance test (although it may be enough in this case to send a patch that obviously works, since this is documented behavior). The appropriate place for that in the wine source is probably dlls/user32/tests. See http://www.winehq.org/site/docs/winedev-guide/testing for guidelines on conformance tests. Vincent Povirk On Thu, Nov 27, 2008 at 3:42 PM, Nils Hoyer <Privat(a)nils-hoyer.de> wrote: > http://bugs.winehq.org/show_bug.cgi?id=16195#c0 > > > This is my first sending of a Wine patch - and first usage of a patch at > all. I'm sorry, if I made any mistake... > > > GetKeyNameTextW results a 1 instead of a the lengh of the Text. This patch > fixes this bug. > > --- keyboard.old 2008-11-27 16:53:15.000000000 +0100 > +++ keyboard.c 2008-11-26 21:19:01.000000000 +0100 > @@ -2328,11 +2328,7 @@ > TRACE("found scan=%04x keyc=%04x keysym=%04x string=%s\n", > scanCode, keyc, (int)keys, name); > if (lpBuffer && nSize && name) > - { > - MultiByteToWideChar(CP_UNIXCP, 0, name, -1, lpBuffer, nSize); > - lpBuffer[nSize - 1] = 0; > - return 1; > - } > + return MultiByteToWideChar(CP_UNIXCP, 0, name, -1, lpBuffer, nSize) > - 1; > } > > /* Finally issue WARN for unknown keys */ > > > >

2 1

Sound regression (in Warcraft III)
by Adam Petaccia 30 Nov '08

30 Nov '08

Maarten, could you look at http://bugs.winehq.org/show_bug.cgi?id=16297 as you're the author of 717df5b2972b3cb998ca5a43279ae2283b117eaa? I tried adding you as CC but bugzilla complained.

2 1

Re: Fw: selinux in fedora 10 regarding text relocation in wine and mono.
by Hin-Tak Leung 30 Nov '08

30 Nov '08

Hi all, I had managed to fix my selinux/wine/mono problem in fedora 10... it is actually two issues, in fact: 1) fedora 10 ships some much stricter selinux policies (but make some exception for wine). 2) I have kernel support for miscellaneous binary formats enabled and have win32 PE registration in the kernel, and run win32 mono.exe (or other PE executables) direct from time to time. so "wine [path]/mono.exe [.NET.exe]" works within the restriction of f10 selinux policies, but "[path]/mono.exe [.NET.exe]" does not. I could either relax the "execmod" policy in selinux, if I want to run any PE .exe's wholesale; or I just need to remember always putting "wine" in front of PE .exe's I want to run... Sorry for the noise.

1 0

Did anyone have any trouble compiling wine today? Or was it just me ....
by Susan Cragin 30 Nov '08

30 Nov '08

and my jaunty jackalope with 2.6.27-7 generic kernel MAKE gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_NTSYSTEM_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits -Wpointer-arith -g -O2 -o serial.o serial.c In file included from serial.c:77: /usr/include/linux/serial.h:164: error: expected specifier-qualifier-list before ‘__u32’ make[2]: *** [serial.o] Error 1 make[2]: Leaving directory `/home/susan/wine/dlls/ntdll' make[1]: *** [ntdll] Error 2 make[1]: Leaving directory `/home/susan/wine/dlls' make: *** [dlls] Error 2 INSTALL make[2]: Leaving directory `/home/susan/wine/dlls/newdev' make[2]: Entering directory `/home/susan/wine/dlls/ntdll' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_NTSYSTEM_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits -Wpointer-arith -g -O2 -o serial.o serial.c In file included from serial.c:77: /usr/include/linux/serial.h:164: error: expected specifier-qualifier-list before ‘__u32’ make[2]: *** [serial.o] Error 1 make[2]: Leaving directory `/home/susan/wine/dlls/ntdll' make[1]: *** [ntdll/__install__] Error 2 make[1]: Leaving directory `/home/susan/wine/dlls' make: *** [dlls/__install__] Error 2

3 2

Re: includes: Fix macros for ITextServices
by Dylan Smith 30 Nov '08

30 Nov '08

The problems with having the macros in the public headers are that they won't work on x86 machines, and are not included in the public headers. Therefore someone developing for another platform will have their code break when using the native public headers or when porting the code to an x86 where the thiscall calling convention is used. On Sun, Nov 30, 2008 at 5:42 AM, Maarten Lankhorst <m.b.lankhorst(a)gmail.com>wrote: > Commit e4ef9c5c removed the ITextServices macros from > wine/include/textserv.h. With this they are added again, and COBJMACROS > before including that header, so that they won't conflict. > --- > > From c04fcab5168309395602f4c4fd07a319a9a532ab Mon Sep 17 00:00:00 2001 > From: Maarten Lankhorst <maarten(a)codeweavers.com> > Date: Sun, 30 Nov 2008 11:37:54 +0100 > Subject: [PATCH] includes: Fix macros for ITextServices > > --- > dlls/riched20/tests/txtsrv.c | 8 +++++++- > include/textserv.h | 19 +++++++++++++++++++ > 2 files changed, 26 insertions(+), 1 deletions(-) > > diff --git a/dlls/riched20/tests/txtsrv.c b/dlls/riched20/tests/txtsrv.c > index 3d47490..c28f5a7 100644 > --- a/dlls/riched20/tests/txtsrv.c > +++ b/dlls/riched20/tests/txtsrv.c > @@ -29,6 +29,9 @@ > #include <objbase.h> > #include <richedit.h> > #include <initguid.h> > + > +#undef COBJMACROS > +/* Don't define ITextServices, we override it here */ > #include <textserv.h> > #include <wine/test.h> > > @@ -44,6 +47,9 @@ static HMODULE hmoduleRichEdit; > #define TXTSERV_VTABLE(This) (This)->lpVtbl > #endif /* __i386__ */ > > +#define ITextServices_QueryInterface(p,a,b) > (p)->lpVtbl->QueryInterface(p,a,b) > +#define ITextServices_AddRef(p) (p)->lpVtbl->AddRef(p) > +#define ITextServices_Release(p) (p)->lpVtbl->Release(p) > #define ITextServices_TxSendMessage(This,a,b,c,d) > TXTSERV_VTABLE(This)->TxSendMessage(This,a,b,c,d) > #define ITextServices_TxDraw(This,a,b,c,d,e,f,g,h,i,j,k,l) > TXTSERV_VTABLE(This)->TxDraw(This,a,b,c,d,e,f,g,h,i,j,k,l) > #define ITextServices_TxGetHScroll(This,a,b,c,d,e) > TXTSERV_VTABLE(This)->TxGetHScroll(This,a,b,c,d,e) > @@ -84,7 +90,7 @@ static HRESULT WINAPI > ITextHostImpl_QueryInterface(ITextHost *iface, > > if (IsEqualIID(riid, &IID_IUnknown) || IsEqualIID(riid, > &IID_ITextHost)) { > *ppvObject = This; > - ITextHost_AddRef((ITextHost *)*ppvObject); > + IUnknown_AddRef((IUnknown *)*ppvObject); > return S_OK; > } > > diff --git a/include/textserv.h b/include/textserv.h > index 977b742..820fc0a 100644 > --- a/include/textserv.h > +++ b/include/textserv.h > @@ -147,6 +147,25 @@ DECLARE_INTERFACE_(ITextServices,IUnknown) > #define ITextServices_QueryInterface(p,a,b) > (p)->lpVtbl->QueryInterface(p,a,b) > #define ITextServices_AddRef(p) (p)->lpVtbl->AddRef(p) > #define ITextServices_Release(p) (p)->lpVtbl->Release(p) > +/*** ITextServices methods ***/ > +#define ITextServices_TxSendMessage(p,a,b,c,d) > (p)->lpVtbl->TxSendMessage(p,a,b > +#define ITextServices_TxDraw(p,a,b,c,d,e,f,g,h,i,j,k,l) > (p)->lpVtbl->TxDraw(p,a > +#define ITextServices_TxGetHScroll(p,a,b,c,d,e) > (p)->lpVtbl->TxGetHScroll(p,a,b > +#define ITextServices_TxGetVScroll(p,a,b,c,d,e) > (p)->lpVtbl->TxGetVScroll(p,a,b > +#define ITextServices_OnTxSetCursor(p,a,b,c,d,e,f,g,h,i) > (p)->lpVtbl->OnTxSetCu > +#define ITextServices_TxQueryHitPoint(p,a,b,c,d,e,f,g,h,i,j) > (p)->lpVtbl->TxQue > +#define ITextServices_OnTxInplaceActivate(p,a) > (p)->lpVtbl->OnTxInplaceActivate > +#define ITextServices_OnTxInplaceDeactivate(p) > (p)->lpVtbl->OnTxInplaceDeactiva > +#define ITextServices_OnTxUIActivate(p) (p)->lpVtbl->OnTxUIActivate(p) > +#define ITextServices_OnTxUIDeactivate(p) (p)->lpVtbl->OnTxUIDeactivate(p) > +#define ITextServices_TxGetText(p,a) (p)->lpVtbl->TxGetText(p,a) > +#define ITextServices_TxSetText(p,a) (p)->lpVtbl->TxSetText(p,a) > +#define ITextServices_TxGetCurrentTargetX(p,a) > (p)->lpVtbl->TxGetCurrentTargetX > +#define ITextServices_TxGetBaseLinePos(p,a) > (p)->lpVtbl->TxGetBaseLinePos(p,a) > +#define ITextServices_TxGetNaturalSize(p,a,b,c,d,e,f,g,h) > (p)->lpVtbl->TxGetNat > +#define ITextServices_TxGetDropTarget(p,a) > (p)->lpVtbl->TxGetDropTarget(p,a) > +#define ITextServices_OnTxPropertyBitsChange(p,a,b) > (p)->lpVtbl->OnTxPropertyBi > +#define ITextServices_TxGetCachedSize(p,a,b) > (p)->lpVtbl->TxGetCachedSize(p,a,b > #endif > > #undef INTERFACE > -- > 1.5.6.5 > > > > >

1 0

Re: winedos: Fixed a problem with timer values that are below 50ms.
by Michael Stefaniuc 30 Nov '08

30 Nov '08

Hello Peter, Peter Dons Tychsen wrote: > Fixed a problem with timer values that are smaller than the minimum time > that can be assigned to the SetTimer() win32 call (approx 50ms). The > patch splits up the timer into several interrupts if too long time has > passed.This fixes good old OutRun, which uses timers of approx 10ms. As > a bonus, this aalso fixes situations where we have fallen behind for > other reasons. your patch introduces a lot of dangling whitespace at the end of lines. bye michael

4 5

today's git does not compile with yesterday's new gcc -- regression test results
by Susan Cragin 30 Nov '08

30 Nov '08

I did the regression test. But how legitimate are the results if the problem is the new gcc that I downloaded recently, and not wine? gcc (Ubuntu 4.3.2-2ubuntu5) 4.3.3 20081129 (prerelease) susan@ubuntu:~/wine$ git bisect bad Bisecting: 0 revisions left to test after this [0b7478a79fb0594daba5cee3c0288884c352ad39] widl: Make sure format strings for structure and union types are only output once. Susan

3 2

Help need list of wine git versions
by Susan Cragin 30 Nov '08

30 Nov '08

Need the number of the current git because am doing regression on it, because it doesn't compile on my machine using my gcc. gcc (Ubuntu 4.3.2-2ubuntu5) 4.3.3 20081129 (prerelease) (And BTW can the regression test page link to this page?) Thank you very much. Susan

3 2

Fw: selinux in fedora 10 regarding text relocation in wine and mono.
by Hin-Tak Leung 30 Nov '08

30 Nov '08

I sent this a few days ago from my "other" e-mail alias and it hasn't come back, so it probably got lost in the spam-filtering - anybody has similiar issue? > So I have upgraded to fedora 10... now when I run wine with > mono for some .Net application I get selinux blocking it, > saying: > > ----------------- > > The mscorsvw.exe application attempted to load > /home/Hin-Tak/.wine/drive_c/windows/Microsoft.NET/Framework/v2.0.50727/mscorsvw.exe > which requires text relocation. This is a potential security > problem. Most libraries do not need this permission. > Libraries are sometimes coded incorrectly and request this > permission. > > ------------------ > > And a few other similar errors. Should I file this with > redhat with their shipped policy, wine or mono? I guess it > should be with redhat, but > somehow I have the impression that I might be asked to file > this with wine-devel. > > Any thoughts on this?

1 0

Hmm, guess we have to update our web site a bit
by Dan Kegel 30 Nov '08

30 Nov '08

Somebody's walkthrough of installing crossover got lots of diggs: http://digg.com/linux_unix/Running_Windows_Programs_On_Ubuntu_8_10_With_Cro… The comments point out that http://www.winehq.org/site/myths could use a little updating...

2 1

wineconsole: Wait on events in curses backend using select instead of poll
by Kirill K. Smirnov 29 Nov '08

29 Nov '08

>Should I add a >check for sys/select.h in the configure script and conditionally included >it, surrounded by HAVE_SYS_SELECT_H? Or would sys/time.h, sys/types.h and >unistd.h be enough to consider it reasonably compatible? Ideally - should. But... 1) There isn't any 'select.h' substring in whole wine tree. 2) There is a file libs/port/usleep.c which uses select() but it does not include any meaningful headers except "config.h" and "wine/port.h". Are these two headers enough wineconsole - I have no idea. Alexandre knows better ;-) Try and see ;-) >After fixing this, I guess I should just submit a new patch against the >current upstream git (not against the old patched version), with the same >commit message, replacing the old one? Yes, and mark a new mail subject with tag '[try 2]' to easily distinguish between different version of the same fix. -- Kirill

2 1

wineconsole: Wait on events in curses backend using select instead of poll
by Kirill K. Smirnov 29 Nov '08

29 Nov '08

Hi, Martin, >+ ret = select(pipefd + 1, &readfds, &writefds, &errorfds, NULL); Passing NULL instead of &writefds in this case is better, IMO. It is not used anyway. ...and... I strongly believe that errorfds parameter os select() is useful for sockets only, not for stdio (I am not sure whether it is true for Darwin). Please, check this. -- Kirill

2 1

Implementing wtmpnam in msvcrt
by Tim Holy 29 Nov '08

29 Nov '08

Hello, I'm trying to implement the "stub" function wtmpnam in msvcrt. Below is a patch at an attempt; there are a number of questions I have about the right way to implement it, and since I don't know the Wine codebase I thought perhaps readers of this list might (with minimal effort) be able to point me in the right direction. Below is the text of the patch (it's short). My questions are embedded after //-style comments (4 in total). Many thanks in advance for your help! --Tim diff -U 3 -r winecopy/wine-1.1.8/dlls/msvcrt/file.c wine-1.1.8/dlls/msvcrt/file.c --- winecopy/wine-1.1.8/dlls/msvcrt/file.c 2008-11-07 10:09:33.000000000 -0600 +++ wine-1.1.8/dlls/msvcrt/file.c 2008-11-29 07:32:43.000000000 -0600 @@ -88,6 +88,7 @@ /* INTERNAL: Static buffer for temp file name */ static char MSVCRT_tmpname[MAX_PATH]; +static MSVCRT_wchar_t MSVCRT_wtmpname[MAX_PATH]; static const unsigned int EXE = 'e' << 16 | 'x' << 8 | 'e'; static const unsigned int BAT = 'b' << 16 | 'a' << 8 | 't'; @@ -2990,6 +2991,32 @@ } /********************************************************************* + * wtmpnam (MSVCRT.@) + */ +MSVCRT_wchar_t * CDECL MSVCRT_wtmpnam(MSVCRT_wchar_t *s) +{ + static int unique; + char tmpstr[16]; + MSVCRT_wchar_t wtmpstr[16]; + MSVCRT_wchar_t *p; + int count; + if (s == 0) + s = MSVCRT_wtmpname; + msvcrt_int_to_base32(GetCurrentProcessId(), tmpstr); + p = s + MSVCRT_swprintf(s, "\\s%s.", tmpstr); // "implicit declaration" error, function is defined in wcs (but no wcs.h); but how to convert format string to MSVCRT_wchar_t? + for (count = 0; count < MSVCRT_TMP_MAX; count++) + { + msvcrt_int_to_base32(unique++, tmpstr); + mbstowcs(wtmpstr,tmpstr,strlen(tmpstr)); // need a MSVCRT_wchar version + wcscpy(p, wtmpstr); // need a MSVCRT_wchar version + if (GetFileAttributesW(s) == INVALID_FILE_ATTRIBUTES && + GetLastError() == ERROR_FILE_NOT_FOUND) + break; + } + return s; +} + +/********************************************************************* * tmpfile (MSVCRT.@) */ MSVCRT_FILE* CDECL MSVCRT_tmpfile(void) diff -U 3 -r winecopy/wine-1.1.8/dlls/msvcrt/msvcrt.spec wine-1.1.8/dlls/msvcrt/msvcrt.spec --- winecopy/wine-1.1.8/dlls/msvcrt/msvcrt.spec 2008-11-07 10:09:33.000000000 -0600 +++ wine-1.1.8/dlls/msvcrt/msvcrt.spec 2008-11-29 07:12:10.000000000 -0600 @@ -579,7 +579,7 @@ @ cdecl _wstrtime(ptr) @ cdecl _wsystem(wstr) @ cdecl _wtempnam(wstr wstr) -@ stub _wtmpnam #(ptr) +@ cdecl wtmpnam(ptr) MSVCRT_wtmpnam // needs an underscore? @ cdecl _wtoi(wstr) ntdll._wtoi @ cdecl _wtoi64(wstr) ntdll._wtoi64 @ cdecl _wtol(wstr) ntdll._wtol

3 6

new winetricks-20081129: new verbs mshflxgd, controlpad/fm20, native_oleaut32
by Dan Kegel 29 Nov '08

29 Nov '08

Also clean up temp directory between verbs, as some verbs were writing readonly files with unique names like 'setup.exe' and stumbling over each other. As always, online at http://kegel.com/wine/winetricks Please submit bug reports to http://code.google.com/p/winezeug/issues/list

1 0

Re: winex11.drv: change bpp fixme to a warn
by James Hawkins 28 Nov '08

28 Nov '08

On Fri, Nov 28, 2008 at 4:25 PM, Austin English <austinenglish(a)gmail.com> wrote: > This isn't something we can really fix on our end, so a FIXME isn't appropriate. > diff --git a/dlls/advapi32/security.c b/dlls/advapi32/security.c index 8229377..16aa8c3 100644 --- a/dlls/advapi32/security.c +++ b/dlls/advapi32/security.c @@ -1155,6 +1155,7 @@ DWORD WINAPI BuildSecurityDescriptorW( BOOL WINAPI InitializeSecurityDescriptor( PSECURITY_DESCRIPTOR pDescr, DWORD revision ) { + pDescr = 0; return set_ntstatus( RtlCreateSecurityDescriptor(pDescr, revision )); } Extraneous change. -- James Hawkins

2 1

Re: shell32/autocomplete: fix handling of WM_KILLFOCUS messages
by Austin English 28 Nov '08

28 Nov '08

On Fri, Nov 28, 2008 at 10:53 AM, Jan de Mooij <jandemooij(a)gmail.com> wrote: > In eMule after moving focus from the searchbox to another control, it > still shows the caret and search is unusable without switching tabs. > > Autocomplete overrides the textbox message handler. But after handling > WM_KILLFOCUS messages we should send it to the old handler so it can > move the focus from the textbox, hide the caret, etc. > > Fixes bug 4090: http://bugs.winehq.org/show_bug.cgi?id=4090 > > Regards > > > > Can you add a testcase for this? -- -Austin

1 0

Re: dinput: Remove WINAPI on static functions where not needed.
by Vitaliy Margolen 28 Nov '08

28 Nov '08

Francois Gouget wrote: > --- > > If you know other places where the functions touched by this patch > are used, please let me know. For more details, see: > > http://www.winehq.org/pipermail/wine-patches/2008-November/064995.html > > > dlls/dinput/joystick_linux.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/dinput/joystick_linux.c b/dlls/dinput/joystick_linux.c > index 4146f1d..47c734d 100644 > --- a/dlls/dinput/joystick_linux.c > +++ b/dlls/dinput/joystick_linux.c > @@ -966,7 +966,7 @@ static HRESULT WINAPI JoystickAImpl_GetProperty( > /****************************************************************************** > * GetObjectInfo : get object info > */ > -static HRESULT WINAPI JoystickWImpl_GetObjectInfo(LPDIRECTINPUTDEVICE8W iface, > +static HRESULT JoystickWImpl_GetObjectInfo(LPDIRECTINPUTDEVICE8W iface, > LPDIDEVICEOBJECTINSTANCEW pdidoi, DWORD dwObj, DWORD dwHow) > { > static const WCHAR axisW[] = {'A','x','i','s',' ','%','d',0}; Please don't apply this patch. This function should be used in vtable but isn't by mistake. Sending a patch to fix this. Vitaliy.

1 0

Re: [1/2] [try 4] mlang: Add implementation offnIMLangFontLink_GetCharCodePages
by Dmitry Timoshkov 28 Nov '08

28 Nov '08

"Vitaly Perov" <vitperov(a)etersoft.ru> wrote: > Changes since last send: > - Used local mlang_data structure instead of calling internal function > wine_cp_enum_table. > - Used macro instead of "iface->lpVtbl->...." Looks good to me. -- Dmitry.

2 1

New winetricks 20081127: new verbs mono20, ie6, msmask, ole2
by Dan Kegel 28 Nov '08

28 Nov '08

Also updates to latest directx9, and fixes a Mac problem. As always, online at http://kegel.com/wine/winetricks Please submit bug reports to http://code.google.com/p/winezeug/issues/list Thanks to everybody who sent in suggestions and patches! ie6 - Steven Edwards msmask - Austin mac bugfix - Ryan Schmidt

1 0

Re: programs: Fix broken compilation on win64
by Rob Shearman 27 Nov '08

27 Nov '08

2008/11/27 Maarten Lankhorst <maarten(a)codeweavers.com>: > --- > Set the Spare[0] at runtime after a critical section is entered. :-) > > I'm not testing Spare[0] at all calls to EnterCriticalSection, but if this > is a problem I will send a revised patch IMHO, this is too fragile. My solution would be two macros: one for declaring a variable storing the name for a critical section, and a second for putting that name into the critical section structure. The latter would be something like the following for 64-bit: #define WINE_DEBUG_USE_CRIT_SECT_NAME(name) { (DWORD)(DWORD_PTR)name, (DWORD)((DWORD_PTR)name >> 32) } It might even be better to let the macro fill in / declare the entire CRITICAL_SECTION_DEBUG stucture. -- Rob Shearman

2 1

Re: d3dxof: DPRINTF -> TRACE.
by Christian Costa 27 Nov '08

27 Nov '08

DPRINTF use here is intentional. Christian Andrew Riedi a écrit : > Changelog: > d3dxof: DPRINTF -> TRACE. > > > ------------------------------------------------------------------------ > >

1 0

Re: [3/5] WineD3D: Fix D3DFMT_R32F, R16F, G16R16F, ... in the pixel shader
by Roderick Colenbrander 27 Nov '08

27 Nov '08

Hi, I don't know much about the current shader code but is this the right way to go thinking about GL_EXT_texture_swizzle + GL_ARB_texture_rg? For instance Nvidia drivers will soon get the swizzle extension and for that you don't have to fixups anymore. Is moving this way the right approach, so that it won't become a mess later on? Roderick -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

3 11

Re: [1/2] [try 3] mlang: Add implementation offnIMLangFontLink_GetCharCodePages
by Dmitry Timoshkov 27 Nov '08

27 Nov '08

"Vitaly Perov" <vitperov(a)etersoft.ru> wrote: > Changes since last send: > - Used WINAPI function instead of accessing Wine internal code page > structures. You still access internal Wine code page structures, I'm not sure why you claim otherwise. > "Dmitry Timoshkov" <dmitry(a)codeweavers.com> wrote: >>It *is* possible to use EnumSystemCodePages > > Yes, it is possible. But : > 1) this function call wine_cp_enum_table, then converts the result (codepage) > to the string. So we need convert the result back to the number. > 2) It pass code pages to the callback-function. The callback function uses > only one argument - string with codepage number. So it's very difficult to > pass this value back to the GetCharCodePages function. > > So, I think the best decision is to use internal function wine_cp_enum_table What's happend to the idea to use mlang_data? And again: forget about Wine internal code page structures, that's the implementation detail that's internal to kernel32/ntdll, that structures should not be used outside of kernel32/ntdll. > + iface->lpVtbl->CodePageToCodePages(iface, > + cpTable->info.codepage, &codePages); Have a look how other parts in Wine call vtable members, the tests have enough code samples. -- Dmitry.

1 0

Re: user32: Improve the LoadImage() test.
by Dmitry Timoshkov 27 Nov '08

27 Nov '08

"Andrew Riedi" <andrewriedi(a)gmail.com> wrote: > - icon_entry->xHotspot = 1; > - icon_entry->yHotspot = 1; > + icon_entry->xHotspot = 1; /* Color planes for .ico. */ > + icon_entry->yHotspot = ICON_BPP; /* BPP for .ico. */ ... > ok(icon_info.xHotspot == 1, "xHotspot is %u.\n", icon_info.xHotspot); > - ok(icon_info.yHotspot == 1, "yHotspot is %u.\n", icon_info.yHotspot); > + ok(icon_info.yHotspot == 32, "yHotspot is %u.\n", icon_info.yHotspot); It should be ICON_BPP instead of 32 for consistency. > + /* Test loading an icon as an icon. */ > + SetLastError(0xdeadbeef); > + handle = LoadImageA(NULL, "icon.ico", IMAGE_ICON, 0, 0, LR_LOADFROMFILE); > + ok(handle != NULL, "LoadImage() failed.\n"); > + error = GetLastError(); > + ok(error == 0 || > + broken(error == 0xdeadbeef) || /* Win9x */ > + broken(error == ERROR_BAD_PATHNAME), /* Win98, WinMe */ > + "Last error: %u\n", error); There is no point in testing last error value if the API didn't fail. > + /* Test the icon information. */ > + SetLastError(0xdeadbeef); > + ret = GetIconInfo(handle, &icon_info); > + ok(ret, "GetIconInfo() failed.\n"); > + error = GetLastError(); > + ok(error == 0xdeadbeef, "Last error: %u\n", error); Same here. > + if (ret) > + { > + ok(icon_info.fIcon == TRUE, "fIcon == FALSE.\n"); > + ok(icon_info.xHotspot == 16, "xHotspot is %u.\n", icon_info.xHotspot); > + ok(icon_info.yHotspot == 16, "yHotspot is %u.\n", icon_info.yHotspot); > + ok(icon_info.hbmColor != NULL, "No hbmColor!\n"); > + ok(icon_info.hbmMask != NULL, "No hbmMask!\n"); > + } 'if (ret)' is useless if you don't expect a failure. > + > + /* Clean up. */ > + SetLastError(0xdeadbeef); > + ret = DestroyIcon(handle); > + ok(ret, "DestroyIcon() failed.\n"); > + error = GetLastError(); > + ok(error == 0xdeadbeef, "Last error: %u\n", error); Same here. -- Dmitry.

3 2

Re: ole32: Add Co*InitializeSpy functions
by Rob Shearman 27 Nov '08

27 Nov '08

2008/11/26 Maarten Lankhorst <maarten(a)codeweavers.com>: > + > +HRESULT WINAPI CoRevokeInitializeSpy(ULARGE_INTEGER cookie) > +{ > + struct oletls *info = COM_CurrentInfo(); > + TRACE("(%s)\n", wine_dbgstr_longlong(cookie.QuadPart)); > + > + if (!info || !info->spy || cookie.QuadPart != (DWORD_PTR)info->spy) > + return E_INVALIDARG; > + > + IUnknown_Release(info->spy); > + return S_OK; > +} No function documentation and you forget to clear info->spy before returning. -- Rob Shearman

2 1

Re: [2/5] WineD3D: Use a separate enum for pixel format fixups
by Henri Verbeet 27 Nov '08

27 Nov '08

2008/11/27 Stefan Dösinger <stefan(a)codeweavers.com>: > +enum shader_color_conv > +{ > + fmtconv_none = 1, > + set_blue_1 = 2, > + signed_2_no_ba = 3, > + signed_2 = 4, > + signed_4 = 5, > + signed_l6v5u5 = 6, > + swap_rg_blue_1 = 7, > + a_to_g_ba_1 = 8, > + yuv_yuy2 = 9, > + yuv_uyvy = 10, > + yuv_yv12 = 11, > + force_dword = 0x7ffffff > +}; > Could you please use uppercase enum elements like the rest of the world? :-/

1 0

Re: ntdll: DPRINTF -> TRACE. (heap.c)
by Dmitry Timoshkov 27 Nov '08

27 Nov '08

"Andrew Riedi" <andrewriedi(a)gmail.com> wrote: > Changelog: > ntdll: DPRINTF -> TRACE. (heap.c) DPRINTF is used for a reason here. -- Dmitry.

2 2

Re: imm32: Add some really basic tests for ImmSetCompositionString().
by Dmitry Timoshkov 27 Nov '08

27 Nov '08

"Andrew Riedi" <andrewriedi(a)gmail.com> wrote: > +static int test_ImmSetCompositionString(void) It's a usual practice to have the test cases return 'void', especially if you don't use the return value. > +{ > + HIMC imc; > + BOOL ret; > + DWORD error; > + > + imc = ImmGetContext(hwnd); First thing to test is the return value of ImmGetContext() and report last error in the case of a failure. -- Dmitry.

2 1

Re: [1/5] D3D9: Document a Microsoft header bug
by Adam Petaccia 27 Nov '08

27 Nov '08

On Thu, 2008-11-27 at 01:30 +0100, Stefan Dösinger wrote: > > + > + /* Note: Microsoft's d3d9.h does not declare > IDirect3D9Ex::RegisterSoftwareDevice . This would mean that > + * the offsets of the other methods in the Vtable change too. > This, however, seems wrong. In Microsoft's > + * d3d9.dll, the offsets for the other functions are still > compatible with IDirect3D9. > + * (This is probably because even in MS's header IDirect3D9Ex > inherits from IDirect3D9, which makes the > + * C++ inferface compatible, and nobody uses the C interface in > Windows world > + */ Maybe this should be documented via Wine's API doc "BUGS: " declaration as well: http://www.winehq.org/site/docs/winedev-guide/api-docs

1 0

Re: mshtml: Do a case-insensitive compare of type (resend 1)
by Alistair Leslie-Hughes 27 Nov '08

27 Nov '08

Any thing wrong with this patch? Best Regards Alistair Leslie-Hughes "Alistair Leslie-Hughes" <leslie_alistair(a)hotmail.com> wrote in message news:492681BB.2090608@hotmail.com... > Hi, > > Changelog: > mshtml: Do a case-insensitive compare of type > -------------------------------------------------------------------------------- > >From ab3346563682349645f07147c5adbcfc3ce90ebf Mon Sep 17 00:00:00 2001 > From: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > Date: Thu, 13 Nov 2008 21:38:13 +1100 > Subject: [PATCH] Do a case-insensitive compare of type > To: wine-patches <wine-patches(a)winehq.org> > > --- > dlls/mshtml/script.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/mshtml/script.c b/dlls/mshtml/script.c > index 4d10853..90bfef9 100644 > --- a/dlls/mshtml/script.c > +++ b/dlls/mshtml/script.c > @@ -640,7 +640,7 @@ static BOOL get_guid_from_type(LPCWSTR type, GUID > *guid) > {'t','e','x','t','/','j','a','v','a','s','c','r','i','p','t',0}; > > /* FIXME: Handle more types */ > - if(!strcmpW(type, text_javascriptW)) { > + if(!strcmpiW(type, text_javascriptW)) { > *guid = CLSID_JScript; > }else { > FIXME("Unknown type %s\n", debugstr_w(type)); > -- > 1.5.4.3 > > -------------------------------------------------------------------------------- > >

1 0

re: RFC: Proposed new web site design
by Dan Kegel 26 Nov '08

26 Nov '08

Looks great so far. Comments: 1) nested scrollbars are evil. Better to put the news on its own tab, lose the little sidebar the news was in, and have a very small area in the main box for just the one most important headline. 2) The main choice text needs to be closer to user tasks. So instead of Information Overview of Wine features. we should have About What is Wine, and why should I use it? and we're missing the user task Will my app work with Wine? which should link to the appdb.

8 8

Re: atl: Remove WINAPI on static functions where not needed.
by Ken Thomases 26 Nov '08

26 Nov '08

Thanks for taking care of this, Francois. On Nov 23, 2008, at 5:15 PM, Francois Gouget wrote: > Astute readers will notice that this leaves one loophole: nasty macro > use like in dlls/winmm/message16.c: > > #define A(_x,_y) MMDRV_InstallMap(_x, \ > MMDRV_##_y##_Map16To32W, MMDRV_##_y##_UnMap16To32W, \ > MMDRV_##_y##_Map32WTo16, MMDRV_##_y##_UnMap32WTo16, \ > MMDRV_##_y##_Callback) > A(MMDRV_AUX, Aux); > > A grep would not find that MMDRV_Aux_Callback is referenced by the > above > code. Could you perhaps grep the output from the preprocessor, instead? -Ken

2 1

Re: mshtml: suppress module unloading while gecko is loaded (take 2)
by Paul Vriens 26 Nov '08

26 Nov '08

Dan Kegel wrote: > Thanks to Mike Hearn for pointing out that mshtml reference > counting was wrong, and Jacek for pointing out how to fix > it for now. > > Once gecko is loaded, don't let mshtml unload. > This fixes a crash in starting Sketchup (bug 16164), > and probably fixes a number of other apps that > went pear-shaped after unloading mshtml... > > > ------------------------------------------------------------------------ > > C++ style comment? Was this a Patchwatcher test ;) -- Cheers, Paul.

1 0

Icons as cursors patch
by Krzysztof Drewniak 25 Nov '08

25 Nov '08

This is my first patch. It allows icons to be loaded as cursors because it defaults hotspots to x = 0 and y = 0 if the hotspot isn't found. Pasting patch into body of message. This is against the latest git . -------------------------------------------------------------------------------------------------------------------------- --- cursoricon.c.orig 2008-11-23 15:07:32.000000000 -0600 +++ cursoricon.c 2008-11-23 15:13:22.000000000 -0600 @@ -932,7 +932,10 @@ static HICON CURSORICON_LoadFromFile( LP entry = CURSORICON_FindBestIconFile( dir, width, height, colors ); if ( !entry ) - goto end; + /* this is my change. If there is no hotspot, default to 0, 0. */ + hotspot.x = 0; + hotspot.y = 0; + goto iconskip; /* check that we don't run off the end of the file */ if ( entry->dwDIBOffset > filesize ) @@ -942,6 +945,7 @@ static HICON CURSORICON_LoadFromFile( LP hotspot.x = entry->xHotspot; hotspot.y = entry->yHotspot; +iconskip: hIcon = CURSORICON_CreateIconFromBMI( (BITMAPINFO *)&bits[entry->dwDIBOffset], hotspot, !fCursor, 0x00030000, width, height, loadflags ); -------------------------------------------------------------------------------------------------------------------------- Please look over the code. Krzys D.

4 7

Re: mshtml: suppress module unloading until we figure out why some apps crash with it enabled
by Jacek Caban 25 Nov '08

25 Nov '08

Dan Kegel wrote: > This prevents http://bugs.winehq.org/show_bug.cgi?id=16164 > > ( http://www.microsoft.com/msj/0197/activex/activex0197.aspx looks > like a nice, scary article on the subject. ) > - return module_ref ? S_FALSE : S_OK; + /* Some apps crash if we let mshtml be unloaded. + * Until we figure out why, don't let mshtml be unloaded. + */ + return S_FALSE; /* module_ref ? S_FALSE : S_OK; */ I think we should prevent unloading mshtml.dll if Gecko was loaded. To do it I'd suggest to increase module count in load_gecko function (it will never be decreased so DLL won't be unloaded). Jacek

1 0

Re: [PATCH] advapi: Only allow opening HKEY_CLASSES_ROOT subkeys with backslash prefix on W2K+.
by Lei Zhang 25 Nov '08

25 Nov '08

On Tue, Nov 25, 2008 at 11:35 AM, Lei Zhang <thestig(a)google.com> wrote: > Hi, > > Commit aacb511da1540fa015c5e853c90fd054b9442701 assumed NT+ behaved > the same way, but running the tests turns out it's actually W2K+. > Doh, that came out wrong. Ignore, sorry.

1 0

Re: RFC: Proposed new web site design
by chris ahrendt 25 Nov '08

25 Nov '08

Austin English wrote: > On Tue, Nov 25, 2008 at 12:27 AM, Scott Ritchie <scott(a)open-vote.org> wrote: > >> We also don't really need a link to AppDB from the big buttons in the >> front - AppDB is only the place to go when you're looking for it (hence >> the button in the upper right) or once you know something about Wine >> (hence a link in the about page). >> >> > > I disagree. You could make the same argument against > bugzilla/forums/wiki. The frontpage should serve as a portal to the > rest of the site. Many times when I needs appdb/wiki, I go to > winehq.org and then click the appropriate link. > > I agree the main page should be the portal where you go to find everything... chris p.s. kudo's on the new design!

1 0

Fw: Re: RFC: Proposed new web site design
by James Mckenzie 25 Nov '08

25 Nov '08

Sent to wrong mailing list. -----Forwarded Message----- >From: James Mckenzie <jjmckenzie51(a)earthlink.net> >Sent: Nov 25, 2008 9:01 AM >To: Wine Users Mailing List <wine-users(a)winehq.org> >Subject: Re: RFC: Proposed new web site design > >Daniel Scharrer <dscharrer(a)gmail.com> at Nov 25, 2008 8:50 AM (MST) wrote about Re: RFC: Proposed new web site design >> >>The new user-centric design looks promising. Contrary to some others I >>quite like the round corners and more modern look. Here are a few >>observations: >> >>- Light gray text on a white background is not so nice. > >This is very hard to read. I like a shade of Yellow on a Green background. White on Green is better. Easy on the eyes. White on Red is also good. > >>- I don't really like the icons too much: As others mentioned, a >>simple down arrow for the 'Download' icon might be better > >The use of the down arrow is intuitive as well. This may lead directly to an available download or download page. > >>The Development icon is really non-intuitive. Better alternatives would be >>gears or a wrench (or both). > >+1 for gears with wrench. > > >>- I think a big "Compatibility" link, as done in the re-layout, really >>belongs onto the front page. I'm guessing many users will want to know >>if their favorite app runs with wine before the download link even >>becomes relevant, both for users who are deciding weather to switch to >>Linux / Mac and those that just want to find out if there is any >>reason to upgrade from the Wine version that ships with their distro. > >I agree. A link to a Compatibility page should be on the Front Page where users can find it. The compatibility page should have categories rather than colors as well: >Runs with Wine unaltered >Runs with Wine with Windows DLLS >Partially Runs with Wine >Partially Runs with Wine with Windows DLLS >DOES NOT RUN WITH WINE (Yes, the bold is deliberate.) > >>+1 To the idea of getting screenshots back on the page, > >+1 to this as well. A small, clickable, screenshot of a running application does wonders. > >James McKenzie

1 0

Re: oleaut32: Add support for loading typelibs from NE files.
by Rob Shearman 25 Nov '08

25 Nov '08

2008/11/25 Huw Davies <huw(a)codeweavers.com>: > --- > dlls/oleaut32/typelib.c | 218 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 218 insertions(+), 0 deletions(-) Looks good. Thanks for doing this. -- Rob Shearman

1 0

Re: RFC: Proposed new web site design
by Daniel Scharrer 25 Nov '08

25 Nov '08

The new user-centric design looks promising. Contrary to some others I quite like the round corners and more modern look. Here are a few observations: - Light gray text on a white background is not so nice. - I thought it was called "Wine" and not "WINE" now. Shouldn't the "logo" at the top left reflect this? - I don't really like the icons too much: As others mentioned, a simple down arrow for the 'Download' icon might be better and the Development icon is really non-intuitive. Better alternatives would be gears or a wrench (or both). Also, I don't see a reason for them being buttons instead of just the icons over the background. Putting the icons into a box just detracts from the icons themselves, at least for me. Also, would it kill to user other colors than than those dictated by the theme for the icons? Compare this to http://www.openoffice.org/ which I'm guessing this design is based on. - I think a big "Compatibility" link, as done in the re-layout, really belongs onto the front page. I'm guessing many users will want to know if their favorite app runs with wine before the download link even becomes relevant, both for users who are deciding weather to switch to Linux / Mac and those that just want to find out if there is any reason to upgrade from the Wine version that ships with their distro. - As many others, I also despise secondary scroll bars. Right now the news content shows way too much redundancy: The "Latest Releases" box, the title of the latest news entry as well as it's first sentence all just say "The latest Wine version is 1.1.8" and they are right next to each other. Is there some way to combine this? How about just: Latest stable release (links to release page) Latest release (also links to it's own release page) Release date. Major changes. 1/2 Non-release news items (WWN,...) Also, even when resizing the browser window to the point where a horizontal scroll bar appears there is still quite a bit of white space in the center, yet the news box has a small fixed width that forces line breaks in the release change summary bullet points. +1 To the idea of getting screenshots back on the page, it's surprising how much a little eye candy can do.They should however be more up to date (perhaps automatically linked from platinum apps on the AppDB) and as was suggested link back to the relevant AppDB entry. Regards, Daniel Scharrer

1 0

Internet Explorer running in Wine usefull for performance testing
by Joris Huizer 25 Nov '08

25 Nov '08

Hello, Just as Dan Kegel likes to announce on the list, how Wine gets mentioned out on the internet, I thought this may be interesting/motivating to you. This page, http://ejohn.org/blog/accuracy-of-javascript-time/, mentions (big) problems in testing javascript performances (there's some interest in that in the new race between webbrowsers), when running IE (and other browsers) on Windows, which are fixed when running it under Wine (in this case on a Mac) Regards, Joris

1 0

Windows mobile and ARM
by Scott Ritchie 25 Nov '08

25 Nov '08

Is it at all feasible to run Windows mobile apps under Wine? From what I understand it's supposed to be largely the same API as standard Win32. How about a port to ARM for the purpose of running Windows Mobile apps, or just recompiled Winelib apps? Ubuntu is getting serious about its ARM port, so if Wine/ARM becomes a reality within the next, say, 2 years the potential for quickly developing mobile applications by just porting Windows ones is huge. Theoretically, we could run Windows applications on a jailbroken iPhone. Thanks, Scott Ritchie

4 3

Bugs not linked to appdb
by Dan Kegel 25 Nov '08

25 Nov '08

Somebody asked if there was a way to find out which bugs were not yet linked into the appdb. There ought to be, but I don't know of one, so I ran the report the hard way last night. It's at http://kegel.com/wine/unlinked.html - Dan

1 0

Re: Revert "mshtml: Added support for DOCHOSTUIFLAG_SCROLL_NO DOCHOSTINFO flag."
by Jacek Caban 25 Nov '08

25 Nov '08

Vitaliy Margolen wrote: > Since Jacek did not comment on the bug 14311, revert patch in question. It > restores 100% functionality of the scrollbars in Steam. > The fact that I didn't comment doesn't mean anything. I didn't have time to work on it and I'm currently looking at it (BTW, with today git other Steam bug is fixed). I know that it doesn't make any difference for user, but from technical point of view, there was no regression. Steam draws its own scrollbars and doesn't use built-in MSHTML scrollbars. Previously there were two bugs: - MSHTML scrollbars were not hidden - Steam scrollbars didn't work The patch that you want to revert (with fixes apps like CS3 installer) fixed the first problem. Now the second one needs to be fixed. Jacek

3 2

Re: [6/6] gdiplus: implement GdipGetRegionHRgn for combined regions
by Vincent Povirk 25 Nov '08

25 Nov '08

I leaked a region in this last one. Please don't apply it. Vincent Povirk On Mon, Nov 24, 2008 at 5:34 PM, Vincent Povirk <vincent(a)codeweavers.com> wrote: > > > >

1 0

Re: mshtml: Add new interfaces into mshtml.idl (try 2)
by Alistair Leslie-Hughes 24 Nov '08

24 Nov '08

Hi Konstantin, > Kondratyuk wrote: > Hello! > > Try 2 changes: > - add missed POINTER_GRAVITY_Max, MARKUP_CONTEXT_TYPE_Max, SELECTION_TYPE_Max > constants > - correct attributes of interfaces: object, pointer_default(unique), uuid(...) > - correct attributes Right and Left methods in IMarkupPointer interface > Non of the Functions in IMarkupPointer should be marked as retval, likewise for IMarkupContainer. IElementSegment functions are in the wrong order, likewise for ISelectionServicesListener, ISelectionServices and IHTMLEditServices. Also you will need to double check the [] values, since you have retval where they are not needed. If you have a copy of the mshtml.tlb you can verify the interfaces by using wine's oleview program. Best Regards Alistair Leslie-Hughes

2 2

adding DEVICEMAP\HARDWARE registry entries
by A C Hurst 24 Nov '08

24 Nov '08

Dear winehackers, I sent this patch to wine-patches, with a few iterations of editing, and wondered if I could have some feedback on it, before I just resend it. Andy

3 4

Re: Revert "mshtml: Added support for DOCHOSTUIFLAG_SCROLL_NO DOCHOSTINFO flag."
by Reece Dunn 24 Nov '08

24 Nov '08

2008/11/24 Vitaliy Margolen <wine-patches(a)kievinfo.com>: > Since Jacek did not comment on the bug 14311, revert patch in question. It > restores 100% functionality of the scrollbars in Steam. This is not the correct fix. Simply reverting a patch because it broke an application without understanding why is not the right way to go. In this case, some applications (http://bugs.winehq.org/show_bug.cgi?id=13459) specify the DOCHOSTUIFLAG_SCROLL_NO flag to specifically not show any scrollbars. In the case of bug 13459, the intro page does not render correctly if scrollbars are shown (and on Windows you don't see any scrollbars). What is the behaviour on Windows? Can you explain comments 3 and 8? - Reece

2 1

Good news regarding Wine and patent threats
by Scott Ritchie 24 Nov '08

24 Nov '08

There's a groklaw article summarizing recent discussion about the impact of the Bilski case on software patents: http://www.groklaw.net/article.php?story=20081102011538422 "The judge says this kind of cloning could be done without infringing Microsoft's copyrights, but how about its patents? Prior to Bilski, one might give one answer. Now, one might give another." If we thought Wine unlikely to be attacked by Microsoft due to nebulous patent issues and anti-trust implications, it's even less likely now. Thanks, Scott Ritchie

1 0

Spaces before '...' in Slovenian
by Francois Gouget 24 Nov '08

24 Nov '08

Does anyone (especially Rok Mandeljc) know if, in Slovenian: 1) '...' must be preceded by a space 2) '...' must not be preceded by a space 3) either form is valid -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy

2 1

Re: adding DEVICEMAP\HARDWARE registry entries
by A C Hurst 24 Nov '08

24 Nov '08

> > The code in oldconfig.c is called by process.c/__wine_kernel_init(), on server startup. > > The entries are volatile, and are dynamically created if you count scanning > wineprefix/dosdevices/ > > and doing a stat() on anything named com[1-9] it finds there every time wine starts up. > > I could just call get_dos_device and let it do the stat calls, but it would be less efficient, > and > > you'd end up with registry entries for the successes of get_default_com_device, not just the > ones > > symlinked in dosdevices > > You don't want to depend on the symlinks, things should work without > requiring the user to create any symlink. It should depend on what > actual devices are present on the machine, and probably be done > somewhere in the HAL support. Would using get_dos_device() be better, since that does fall through to default behaviour when the symlink isn't there? I chose oldconfig.c since that's where the \DEVICEMAP\Scsi entries get built. Would the scsi stuff want moving over to HAL too?

2 1

Re: atl: Remove WINAPI on static functions where not needed.
by Chris Robinson 24 Nov '08

24 Nov '08

On Sunday 23 November 2008 03:15:36 pm Francois Gouget wrote: > To quote Ken Thomases who did the research on this issue with Alexandre: > > This is motivated by a gcc bug that we've encountered on the Mac. On > the Mac, WINAPI (and other declspecs) include the > force_align_arg_pointer attribute. With -O2 optimization (actually > -funit-at-a-time, implied by -O2) the compiler may change the calling > convention used by non-exported functions to take arguments via > registers rather than on the stack. The prologue generated for > force_align_arg_pointer clobbers one of those registers (and hence > one of the arguments). > > Alexandre's preferred solution is to find and eliminate such cases. > Even if/when the compiler bug is fixed, those functions should still > not have the extraneous declspec. Out of curiousity, then, does this affect static functions that are used for COM objects? It's typical for those to be marked as static, their address put into a (possibly static) vtable struct, which is then used as a field for an allocated struct passed to the user.

2 1

Re: d3d9: Remove WINAPI on static functions where not needed.
by Vitaliy Margolen 24 Nov '08

24 Nov '08

Francois Gouget wrote: > --- > > If you know other places where the functions touched by this patch > are used, please let me know. For more details, see: > > /* This isn't in MSDN! > -static HRESULT WINAPI IDirect3DDevice9Impl_GetFrontBuffer(LPDIRECT3DDEVICE9EX iface, IDirect3DSurface9* pDestSurface) { > +static HRESULT IDirect3DDevice9Impl_GetFrontBuffer(LPDIRECT3DDEVICE9EX iface, IDirect3DSurface9* pDestSurface) { > IDirect3DDevice9Impl *This = (IDirect3DDevice9Impl *)iface; > FIXME("(%p) : stub\n", This); > return D3D_OK; You can't do that. It's part of the v-table so it can be called by user application. Vitaliy

3 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel