wine-devel January 2007

wine-devel@winehq.org

137 participants
274 discussions

Re: ntdll: remove an unnecessary NULL check : Coverity
by Dmitry Timoshkov 02 Jan '07

02 Jan '07

"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 02 Jan '07

02 Jan '07

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 02 Jan '07

02 Jan '07

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 02 Jan '07

02 Jan '07

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 01 Jan '07

01 Jan '07

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 01 Jan '07

01 Jan '07

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 01 Jan '07

01 Jan '07

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 01 Jan '07

01 Jan '07

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 01 Jan '07

01 Jan '07

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 01 Jan '07

01 Jan '07

$ 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

Jump to page:

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 January 2007