January 2007 - Wine-Devel - list.winehq.org

Re: [PATCH 1/3] [Msvcrt]: reset a signal to DFL after it's been used
by Alexandre Julliard Jan. 2, 2007

Jan. 2, 2007

Eric Pouech <eric.pouech(a)wanadoo.fr> writes: > @@ -455,13 +456,13 @@ static LONG WINAPI msvcrt_exception_filt > case EXCEPTION_FLT_OVERFLOW: > case EXCEPTION_FLT_STACK_CHECK: > case EXCEPTION_FLT_UNDERFLOW: > - if (sighandlers[MSVCRT_SIGFPE]) > + if ((handler =3D sighandlers[MSVCRT_SIGFPE]) !=3D MSVCRT_SIG_DFL= > ) > { > - if (sighandlers[MSVCRT_SIGFPE] !=3D MSVCRT_SIG_IGN) > + sighandlers[MSVCRT_SIGSEGV] =3D MSVCRT_SIG_DFL; > + if (handler !=3D MSVCRT_SIG_IGN) You have to check for SIG_IGN first, the handler should not be reset in that case. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: systray [2]: transparent icons: let systray window responsible for background
by Kirill K. Smirnov Jan. 2, 2007

Jan. 2, 2007

> "Kirill K. Smirnov" <lich(a)math.spbu.ru> writes: > > > @@ -366,6 +366,7 @@ static void systray_dock_window( Display > > > > wine_tsx11_lock(); > > XSendEvent( display, systray_window, False, NoEventMask, &ev ); > > + XSetWindowBackgroundPixmap(display, data->whole_window, ParentRelative); > > wine_tsx11_unlock(); > > This won't really do what you want. You have to set the window shape > if you want the background to be properly transparent. Now I understand, that the problem is more hard than I think before. 1) The code I sent is the solution... unless the application change icon. In this case new icon is painted over and produces a mixture. 2) If I set window shape to 'AND' bitmap of icon (do I correctly understand you?) then what to do with full transparent icons? E.g. some applications (qip) flashes the icons by changing the icon with full transparent icon and back. a) Will window with NULL shape be created? b) if a) is true, then when I click on null icon will I get any events? For some time I wonder, why kde icons looks good even when they are changing??? The answer is kde applications use KSystemTray directly without XEMBED. xmule to achieve the same goal, removes the icon from systray and adds new one (as I understand it, I may wrong). Shall we use the same mechanism? Any other suggestion?

2 1

World of Warcraft Progress
by darckness Jan. 2, 2007

Jan. 2, 2007

Ahoy! First off, I'd like to say happy 2007! Hope you all did some good celebrating. I know I did ;) Anyway, I've been doing some testing on World of Warcraft, and I noticed some things of interest (Latest wine version from cvs/git, no patches applied). First off, the D3D (DX9) runs MUCH better (faster and more smoothly) than the OGL mode. Big kudos to you guys; last time I played, the D3D mode was completely unusable because there was no D3D support in wine. Very impressive. The OGL performance isn't bad by any means, but it isn't great either. I was running some traces as I played, but nothing in particular seemed to be the culprit in terms of choppiness, so it's possible that it could just be my system. I'll write back soon when I have more conclusive evidence. Additionally, OGL mode crashes any time I attempt to change a video setting, something that does not happen in D3D mode. The load time (both startup and between zones/etc) is at least 10x faster than it used to be. I know that Blizzard has been working on this a bit, but based on what I've seen on systems running Windows, the load time reduction seems largely due to improvements in wine. I guess my only real complaint at this point, since the D3D mode woks so well, is that the X cursor still shows up in the game window along with the game cursor. I vaguely recall having this problem a long long time ago in OGL mode, but I can't remember exactly what caused it or how it was fixed. Anyone have a better memory than I do? That's pretty much the state of WoW at the moment. Comments/Questions/Solutions?

3 2

Re: Resend: d3d9: fix failing tests on windows, when no 3d hardware acceleration is available
by Ivan Gyurdiev Jan. 2, 2007

Jan. 2, 2007

Louis. Lenders wrote: > Hi, is there anything wrong with this patch? If so, could you please > tell me what. Thx > > */"Louis. Lenders" <xerox_xerox2000(a)yahoo.co.uk>/* wrote: > > Hi, this patch should fix failing tests in d3d9, like you see for > example here: > http://test.winehq.org/data/200612231000/ > > Appearently the tests in stateblock.c didn't need to be modified, > as they create the device with flag D3DDEVTYPE_NULLREF; these > tests do not fail anywhere. > > thanks for some advice from stringfellow > ------------------------------------------------------------------------ > So why not fallback to REF or NULLREF type of device everywhere else if HAL is unavailable? Do those tests need HAL support in the first place?

2 1

Re: Resend: d3d9: fix failing tests on windows, when no 3d hardware acceleration is available
by Alexandre Julliard Jan. 2, 2007

Jan. 2, 2007

"Louis. Lenders" <xerox_xerox2000(a)yahoo.co.uk> writes: > Hi, is there anything wrong with this patch? If so, could you please tell me what. Thx I fixed it up, but next time please try to respect the indentation style of the existing file. We don't have any place that uses a strange style like this: > + if(FAILED(hr)) > + { > + trace("could not create device, IDirect3D9_CreateDevice returned %#x\n", hr); > + goto cleanup; > + } -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: systray [2]: transparent icons: let systray window responsible for background
by Alexandre Julliard Jan. 2, 2007

Jan. 2, 2007

"Kirill K. Smirnov" <lich(a)math.spbu.ru> writes: > @@ -366,6 +366,7 @@ static void systray_dock_window( Display > > wine_tsx11_lock(); > XSendEvent( display, systray_window, False, NoEventMask, &ev ); > + XSetWindowBackgroundPixmap(display, data->whole_window, ParentRelative); > wine_tsx11_unlock(); This won't really do what you want. You have to set the window shape if you want the background to be properly transparent. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: dlls/opengl32/wgl.c: minor dealloc fix
by Stefan Dösinger Jan. 2, 2007

Jan. 2, 2007

Am 01.01.2007 um 11:03 schrieb Nick Burns: > There can be a problem where the detach is hit before > internal_gl_extensions is allocated and it tries to free NULL and > dies... > > This just checks for the allocation before freeing -- very minor > > - Nick HeapFree(GetProcessHeap(), 0, NULL) is supposed to be a nop, so the check is not needed.

4 5

Re: [9/16] WineD3D: Move decoding the vertex declaration to the device
by Ivan Gyurdiev Jan. 2, 2007

Jan. 2, 2007

+ if (stateblock->wineD3DDevice->vs_selected_mode != SHADER_NONE && stateblock->vertexShader && + ((IWineD3DVertexShaderImpl *)stateblock->vertexShader)->baseShader.function != NULL) + memcpy(&stateblock->wineD3DDevice->strided_streams, stateblock->wineD3DDevice->up_strided, sizeof(stateblock->wineD3DDevice->strided_streams)); + primitiveDeclarationConvertToStridedData((IWineD3DDevice *) stateblock->wineD3DDevice, useVertexShaderFunction, + &stateblock->wineD3DDevice->strided_streams, &stateblock->wineD3DDevice->streamFixedUp); My eyes hurt - can we *please* store the device in a local variable. Also, I am not sure how we got to the point where this many upward references to the device from the stateblock are necessary - there has to be something wrong with that: a stateblock captures the state of a device, so why is it referring back to its parent device and looking up state there? This type of thing was introduced into the shader code as well, and IIRC it was wrong there too. Also, all this transient data from the drawprim codepath moved into the device - can you explain again why that's necessary, does it really need to persist after the drawprim call?

2 1

Re: wininet: ensure null check before dereference
by James Hawkins Jan. 2, 2007

Jan. 2, 2007

On 1/1/07, Jeff Latimer <lats(a)yless4u.com.au> wrote: > Coverity cid: 367 Do the null check before the dereference. Given that > this is an simple internal function, do we need to check for null pointers? > Generally we don't check for NULL params in internal functions. -- James Hawkins

1 0

Re: dbghelp: Search for .gnu_debuglink file
by Eric Pouech Jan. 2, 2007

Jan. 2, 2007

Frank Richter a écrit : > The .gnu_debuglink section contains only a bare filename, however, the > debug file can be in a number of locations. These are stated in the > GDB manual and are now searched when a .gnu_debuglink is encountered. Frank, a couple of remarks: - there are memory leaks in the code (moduleDir can be leaked, as well as the newly found pathname) - for the code to still be readable, I'd rather but in a single function all the processing required, ie. do it the same way as for the other debug information: if the .gnu_debuglink section is found, map it, and then let this new function handle the lot A+

1 0

Re: ntdll: remove an unnecessary NULL check : Coverity
by Dmitry Timoshkov Jan. 2, 2007

Jan. 2, 2007

"Jeff Latimer" <lats(a)yless4u.com.au> wrote: > Coverity Cid:344 highlighted a REVERSE-INULL. This patch removes the > redundant null tests as it is clear from the code above that the pointer > has already been used to dereference and can't be null. Yes, 'attr' is used without a NULL check earlier, but that's an actual bug, and that's where the code needs to be fixed. -- Dmitry.

2 4

help with dll
by xie jason Jan. 2, 2007

Jan. 2, 2007

Hi there, My name is Jason. I am trying to compile my windows application under linux. I found that the dll file i use to build mu application links to some other dlls. i was just wondering that when i compile it under linux, do i need to compile with those dlls. if yes, it will be very troublesome since they are quite a lot and i have no access to the header files. thanks Jason Send instant messages to your online friends http://au.messenger.yahoo.com

1 0

Re: What to do about apps that require 256-color mode?
by Dan Kegel Jan. 2, 2007

Jan. 2, 2007

On 1/1/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > > So what's Wine to do? Can we somehow tell Wine > > to emulate 256 color mode for particular apps? > > If it is a DirectDraw application then wine will emulate 256 color > mode(palettized colors). The app in question is "I Spy Junior", which seems to have been written in 1999 using Macromedia (probably Director). It has a free trial which can be downloaded at http://www.scholastic.com/kids/downloads2go/productDetail.asp?productid=5&s… but the trial doesn't get as far as the real app, it seems to get stuck even in 8 bpp mode before putting up a window. (I'll file a bug...) - Dan

1 0

RFC: OpenAL32.dll thunk -- demacroized
by Nick Burns Jan. 2, 2007

Jan. 2, 2007

Here is my OpenAL32.dll thunk demacroized. Sorry this took so long -- finally got some time with the break. This is basically the same patch as before -- supports the same functionality and all -- but no more cool macros (of doom) (~500 lines -> ~1500 lines) I have added as many extensions as I could find to this thunk. (no idea on where these extensions are available) I would like to fix up the extension handling at some point (basically it needs to be more like OpenGL) I would like any comments on this patch And would hopefully like to get it in wine - Nick

2 2

Re: wineded3/vertexbuffer.c: dirtyend set to more than resource size
by Stefan Dösinger Jan. 1, 2007

Jan. 1, 2007

Am 01.01.2007 um 19:08 schrieb Christoph Bumiller: > I'm not 100% sure of this but I think IWineD3DVertexBufferImpl- > >dirtyend can't be more than ->resourse.size and if so this is a > bug (please correct me if I'm wrong); and so if SizeToLock is zero > dirtyend should be set to resource.size in both cases (buffer dirty > or not): Yeah, makes sense to me :-) > --- > dlls/wined3d/vertexbuffer.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/wined3d/vertexbuffer.c b/dlls/wined3d/vertexbuffer.c > index 820309f..4f350bb 100644 > --- a/dlls/wined3d/vertexbuffer.c > +++ b/dlls/wined3d/vertexbuffer.c > @@ -439,7 +439,7 @@ static HRESULT WINAPI IWineD3DVertexBuf > if(SizeToLock) > This->dirtyend = OffsetToLock + SizeToLock; > else > - This->dirtyend = OffsetToLock + This->resource.size; > + This->dirtyend = This->resource.size; > } > > if(This->resource.allocatedMemory) { > -- > 1.4.4 > >

1 0

re: ppviewer.exe MSI failure (PowerPoint 2k3): HowTo assemble a lynch
by Dan Kegel Jan. 1, 2007

Jan. 1, 2007

Andreas wrote: > [ppviewer 2003] > failed to install with some nice MSI failures when I tried it last week on a current > Wine version (Ubuntu package 0.9.28, I think). > > Does that mean that I'm entitled to assemble a capable lynch mob for the guys > who were supposed to fix any and all MSI installer issues at CodeWeavers? ;) First: it's not even funny with the smily. You have no idea how hard MSI was. Second: they weren't all Codeweavers guys. Third: did you file a bug? Tsk. Fourth: carrots work better than sticks. I'd say your best bet is to send James Hawkins a couple of pizzas :-) - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Re: winex11: Use GLXFBConfig for the pixel format list
by Vitaliy Margolen Jan. 1, 2007

Jan. 1, 2007

Chris Robinson wrote: > This greatly simplifies some of the wgl code by keeping around a single > customized fbconfig array, instead of holding a static, custom-typedef array > which left many functions to query glx for the fbconfig list anyway (which in > turn caused many needless, potentially problematic allocations and > deallocations of memory). > > This doesn't change the behavior of the code, but it makes it simpler for > future enhancements (such as supporting extra fbconfigs for on-screen or > off-screen use), and easier maintanence by removing a lot of duplicate code. Please don't send compressed patches. It's not that huge to gzip it. > + WineGLFBConfigsListSize = 1; > + WineGLDisplayablePixelFormatListSize = 1; If you hard-coding the list size to 1 it's not a list anymore, but a single element. > @@ -670,7 +718,7 @@ static int ConvertAttribWGLtoGLX(const i > switch (pop) { > case WGL_TYPE_COLORINDEX_ARB: pop = GLX_COLOR_INDEX_BIT; isColor = 1; break ; > case WGL_TYPE_RGBA_ARB: pop = GLX_RGBA_BIT; break ; > - case WGL_TYPE_RGBA_FLOAT_ATI: pop = GLX_RGBA_FLOAT_ATI_BIT; break ; > + case WGL_TYPE_RGBA_FLOAT_ARB: pop = GLX_RGBA_FLOAT_BIT; break ; > default: > ERR("unexpected PixelType(%x)\n", pop); > pop = 0; This code seems like unrelated to the description. Please send it as a separate patch. > @@ -681,12 +729,7 @@ static int ConvertAttribWGLtoGLX(const i > > case WGL_SUPPORT_GDI_ARB: > pop = iWGLAttr[++cur]; > - /* We only support a limited number of formats which are all renderable by X (similar to GDI). > - * Ignore this attribute to prevent us from not finding a match due to the limited > - * amount of formats supported right now. This option could be matched to GLX_X_RENDERABLE > - * but the issue is that when a program asks for no GDI support, there's no format we can return > - * as all our supported formats are renderable by X. > - */ > + PUSH2(oGLXAttr, GLX_X_RENDERABLE, pop); > TRACE("pAttr[%d] = WGL_SUPPORT_GDI_ARB: %d\n", cur, pop); > break; > Your description said nothing about altering this behavior stated in comments. Same for the PUSH, and lots of other changes. It seems to me that you have at least 3-5 separate patches here. Please split them and send them separately. > @@ -1037,13 +987,13 @@ int X11DRV_ChoosePixelFormat(X11DRV_PDEV > /* When we pass all the checks we have found a matching format :) */ > ret = 1; > TRACE("Successfully found a matching mode, returning index: %d\n", ret); > +choose_exit: > + ; > } > > -choose_exit: > if(!ret) > TRACE("No matching mode was found returning 0\n"); > Why do you need this change? > @@ -1519,11 +1458,13 @@ BOOL X11DRV_wglMakeCurrent(X11DRV_PDEVIC > * We are certain that the drawable and context are compatible as we only allow compatible formats. > */ > TRACE(" Creating GLX Context\n"); > - ctx->ctx = pglXCreateContext(gdi_display, ctx->vis, NULL, type == OBJ_MEMDC ? False : True); > + create_glx_context(physDev, ctx, NULL); > TRACE(" created a delayed OpenGL context (%p)\n", ctx->ctx); > } > TRACE(" make current for dis %p, drawable %p, ctx %p\n", gdi_display, (void*) drawable, ctx->ctx); > + X11DRV_expect_error(gdi_display, error_catcher, NULL); > ret = pglXMakeCurrent(gdi_display, drawable, ctx->ctx); > + X11DRV_expect_error(gdi_display, NULL, NULL); > NtCurrentTeb()->glContext = ctx; > if(ret) > { Can you explain this one a bit? Your error_catcher() does nothing, except ignoring the error. Yet here you assuming that calls succeeded and continue on, assigning the context to a thread which won't have the context assigned. Vitaliy.

3 2

Reason for some process failures in kernel32 tests
by Paul Vriens Jan. 1, 2007

Jan. 1, 2007

Hi, I've been trying to tackle some of the issues we have when trying to run some process tests (through winetest.exe, see also http://test.winehq.org/data) process.c:775: Test failed: CreateProcess (./kernel32_test.exe tests/process.c C:\TEMP\wt44.tmp "a\"b\\" c\" d) failed : 2 process.c:777: Test failed: Child process termination process.c:781: Test failed: Arguments:argvA0 expected './kernel32_test.exe', got '(null)' process.c:790: Test failed: CreateProcess (.\kernel32_test.exe tests/process.c C:\TEMP\wt45.tmp "a\"b\\" c\" d) failed : 2 process.c:792: Test failed: Child process termination process.c:796: Test failed: Arguments:argvA0 expected '.\kernel32_test.exe', got '(null)' process.c:810: Test failed: CreateProcess (..\wct12/kernel32_test.exe tests/process.c C:\TEMP\wt46.tmp "a\"b\\" c\" d) failed : 2 process.c:812: Test failed: Child process termination process.c:816: Test failed: Arguments:argvA0 expected '..\wct12/kernel32_test.exe', got '(null)' The reason for this particular one is that I'm running winetest.exe started from a command-file on my desktop. This means that the current directory is the desktop directory. The winetest gui shows that the working directory is (in this case) c:\temp\wct12. This value is however not passed to the tests when CreateProcess is run: main.c: 291 if (!CreateProcessA (NULL, cmd, NULL, NULL, TRUE, 0, 292 NULL, NULL, &si, &pi)) { The above means that the kernel32_test.exe has a working directory that is not c:\temp\wct12 (in this case again) and thus cannot find the executable when referenced relatively. All the test-results that are shown on http://test.winehq.org show more-or-less the same behavior. How can I retrieve the correct working directory (as shown in the winetest gui) and pass that to the single tests? (I think that would solve these particular issues). Cheers and thanks for any pointers, Paul.

3 5

missing BITS service workaround
by Robert Reif Jan. 1, 2007

Jan. 1, 2007

There is a registry workaround I have used in the past for installers that complain about BITS service but I can't remember what it is or find it using searches. Does anyone remember the workaround?

1 0

Stats
by Hans Leidekker Jan. 1, 2007

Jan. 1, 2007

$ for y in {2002..2006}; do \ n=$( git log | grep ^Date: | grep $y | wc -l ); \ echo "Number of patches in $y: $n"; \ done Number of patches in 2002: 3094 Number of patches in 2003: 3283 Number of patches in 2004: 3851 Number of patches in 2005: 6006 Number of patches in 2006: 8404 -Hans

1 0

.SYS Drivers
by Andrew Neil Ramage Jan. 1, 2007

Jan. 1, 2007

Is there any way to interface between the hardware and windows .SYS and .VXD device drivers ? If it is possible, I would be interested in writing the interface. -- Andrew "Oh, bother," said the Borg. "We've assimilated Pooh."

2 1

Re: Problems with the serial interface
by Eric Pouech Jan. 1, 2007

Jan. 1, 2007

Reinhard Karcher a écrit : > Hello wine developers, > > the attached patch fixes some issues I had with the 16 bit configuration > program for our SOHO PBX. > Hi Reinhard, thanks the work on the attached patch items #1 and #4 look ok to me I'm not sure about #2. Does it make a real difference for your program ? regarding #3, it's a left over from old code, where we handled differently read and write operations. However, your proposed fix looks acceptable (and is similar to what is done for ReadComm16 anyway). I'd suggest anyhow to split this patch in smaller chunks, since they don't correlate at all (in their fixes) you should provide : - #1 & #2 together (if #2 is really needed) (as typos in ntdll/serial.c code) - #3 as a speed improvement for 16bit comm support - #4 as an erroneous wait operation A+

1 0

Wine 32-bit address space
by Nick Burns Jan. 1, 2007

Jan. 1, 2007

According to http://msdn2.microsoft.com/en-gb/library/aa366912.aspx The range 3GB (0xC0000000) - 4GB (0xFFFFFFFF) is considered system memory and apps should not write here (not sure why you would want to read from there either). But Wine tries to mmap this range (on Mac OSX at least) I was wondering why this is? Should this range just be left as it is? -- is there a reason to mmap this range? Any ideas? for reference -- this mmap is spurred from libs/wine/mmap.c:356 (mmap_init) - Nick

2 3

winbench '96 (and '97)
by Dan Kegel Jan. 1, 2007

Jan. 1, 2007

After trying out Winbench '99 without too much success, (http://www.winehq.org/pipermail/wine-devel/2006-December/052818.html) I managed to buy a copy of Winbench '96 on ebay for $3 or so. It seems a little closer to running -- the things that stop it appear to be more garden variety problems, not whacky COM stuff. While there aren't any more copies on ebay, I discovered that searching http://froogle.com for winbench found three books that come with a copy of the tool: "Using Windows 95 : Platinum Edition" (0789707977) comes with Winbench '96 "Optimizing Windows 95 & Windows NT 4.0" ( 0789708418) comes with Winbench '97 "Tom's Hardware Guide" (0789716860) comes with an unspecified version, maybe '99 (which is downloadable anyway, so maybe that's not so interesting). I guess I'll pick up a copy of that one that comes with Winbench '97 just for completeness... - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0