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

Re: dlls/opengl32/wgl.c: minor dealloc fix

by Nick Burns

According to... http://msdn2.microsoft.com/en-us/library/aa366701.aspx lpMem [in] ...If this pointer is NULL, the behavior is undefined. I personally dislike undefined behaviour -- If it is defined to NOP in wine that is sufficent for me. But I think/tought I had a crash there tho... - Nick >From: Stefan Dösinger <stefandoesinger(a)gmx.at> >To: wine-devel(a)winehq.org >CC: Nick Burns <adger44(a)hotmail.com> >Subject: Re: dlls/opengl32/wgl.c: minor dealloc fix >Date: Mon, 1 Jan 2007 22:33:49 +0100 > > >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. > > >

Jan. 1, 2007

Re: RFC: OpenAL32.dll thunk -- demacroized

by Stefan Dösinger

Am 01.01.2007 um 12:06 schrieb Nick Burns: > 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 Some things I noticed The openal.c header: +/* Written by Nick Burns (adger44(a)hotmail.com) */ +/* while sick */ +/* now demacroized */ I think you should take the usual LGPL header that all the other files use. With regard to the traces, I think the usual convention is to write all the function parameters in the trace. I don't know how well this can be done, and I imagine that it is quite some work and makes autogeneration with a script(like opengl) much harder. If the openal headers are missing you use stubs that just print a fixme. This is fine, but I think the fixme's should be ERRs. The DllMain library in that case should maybe return FALSE in that case, so the app can deal with the lack of openal(or just fail) I will give the new version another try with Jedi Academy :-) Stefan

Jan. 1, 2007

Re: dlls/opengl32/wgl.c: minor dealloc fix

by Stefan Dösinger

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.

Jan. 1, 2007

Re: wineded3/vertexbuffer.c: dirtyend set to more than resource size

by Stefan Dösinger

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

Jan. 1, 2007

re: ppviewer.exe MSI failure (PowerPoint 2k3): HowTo assemble a lynch

by Dan Kegel

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

Jan. 1, 2007

Re: winex11: Use GLXFBConfig for the pixel format list

by Chris Robinson

On Monday 01 January 2007 00:47, Vitaliy Margolen wrote: > Please don't send compressed patches. It's not that huge to gzip it. Sorry. > > + WineGLFBConfigsListSize = 1; > > + WineGLDisplayablePixelFormatListSize = 1; > > If you hard-coding the list size to 1 it's not a list anymore, but a > single element. Originally, the list contained the full FBConfig list and dealt with it accordingly. But Thunderbird/Roderick said he'd prefer if the patch didn't do that and just retained the single main visual for now. Unless I misunderstood him.. > > @@ -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? Originally that section was turned into a loop to deal with the list, and the choose_exit would be used to skip to the next iteration. But Roderick said he didn't want that turned into a loop yet so I removed the for() bit, and that got left. > 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. According to the docs, "glXMakeCurrent returns True if it is successful, False otherwise." And since the function returns what glXMakeCurrent returns, the call is not assumed to succeed. Without it, glXMakeCurrent may cause the program to abort before the rest of the program knows it failed. But I suppose that too should be sent seperately.. Apologies. I'll split up the patch and send the relavant parts.

Jan. 1, 2007

Re: Reason for some process failures in kernel32 tests

by Wagner Ferenc

Paul Vriens <paul.vriens.wine(a)gmail.com> writes: > On Mon, 2007-01-01 at 16:25 +0100, Wagner Ferenc wrote: > >> Paul Vriens <paul.vriens.wine(a)gmail.com> writes: >> >>> 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)) { >> ,--------------------------^ >> MSDN: If this parameter is NULL, the new process will have the same >> current drive and directory as the calling process. >> >> The CreateProcess documentation is rather convoluted, though. The >> first NULL also seems risky on first read. > > That was exactly my point when putting in that piece of code :-). > > This also means (me thinks) that the start-directory is used instead of > the working-directory. > > Another approach would be to have winetest change the directory to the > working directory. I was under the impression that winetest changed its working directory to the temporary directory it creates. Looks like it does not, probably so that it can remove the directory in the end. Either main()'s tempdir variable should be passed to run_test() and later to run_ex() for passing to CreateProcessA(), or the working directory should be changed after creating and before removing it in main(), I guess. -- Feri.

Jan. 1, 2007

Re: Reason for some process failures in kernel32 tests

by Paul Vriens

On Mon, 2007-01-01 at 16:25 +0100, Wagner Ferenc wrote: > Paul Vriens <paul.vriens.wine(a)gmail.com> writes: > > > 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)) { > ,--------------------------^ > MSDN: If this parameter is NULL, the new process will have the same > current drive and directory as the calling process. > > The CreateProcess documentation is rather convoluted, though. The > first NULL also seems risky on first read. That was exactly my point when putting in that piece of code :-). This also means (me thinks) that the start-directory is used instead of the working-directory. Another approach would be to have winetest change the directory to the working directory. Cheers, Paul.

Jan. 1, 2007

Re: Reason for some process failures in kernel32 tests

by Wagner Ferenc

Paul Vriens <paul.vriens.wine(a)gmail.com> writes: > 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)) { ,--------------------------^ MSDN: If this parameter is NULL, the new process will have the same current drive and directory as the calling process. The CreateProcess documentation is rather convoluted, though. The first NULL also seems risky on first read. -- Feri.

Jan. 1, 2007

missing BITS service workaround

by Robert Reif

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?

Jan. 1, 2007