June 2009 - Wine-Devel - list.winehq.org

Re: winedbg italian translation
by Nikolay Sivov June 28, 2009

June 28, 2009

Davide Pizzetti wrote: > Il giorno dom, 28/06/2009 alle 16.39 +0400, Nikolay Sivov ha scritto: > >> Davide Pizzetti wrote: >> >>> i think i made a little mess with the files for winedbg. how do i >>> restore the situation to the previous state? >>> Il giorno dom, 28/06/2009 alle 16.14 +0400, Nikolay Sivov ha scritto: >>> >>> >>>> Davide Pizzetti wrote: >>>> >>>> >>>>> Here's the italian translation for winedbg >>>>> >>>>> >>>>> >>>> Hi, Davide. >>>> >>>> This patch is malformed too. >>>> >>>> When you need to create new file in repo, first create it in your file >>>> system, then do 'git add programs/winedbg/rsrc_It.rc' . >>>> This will add it to your repo. Don't forget to edit rsrc.rc file too to >>>> add your new created resource file. >>>> >>>> Bye. >>>> >>>> >> Save your edited files somewhere outside tree to keep your work. After >> that do 'git reset --hard origin' >> this will reset your tree head to point of last 'git fetch' update. >> >> After that proceed as described (add new file, put translation in it, etc). >> >> > > Ok, thank you. For restoring the completed works i just overwrite the > files, right? > Yeah, just paste it into new created file.

1 0

Re: winedbg italian translation
by Nikolay Sivov June 28, 2009

June 28, 2009

Davide Pizzetti wrote: > Another question: when i create a new language translation file, i have > to copy the english file into a new file and translate it? > > Il giorno dom, 28/06/2009 alle 16.14 +0400, Nikolay Sivov ha scritto: > >> Davide Pizzetti wrote: >> >>> Here's the italian translation for winedbg >>> >>> >> Hi, Davide. >> >> This patch is malformed too. >> >> When you need to create new file in repo, first create it in your file >> system, then do 'git add programs/winedbg/rsrc_It.rc' . >> This will add it to your repo. Don't forget to edit rsrc.rc file too to >> add your new created resource file. >> >> Bye. >> Yes, cause only english resources are complete - that's the only reason why you should sync with it.

1 0

Re: winedbg italian translation
by Nikolay Sivov June 28, 2009

June 28, 2009

Davide Pizzetti wrote: > i think i made a little mess with the files for winedbg. how do i > restore the situation to the previous state? > Il giorno dom, 28/06/2009 alle 16.14 +0400, Nikolay Sivov ha scritto: > >> Davide Pizzetti wrote: >> >>> Here's the italian translation for winedbg >>> >>> >> Hi, Davide. >> >> This patch is malformed too. >> >> When you need to create new file in repo, first create it in your file >> system, then do 'git add programs/winedbg/rsrc_It.rc' . >> This will add it to your repo. Don't forget to edit rsrc.rc file too to >> add your new created resource file. >> >> Bye. >> Save your edited files somewhere outside tree to keep your work. After that do 'git reset --hard origin' this will reset your tree head to point of last 'git fetch' update. After that proceed as described (add new file, put translation in it, etc).

1 0

Re: winedbg italian translation
by Nikolay Sivov June 28, 2009

June 28, 2009

Davide Pizzetti wrote: > Here's the italian translation for winedbg > Hi, Davide. This patch is malformed too. When you need to create new file in repo, first create it in your file system, then do 'git add programs/winedbg/rsrc_It.rc' . This will add it to your repo. Don't forget to edit rsrc.rc file too to add your new created resource file. Bye.

1 0

Re: [5/6] WineD3D: Write the vshader footer in a separate function
by Ivan Gyurdiev June 27, 2009

June 27, 2009

> Re: [5/6] WineD3D: Write the vshader footer in a separate function I like this patch - would be great to have more of these: Lines that fit on the screen in my gnome-terminal: < 50 Average size of six large ARB shader functions, before this patch: 205 (generate pshader, vshader, handle_ins, arb_declarations, init_output_register, gen_arbfp_ffp...) A couple of other shader questions/suggestions, not related to the patch: - The "handle_instruction" code seems to be moving away from the design to handle each instruction separately into its own handler - is this really necessary? Does it make sense to create a "loop" intermediate representation in baseshader if the ARB backend needs it to better handle loops? - There are some elaborate bitfields to track which instructions are called in baseshader.c. Does it make sense to have a more formal framework, where all instructions are tracked or maybe each backend requests which instructions it is interested to track? Ivan

1 0

Re: [4/6] WineD3D: Implement function calls with NV exts
by Henri Verbeet June 27, 2009

June 27, 2009

2009/6/27 Stefan Dösinger <stefan(a)codeweavers.com>: > - || ins.handler_idx == WINED3DSIH_PHASE > - || ins.handler_idx == WINED3DSIH_RET) > + || ins.handler_idx == WINED3DSIH_PHASE) Did you test this change with GLSL?

2 2

re: Removing active maintainers
by Susan Cragin June 27, 2009

June 27, 2009

>A basic level of courtesy shouldn't be too hard. >Dogfights where two maintainers are asking to have each other thrown >out are a good sign that both of said developers need to chill. We need more women. Susan

2 1

Fixing EOL in logging messages
by Frédéric Delanoy June 27, 2009

June 27, 2009

Hi, I'm intending to fix some non-\n-terminated strings for different logging classes (MESSAGE, TRACE, ...) For each class, should I send (1) a patch for *each* affected module or (2) just a "generic" one ? Solution (1) seems a bit like overkill for me... Frédéric

2 1

Appinstall caught a (fixed) bug
by Austin English June 27, 2009

June 27, 2009

Whlie checking logs today, I noticed something interesting: All tests passed builtin-gui-result.txt:Error window didn't appear. Bug 19081 fixed. TODO_FIXED. builtin-gui-result.txt:Error window didn't appear. Bug 19081 fixed. TODO_FIXED. kmeleon-152-result.txt:k-meleon.exe didn't crash. Bug 17524 TODO_FIXED. nestopia-result.txt:nestopia.exe didn't crash. Bug 19609 TODO_FIXED. Some TODO_FIXED...investigate! From:http://austinenglish.com/logs/appinstall-2009-06-26/summary.txt The builtin-gui stuff is a red herring (I need to adjust the test). The nestopia test was a real bug (http://bugs.winehq.org/show_bug.cgi?id=19069) that I added a testcase for to make sure appinstall would catch it/it doesn't break later on. The kmeleon-152 result, however, wasn't expected...apparently something in today's git fixed it (I ran it manually as well, and it's working fine). Now I need to get busy and add more tests... -- -Austin

1 0

Re: Removing active maintainers
by Susan Cragin June 27, 2009

June 27, 2009

>> Version 9 should be entirely deleted. That refers to the early 9.0 Preferred >> release, which is not available any more. 9.0 Preferred has been replaced by >> 9.5 Preferred, which is garbage like Standard. We should not have people >> buying DNS 9 Preferred and thinking it is installable when it is not. > >Versions should not be deleted, especially not for programs sold on actual disks. A user may dig up an old copy somewhere and wonder >whether it would work. If the version is deleted, he/she will not know and/or may recreate the page with his results. > >Gert OK, but Version 9 should be re-numbered to 9.0 Preferred, with a note that version was superseded by 9.5, and new copies purchased will most likely be 9.5.

2 1

wine 1.1.23 configure message Mac OSX 10.5.7
by Maurits Lamers June 27, 2009

June 27, 2009

Hi, while running configure of wine 1.1.23 on Mac OSX Leopard 10.5.7 the message below appeared with a request to mail it. Running XCode 3.1.2, i686-apple-darwin9-gcc-4.0.1. Please feel free to contact me if you need any extra information. greets Maurits ==== checking mach-o/dyld_images.h usability... no checking mach-o/dyld_images.h presence... yes configure: WARNING: mach-o/dyld_images.h: present but cannot be compiled configure: WARNING: mach-o/dyld_images.h: check for missing prerequisite headers? configure: WARNING: mach-o/dyld_images.h: see the Autoconf documentation configure: WARNING: mach-o/dyld_images.h: section "Present But Cannot Be Compiled" configure: WARNING: mach-o/dyld_images.h: proceeding with the preprocessor's result configure: WARNING: mach-o/dyld_images.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to wine-devel(a)winehq.org ## configure: WARNING: ## ------------------------------------ ##

3 3

Regression on OS X, may not be able to load dll
by Gellule Xg June 26, 2009

June 26, 2009

Hi, (wine, almost latest git, on OS X) Trying to test the latest changes on the loader memory management with Ryzom (which I had some OpenGL related out of memory issues), I stumbled on the following: "wine client_ryzom_rd.exe" crashes with: DBG 9 dynloadlib.cpp 211 NLMISC::CLibrary::loadLibrary client_ryzom_rd.exe : Loading dynamic library 'nel_drv_opengl_win_r.dll' dyld: lazy symbol binding failed: lazy pointer not found at address 0x303d17af in image /opt/local/libexec/wine/wine dyld: lazy pointer not found at address 0x303d17af in image /opt/local/libexec/wine/wine WRN 9 dynloadlib.cpp 45 NLMISC::nlLoadLibrary client_ryzom_rd.exe : Load library 'nel_drv_opengl_win_r.dll' failed: ???????? WRN 9 dynloadlib.cpp 222 NLMISC::CLibrary::loadLibrary client_ryzom_rd.exe : Loading library nel_drv_opengl_win_r.dll failed: Verify DLL existence The application cannot load the native library 'nel_drv_opengl_win_r.dll'. winecfg also exhibits these two lines (at first launch, creating the .wine directory), but without crashing: dyld: lazy symbol binding failed: lazy pointer not found at address 0x303d17af in image /opt/local/libexec/wine/wine dyld: lazy pointer not found at address 0x303d17af in image /opt/local/libexec/wine/wine I checked out a few revisions and narrowed down the issue to be between: "kernel32: Add call frame annotations in x86 assembly code." (which works) and "loader: Reserve some more memory to cover the native ole32 addresses." (which does not). I'm ready to do some more testing if somebody could guide me. I could already start bisecting through: loader: Reserve some more memory to cover the native... ntdll: Release some address space after the process... ntdll: Don't try to decommit a heap past its initial... ntdll: Compute the free lists address at run-time inste... Best regards, -Gellule

1 0

Usage of wine-tests-results mailing list
by Frédéric Delanoy June 26, 2009

June 26, 2009

Hi, looking at the different mailing lists of wine on http://www.winehq.org/mailman/listinfo, I found that wine-tests-results seems only filled with garbage (actually "[ERROR] winetest error report"). Has that list any use these days? Frédéric

1 0

Regression on OS X, may not be able to load native dll
by Gellule Xg June 26, 2009

June 26, 2009

Hi, (wine, almost latest git, on OS X) Trying to test the latest changes on the loader memory management with Ryzom (which I had some OpenGL related out of memory issues), I stumbled on the following: "wine client_ryzom_rd.exe" crashes with the following. DBG 9 dynloadlib.cpp 211 NLMISC::CLibrary::loadLibrary client_ryzom_rd.exe : Loading dynamic library 'nel_drv_opengl_win_r.dll' dyld: lazy symbol binding failed: lazy pointer not found at address 0x303d17af in image /opt/local/libexec/wine/wine dyld: lazy pointer not found at address 0x303d17af in image /opt/local/libexec/wine/wine WRN 9 dynloadlib.cpp 45 NLMISC::nlLoadLibrary client_ryzom_rd.exe : Load library 'nel_drv_opengl_win_r.dll' failed: ???????? WRN 9 dynloadlib.cpp 222 NLMISC::CLibrary::loadLibrary client_ryzom_rd.exe : Loading library nel_drv_opengl_win_r.dll failed: Verify DLL existence The application cannot load the native library 'nel_drv_opengl_win_r.dll'. winecfg also exhibit these two lines, but without crashing: dyld: lazy symbol binding failed: lazy pointer not found at address 0x303d17af in image /opt/local/libexec/wine/wine dyld: lazy pointer not found at address 0x303d17af in image /opt/local/libexec/wine/wine I checked out a few revisions and narrowed down the issue to be between: "kernel32: Add call frame annotations in x86 assembly code." (which works) and "loader: Reserve some more memory to cover the native ole32 addresses." (which does not). I'm ready to do some more testing if somebody could guide me. I could already start bisecting through: loader: Reserve some more memory to cover the native... ntdll: Release some address space after the process... ntdll: Don't try to decommit a heap past its initial... ntdll: Compute the free lists address at run-time inste... Best regards, -Gellule

1 0

Removing active maintainers
by Vitaliy Margolen June 26, 2009

June 26, 2009

Why did someone removed active maintainers from most active applications? Do you guys even care who active who not? I was the only one doing _anything_ on Steam AppDB entry. And I was removed by Ken Sharp because he didn't like 9 "oldish" posts??? WTH? This got to stop! If someone doesn't like old entries - well that's just too bad. Don't go to those apps, or fix AppDB to split comments into several pages. I'm appreciate what Ken was doing but not anymore. Please remove him from the admin role an AppDB. This is way over the head of what he's been doing. Vitaliy.

18 41

Strange issue with recv in Launchpad Enhanced
by Erich Hoover June 26, 2009

June 26, 2009

I'm trying to track down an issue with Launchpad Enhanced were it fails to download its updates (Bug #17443). It appears that the issue stems from recv being called with a buffer from a different process, so as a result the call fails. I put together a hack that gets around the problem ( http://bugs.winehq.org/show_bug.cgi?id=17443#c2) but I'm having difficulty figuring out exactly why this is happening in the first place. Does anyone know if this is a known difference between Windows and Linux or if there is something else strange going on? Erich Hoover ehoover(a)mines.edu

2 5

Re: Removing active maintainers
by Susan Cragin June 26, 2009

June 26, 2009

3 2

Re: clock: Reset default codepage in utf8 rc file
by Paul Chitescu June 26, 2009

June 26, 2009

On Wednesday 24 June 2009 02:28:12 Frédéric Delanoy wrote: > clock: Reset default codepage in utf8 rc file > > In the Romanian resource file for the "clock" program, which is in utf-8 > format, the code page wasn't reset to the default code page at the end of > the file. Now that's weird... I just checked the patch I've sent to wine-patches and it had #pragma code_page(default) at the end. On the other hand the git commit didn't include it. What gives?

4 4

Re: user32/tests: Add more intensive tests for SetCursor.
by Daniel Santos June 26, 2009

June 26, 2009

lol! I guess it's time for me to remove myself from the mailing lists I don't read anymore, I'm starting to miss replies! Anyway, I'm off for the weekend, but will rebase and re-send (with attachment) Monday or so. Thanks for the response Austin! Daniel --- On Tue, 6/9/09, Austin English <austinenglish(a)gmail.com> wrote: > From: Austin English <austinenglish(a)gmail.com> > Subject: Re: user32/tests: Add more intensive tests for SetCursor. > To: "Daniel Santos" <javatroubadour(a)yahoo.com> > Cc: "Wine Devel" <wine-devel(a)winehq.org> > Date: Tuesday, June 9, 2009, 5:15 PM > On Tue, Jun 9, 2009 at 5:13 PM, > Daniel Santos<javatroubadour(a)yahoo.com> > wrote: > > > > Hello! This is a prelude to other cursor patches to > follow (both Griswold's & my work). As requested, I > have replaced the __FILE_SPOT with the standard > ok_(file,line) mechanism (looks much better to me). I've > removed the windows version checking from tests and last > error checking on success, although I have reservations > about it (mostly the later). > > Forgot patch. > > > -- > -Austin >

1 0

As of Thursday's git, DNS runs for a bit longer.
by Susan Cragin June 26, 2009

June 26, 2009

I have been timing Dragon NaturallySpeaking to see how fast it crashes. I start when I click on the program, and use it pretty steadily until it crashes. As of yesterday's git, it runs for about 15 minutes and 30 seconds. That's an improvement of two minutes over previous versions. :) Susan

1 0

Alpha Roadblocks
by Joel Holdsworth June 26, 2009

June 26, 2009

Hi All, Some of you may have read some of my recent mails about my work to refresh the wine icons with Tango versions, as demonstrated in this screenshot: http://www.airwebreathe.org.uk/alpha-tango-icons.png Achieving this task isn't a simple icon replacement job, because of the inability of wine to handle the alpha channel correctly in two key areas: HICONS, and IImageLists. I've patched some of the problems, but others are roadblocked by shortcomings in x11.drv's BitBlt/StretchBlt which (usually) strip the alpha channel. This leaves me a bit stuck: AJ rightly won't accept any hacks or workabouts, which leaves me with the choice to give up (for the time being), or try and fix x11.drv myself. I'm pretty sure that fixing the blts would be a major job, but I thought I'd write and ask for some comments. Is it so hard as I think? Does anyone have any ideas what would be required? Thanks Joel

3 2

Re: [5/10] d3dx9: Implement D3DXLoadSurfaceFromSurface
by Tony Wasserka June 26, 2009

June 26, 2009

> Watch out, some surfaces aren't lockable. I don't know the d3dx9 api too well, > but are you sure that you have a lockable surface here? > In some situations IDirect3DDevice9::UpdateSurface or > IDirect3DDevice9::StretchRect may be a faster way to achieve what this code > does(without colorkeying though). Hi, The function just fails with D3DXERR_INVALIDDATA if the surface is not lockable, just as D3DXLoadSurfaceFromMemory will when it's implemented. Of course UpdateSurface could be used, but as you said it doesn't support color keying (nor palettes I guess) or filtering and it only works in very specific cases (i.e. same dimensions, no color keying, no filtering), applications are more likely to do things like that on their own probably. D3DX has been created for the general case mostly, so optimizations like this would just make the code more complicated ;) Tony

1 0

oleaut32:usrmarshal tests on Win95
by Paul Vriens June 26, 2009

June 26, 2009

Hi, I'm looking into the failures for the usrmarshal tests on Win95. The attached patch shows the differences between NT+ and Win95. I'm not able to pinpoint the correct way to fix these failures yet. Some other results: - older Win98 boxes behave the same as Win95 - newer Win98 boxes and WinME behave partly the same (need those '+4' every now and then) but crash later on Any ideas how to properly fix this? -- Cheers, Paul. diff --git a/dlls/oleaut32/tests/usrmarshal.c b/dlls/oleaut32/tests/usrmarshal.c index 38827b1..ce1a88f 100644 --- a/dlls/oleaut32/tests/usrmarshal.c +++ b/dlls/oleaut32/tests/usrmarshal.c @@ -572,6 +572,7 @@ static void test_marshal_VARIANT(void) LPSAFEARRAY lpsa; DECIMAL dec, dec2; HeapUnknown *heap_unknown; + int win95_correction = 4; stubMsg.RpcMsg = &rpcMsg; @@ -600,11 +601,11 @@ static void test_marshal_VARIANT(void) rpcMsg.BufferLength = stubMsg.BufferLength = VARIANT_UserSize(&umcb.Flags, 0, &v); ok(stubMsg.BufferLength == 21, "size %d\n", stubMsg.BufferLength); - buffer = rpcMsg.Buffer = stubMsg.Buffer = stubMsg.BufferStart = HeapAlloc(GetProcessHeap(), 0, stubMsg.BufferLength); - stubMsg.BufferEnd = stubMsg.Buffer + stubMsg.BufferLength; + buffer = rpcMsg.Buffer = stubMsg.Buffer = stubMsg.BufferStart = HeapAlloc(GetProcessHeap(), 0, stubMsg.BufferLength + win95_correction); + stubMsg.BufferEnd = stubMsg.Buffer + stubMsg.BufferLength + win95_correction; next = VARIANT_UserMarshal(&umcb.Flags, buffer, &v); - ok(next == buffer + stubMsg.BufferLength, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); - wirev = (DWORD*)buffer; + ok(next == buffer + stubMsg.BufferLength + win95_correction, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); + wirev = (DWORD*)(buffer + win95_correction); check_variant_header(wirev, &v, stubMsg.BufferLength); wirev += 5; @@ -614,7 +615,7 @@ static void test_marshal_VARIANT(void) VariantInit(&v2); stubMsg.Buffer = buffer; next = VARIANT_UserUnmarshal(&umcb.Flags, buffer, &v2); - ok(next == buffer + stubMsg.BufferLength, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); + ok(next == buffer + stubMsg.BufferLength + win95_correction, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); ok(V_VT(&v) == V_VT(&v2), "got vt %d expect %d\n", V_VT(&v), V_VT(&v2)); ok(V_I1(&v) == V_I1(&v2), "got i1 %x expect %x\n", V_I1(&v), V_I1(&v2)); @@ -630,11 +631,11 @@ static void test_marshal_VARIANT(void) rpcMsg.BufferLength = stubMsg.BufferLength = VARIANT_UserSize(&umcb.Flags, 0, &v); ok(stubMsg.BufferLength == 22, "size %d\n", stubMsg.BufferLength); - buffer = rpcMsg.Buffer = stubMsg.Buffer = stubMsg.BufferStart = HeapAlloc(GetProcessHeap(), 0, stubMsg.BufferLength); - stubMsg.BufferEnd = stubMsg.Buffer + stubMsg.BufferLength; + buffer = rpcMsg.Buffer = stubMsg.Buffer = stubMsg.BufferStart = HeapAlloc(GetProcessHeap(), 0, stubMsg.BufferLength + win95_correction); + stubMsg.BufferEnd = stubMsg.Buffer + stubMsg.BufferLength + win95_correction; next = VARIANT_UserMarshal(&umcb.Flags, buffer, &v); - ok(next == buffer + stubMsg.BufferLength, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); - wirev = (DWORD*)buffer; + ok(next == buffer + stubMsg.BufferLength + win95_correction, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); + wirev = (DWORD*)(buffer + win95_correction); check_variant_header(wirev, &v, stubMsg.BufferLength); wirev += 5; @@ -644,7 +645,7 @@ static void test_marshal_VARIANT(void) VariantInit(&v2); stubMsg.Buffer = buffer; next = VARIANT_UserUnmarshal(&umcb.Flags, buffer, &v2); - ok(next == buffer + stubMsg.BufferLength, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); + ok(next == buffer + stubMsg.BufferLength + win95_correction, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); ok(V_VT(&v) == V_VT(&v2), "got vt %d expect %d\n", V_VT(&v), V_VT(&v2)); ok(V_I2(&v) == V_I2(&v2), "got i2 %x expect %x\n", V_I2(&v), V_I2(&v2)); @@ -661,8 +662,8 @@ static void test_marshal_VARIANT(void) rpcMsg.BufferLength = stubMsg.BufferLength = VARIANT_UserSize(&umcb.Flags, 0, &v); ok(stubMsg.BufferLength == 26, "size %d\n", stubMsg.BufferLength); - buffer = rpcMsg.Buffer = stubMsg.Buffer = stubMsg.BufferStart = HeapAlloc(GetProcessHeap(), 0, stubMsg.BufferLength); - stubMsg.BufferEnd = stubMsg.Buffer + stubMsg.BufferLength; + buffer = rpcMsg.Buffer = stubMsg.Buffer = stubMsg.BufferStart = HeapAlloc(GetProcessHeap(), 0, stubMsg.BufferLength + win95_correction); + stubMsg.BufferEnd = stubMsg.Buffer + stubMsg.BufferLength + win95_correction; next = VARIANT_UserMarshal(&umcb.Flags, buffer, &v); ok(next == buffer + stubMsg.BufferLength, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); wirev = (DWORD*)buffer; @@ -697,11 +698,11 @@ static void test_marshal_VARIANT(void) rpcMsg.BufferLength = stubMsg.BufferLength = VARIANT_UserSize(&umcb.Flags, 0, &v); ok(stubMsg.BufferLength == 24, "size %d\n", stubMsg.BufferLength); - buffer = rpcMsg.Buffer = stubMsg.Buffer = stubMsg.BufferStart = HeapAlloc(GetProcessHeap(), 0, stubMsg.BufferLength); - stubMsg.BufferEnd = stubMsg.Buffer + stubMsg.BufferLength; + buffer = rpcMsg.Buffer = stubMsg.Buffer = stubMsg.BufferStart = HeapAlloc(GetProcessHeap(), 0, stubMsg.BufferLength + win95_correction); + stubMsg.BufferEnd = stubMsg.Buffer + stubMsg.BufferLength + win95_correction; next = VARIANT_UserMarshal(&umcb.Flags, buffer, &v); - ok(next == buffer + stubMsg.BufferLength, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); - wirev = (DWORD*)buffer; + ok(next == buffer + stubMsg.BufferLength + win95_correction, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); + wirev = (DWORD*)(buffer + win95_correction); check_variant_header(wirev, &v, stubMsg.BufferLength); wirev += 5; @@ -712,7 +713,7 @@ static void test_marshal_VARIANT(void) VariantInit(&v2); stubMsg.Buffer = buffer; next = VARIANT_UserUnmarshal(&umcb.Flags, buffer, &v2); - ok(next == buffer + stubMsg.BufferLength, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); + ok(next == buffer + stubMsg.BufferLength + win95_correction, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); ok(V_VT(&v) == V_VT(&v2), "got vt %d expect %d\n", V_VT(&v), V_VT(&v2)); ok(V_I4(&v) == V_I4(&v2), "got i4 %x expect %x\n", V_I4(&v), V_I4(&v2)); @@ -729,11 +730,11 @@ static void test_marshal_VARIANT(void) rpcMsg.BufferLength = stubMsg.BufferLength = VARIANT_UserSize(&umcb.Flags, 0, &v); ok(stubMsg.BufferLength == 24, "size %d\n", stubMsg.BufferLength); - buffer = rpcMsg.Buffer = stubMsg.Buffer = stubMsg.BufferStart = HeapAlloc(GetProcessHeap(), 0, stubMsg.BufferLength); - stubMsg.BufferEnd = stubMsg.Buffer + stubMsg.BufferLength; + buffer = rpcMsg.Buffer = stubMsg.Buffer = stubMsg.BufferStart = HeapAlloc(GetProcessHeap(), 0, stubMsg.BufferLength + win95_correction); + stubMsg.BufferEnd = stubMsg.Buffer + stubMsg.BufferLength + win95_correction; next = VARIANT_UserMarshal(&umcb.Flags, buffer, &v); - ok(next == buffer + stubMsg.BufferLength, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); - wirev = (DWORD*)buffer; + ok(next == buffer + stubMsg.BufferLength + win95_correction, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); + wirev = (DWORD*)(buffer + win95_correction); check_variant_header(wirev, &v, stubMsg.BufferLength); wirev += 5; @@ -743,7 +744,7 @@ static void test_marshal_VARIANT(void) VariantInit(&v2); stubMsg.Buffer = buffer; next = VARIANT_UserUnmarshal(&umcb.Flags, buffer, &v2); - ok(next == buffer + stubMsg.BufferLength, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); + ok(next == buffer + stubMsg.BufferLength + win95_correction, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); ok(V_VT(&v) == V_VT(&v2), "got vt %d expect %d\n", V_VT(&v), V_VT(&v2)); ok(V_UI4(&v) == V_UI4(&v2), "got ui4 %x expect %x\n", V_UI4(&v), V_UI4(&v2)); @@ -761,8 +762,8 @@ static void test_marshal_VARIANT(void) rpcMsg.BufferLength = stubMsg.BufferLength = VARIANT_UserSize(&umcb.Flags, 0, &v); ok(stubMsg.BufferLength == 28, "size %d\n", stubMsg.BufferLength); - buffer = rpcMsg.Buffer = stubMsg.Buffer = stubMsg.BufferStart = HeapAlloc(GetProcessHeap(), 0, stubMsg.BufferLength); - stubMsg.BufferEnd = stubMsg.Buffer + stubMsg.BufferLength; + buffer = rpcMsg.Buffer = stubMsg.Buffer = stubMsg.BufferStart = HeapAlloc(GetProcessHeap(), 0, stubMsg.BufferLength + win95_correction); + stubMsg.BufferEnd = stubMsg.Buffer + stubMsg.BufferLength + win95_correction; next = VARIANT_UserMarshal(&umcb.Flags, buffer, &v); ok(next == buffer + stubMsg.BufferLength, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); wirev = (DWORD*)buffer; @@ -794,11 +795,11 @@ static void test_marshal_VARIANT(void) rpcMsg.BufferLength = stubMsg.BufferLength = VARIANT_UserSize(&umcb.Flags, 0, &v); ok(stubMsg.BufferLength == 24, "size %d\n", stubMsg.BufferLength); - buffer = rpcMsg.Buffer = stubMsg.Buffer = stubMsg.BufferStart = HeapAlloc(GetProcessHeap(), 0, stubMsg.BufferLength); - stubMsg.BufferEnd = stubMsg.Buffer + stubMsg.BufferLength; + buffer = rpcMsg.Buffer = stubMsg.Buffer = stubMsg.BufferStart = HeapAlloc(GetProcessHeap(), 0, stubMsg.BufferLength + win95_correction); + stubMsg.BufferEnd = stubMsg.Buffer + stubMsg.BufferLength + win95_correction; next = VARIANT_UserMarshal(&umcb.Flags, buffer, &v); - ok(next == buffer + stubMsg.BufferLength, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); - wirev = (DWORD*)buffer; + ok(next == buffer + stubMsg.BufferLength + win95_correction, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); + wirev = (DWORD*)(buffer + win95_correction); check_variant_header(wirev, &v, stubMsg.BufferLength); wirev += 5; @@ -808,7 +809,7 @@ static void test_marshal_VARIANT(void) VariantInit(&v2); stubMsg.Buffer = buffer; next = VARIANT_UserUnmarshal(&umcb.Flags, buffer, &v2); - ok(next == buffer + stubMsg.BufferLength, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); + ok(next == buffer + stubMsg.BufferLength + win95_correction, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); ok(V_VT(&v) == V_VT(&v2), "got vt %d expect %d\n", V_VT(&v), V_VT(&v2)); ok(V_R4(&v) == V_R4(&v2), "got r4 %f expect %f\n", V_R4(&v), V_R4(&v2)); @@ -890,11 +891,11 @@ static void test_marshal_VARIANT(void) rpcMsg.BufferLength = stubMsg.BufferLength = VARIANT_UserSize(&umcb.Flags, 0, &v); ok(stubMsg.BufferLength == 22, "size %d\n", stubMsg.BufferLength); - buffer = rpcMsg.Buffer = stubMsg.Buffer = stubMsg.BufferStart = HeapAlloc(GetProcessHeap(), 0, stubMsg.BufferLength); - stubMsg.BufferEnd = stubMsg.Buffer + stubMsg.BufferLength; + buffer = rpcMsg.Buffer = stubMsg.Buffer = stubMsg.BufferStart = HeapAlloc(GetProcessHeap(), 0, stubMsg.BufferLength + win95_correction); + stubMsg.BufferEnd = stubMsg.Buffer + stubMsg.BufferLength + win95_correction; next = VARIANT_UserMarshal(&umcb.Flags, buffer, &v); - ok(next == buffer + stubMsg.BufferLength, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); - wirev = (DWORD*)buffer; + ok(next == buffer + stubMsg.BufferLength + win95_correction, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); + wirev = (DWORD*)(buffer + win95_correction); check_variant_header(wirev, &v, stubMsg.BufferLength); wirev += 5; @@ -904,7 +905,7 @@ static void test_marshal_VARIANT(void) VariantInit(&v2); stubMsg.Buffer = buffer; next = VARIANT_UserUnmarshal(&umcb.Flags, buffer, &v2); - ok(next == buffer + stubMsg.BufferLength, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); + ok(next == buffer + stubMsg.BufferLength + win95_correction, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); ok(V_VT(&v) == V_VT(&v2), "got vt %d expect %d\n", V_VT(&v), V_VT(&v2)); ok(V_BOOL(&v) == V_BOOL(&v2), "got bool %x expect %x\n", V_BOOL(&v), V_BOOL(&v2)); @@ -996,11 +997,11 @@ static void test_marshal_VARIANT(void) rpcMsg.BufferLength = stubMsg.BufferLength = VARIANT_UserSize(&umcb.Flags, 0, &v); ok(stubMsg.BufferLength == 20, "size %d\n", stubMsg.BufferLength); - buffer = rpcMsg.Buffer = stubMsg.Buffer = stubMsg.BufferStart = HeapAlloc(GetProcessHeap(), 0, stubMsg.BufferLength); - stubMsg.BufferEnd = stubMsg.Buffer + stubMsg.BufferLength; + buffer = rpcMsg.Buffer = stubMsg.Buffer = stubMsg.BufferStart = HeapAlloc(GetProcessHeap(), 0, stubMsg.BufferLength + win95_correction); + stubMsg.BufferEnd = stubMsg.Buffer + stubMsg.BufferLength + win95_correction; next = VARIANT_UserMarshal(&umcb.Flags, buffer, &v); - ok(next == buffer + stubMsg.BufferLength, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); - wirev = (DWORD*)buffer; + ok(next == buffer + stubMsg.BufferLength + win95_correction, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); + wirev = (DWORD*)(buffer + win95_correction); check_variant_header(wirev, &v, stubMsg.BufferLength); if (VARIANT_UNMARSHAL_WORKS) @@ -1008,7 +1009,7 @@ static void test_marshal_VARIANT(void) VariantInit(&v2); stubMsg.Buffer = buffer; next = VARIANT_UserUnmarshal(&umcb.Flags, buffer, &v2); - ok(next == buffer + stubMsg.BufferLength, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); + ok(next == buffer + stubMsg.BufferLength + win95_correction, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); ok(V_VT(&v) == V_VT(&v2), "got vt %d expect %d\n", V_VT(&v), V_VT(&v2)); VARIANT_UserFree(&umcb.Flags, &v2); @@ -1022,11 +1023,11 @@ static void test_marshal_VARIANT(void) rpcMsg.BufferLength = stubMsg.BufferLength = VARIANT_UserSize(&umcb.Flags, 0, &v); ok(stubMsg.BufferLength == 20, "size %d\n", stubMsg.BufferLength); - buffer = rpcMsg.Buffer = stubMsg.Buffer = stubMsg.BufferStart = HeapAlloc(GetProcessHeap(), 0, stubMsg.BufferLength); - stubMsg.BufferEnd = stubMsg.Buffer + stubMsg.BufferLength; + buffer = rpcMsg.Buffer = stubMsg.Buffer = stubMsg.BufferStart = HeapAlloc(GetProcessHeap(), 0, stubMsg.BufferLength + win95_correction); + stubMsg.BufferEnd = stubMsg.Buffer + stubMsg.BufferLength + win95_correction; next = VARIANT_UserMarshal(&umcb.Flags, buffer, &v); - ok(next == buffer + stubMsg.BufferLength, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); - wirev = (DWORD*)buffer; + ok(next == buffer + stubMsg.BufferLength + win95_correction, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); + wirev = (DWORD*)(buffer + win95_correction); check_variant_header(wirev, &v, stubMsg.BufferLength); if (VARIANT_UNMARSHAL_WORKS) @@ -1034,7 +1035,7 @@ static void test_marshal_VARIANT(void) VariantInit(&v2); stubMsg.Buffer = buffer; next = VARIANT_UserUnmarshal(&umcb.Flags, buffer, &v2); - ok(next == buffer + stubMsg.BufferLength, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); + ok(next == buffer + stubMsg.BufferLength + win95_correction, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); ok(V_VT(&v) == V_VT(&v2), "got vt %d expect %d\n", V_VT(&v), V_VT(&v2)); VARIANT_UserFree(&umcb.Flags, &v2); @@ -1123,11 +1124,11 @@ static void test_marshal_VARIANT(void) rpcMsg.BufferLength = stubMsg.BufferLength = VARIANT_UserSize(&umcb.Flags, 0, &v); ok(stubMsg.BufferLength == 152, "size %d\n", stubMsg.BufferLength); - buffer = rpcMsg.Buffer = stubMsg.Buffer = stubMsg.BufferStart = HeapAlloc(GetProcessHeap(), 0, stubMsg.BufferLength); - stubMsg.BufferEnd = stubMsg.Buffer + stubMsg.BufferLength; + buffer = rpcMsg.Buffer = stubMsg.Buffer = stubMsg.BufferStart = HeapAlloc(GetProcessHeap(), 0, stubMsg.BufferLength + win95_correction); + stubMsg.BufferEnd = stubMsg.Buffer + stubMsg.BufferLength + win95_correction; next = VARIANT_UserMarshal(&umcb.Flags, buffer, &v); - ok(next == buffer + stubMsg.BufferLength, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); - wirev = (DWORD*)buffer; + ok(next == buffer + stubMsg.BufferLength + win95_correction, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); + wirev = (DWORD*)(buffer + win95_correction); check_variant_header(wirev, &v, stubMsg.BufferLength); wirev += 5; @@ -1141,7 +1142,7 @@ static void test_marshal_VARIANT(void) VariantInit(&v2); stubMsg.Buffer = buffer; next = VARIANT_UserUnmarshal(&umcb.Flags, buffer, &v2); - ok(next == buffer + stubMsg.BufferLength, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); + ok(next == buffer + stubMsg.BufferLength + win95_correction, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); ok(V_VT(&v) == V_VT(&v2), "got vt %d expect %d\n", V_VT(&v), V_VT(&v2)); ok(SafeArrayGetDim(V_ARRAY(&v)) == SafeArrayGetDim(V_ARRAY(&v)), "array dims differ\n"); SafeArrayGetLBound(V_ARRAY(&v), 1, &bound); @@ -1164,11 +1165,11 @@ static void test_marshal_VARIANT(void) rpcMsg.BufferLength = stubMsg.BufferLength = VARIANT_UserSize(&umcb.Flags, 0, &v); ok(stubMsg.BufferLength == 152, "size %d\n", stubMsg.BufferLength); - buffer = rpcMsg.Buffer = stubMsg.Buffer = stubMsg.BufferStart = HeapAlloc(GetProcessHeap(), 0, stubMsg.BufferLength); - stubMsg.BufferEnd = stubMsg.Buffer + stubMsg.BufferLength; + buffer = rpcMsg.Buffer = stubMsg.Buffer = stubMsg.BufferStart = HeapAlloc(GetProcessHeap(), 0, stubMsg.BufferLength + win95_correction); + stubMsg.BufferEnd = stubMsg.Buffer + stubMsg.BufferLength + win95_correction; next = VARIANT_UserMarshal(&umcb.Flags, buffer, &v); - ok(next == buffer + stubMsg.BufferLength, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); - wirev = (DWORD*)buffer; + ok(next == buffer + stubMsg.BufferLength + win95_correction, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); + wirev = (DWORD*)(buffer + win95_correction); check_variant_header(wirev, &v, stubMsg.BufferLength); wirev += 5; @@ -1184,7 +1185,7 @@ static void test_marshal_VARIANT(void) VariantInit(&v2); stubMsg.Buffer = buffer; next = VARIANT_UserUnmarshal(&umcb.Flags, buffer, &v2); - ok(next == buffer + stubMsg.BufferLength, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); + ok(next == buffer + stubMsg.BufferLength + win95_correction, "got %p expect %p\n", next, buffer + stubMsg.BufferLength); ok(V_VT(&v) == V_VT(&v2), "got vt %d expect %d\n", V_VT(&v), V_VT(&v2)); ok(SafeArrayGetDim(*V_ARRAYREF(&v)) == SafeArrayGetDim(*V_ARRAYREF(&v)), "array dims differ\n"); SafeArrayGetLBound(*V_ARRAYREF(&v), 1, &bound); @@ -1257,11 +1258,11 @@ static void test_marshal_VARIANT(void) rpcMsg.BufferLength = stubMsg.BufferLength = VARIANT_UserSize(&umcb.Flags, 0, &v); ok(stubMsg.BufferLength > 32, "size %d\n", stubMsg.BufferLength); - buffer = rpcMsg.Buffer = stubMsg.Buffer = stubMsg.BufferStart = HeapAlloc(GetProcessHeap(), 0, stubMsg.BufferLength); - stubMsg.BufferEnd = stubMsg.Buffer + stubMsg.BufferLength; + buffer = rpcMsg.Buffer = stubMsg.Buffer = stubMsg.BufferStart = HeapAlloc(GetProcessHeap(), 0, stubMsg.BufferLength + win95_correction); + stubMsg.BufferEnd = stubMsg.Buffer + stubMsg.BufferLength + win95_correction; memset(buffer, 0xcc, stubMsg.BufferLength); next = VARIANT_UserMarshal(&umcb.Flags, buffer, &v); - wirev = (DWORD*)buffer; + wirev = (DWORD*)(buffer + win95_correction); check_variant_header(wirev, &v, next - buffer); wirev += 5; @@ -1270,10 +1271,10 @@ static void test_marshal_VARIANT(void) *wirev == (DWORD_PTR)V_UNKNOWN(&v) + 1 /* NT */, "wv[5] %08x\n", *wirev); wirev++; todo_wine - ok(*wirev == next - buffer - 0x20, "wv[6] %08x\n", *wirev); + ok(*wirev == next - buffer - win95_correction - 0x20, "wv[6] %08x\n", *wirev); wirev++; todo_wine - ok(*wirev == next - buffer - 0x20, "wv[7] %08x\n", *wirev); + ok(*wirev == next - buffer - win95_correction - 0x20, "wv[7] %08x\n", *wirev); wirev++; todo_wine ok(*wirev == 0x574f454d, "wv[8] %08x\n", *wirev);

1 0

Re: [PATCH 1/5] wined3d: Make sure queries have an active GL context.
by Stefan Dösinger June 26, 2009

June 26, 2009

Am Friday 26 June 2009 10:07:08 schrieb Henri Verbeet: > + ActivateContext(This->wineD3DDevice, > This->wineD3DDevice->lastActiveRenderTarget, CTXUSAGE_RESOURCELOAD); + > if (((WineQueryOcclusionData *)This->extendedData)->ctx != > This->wineD3DDevice->activeContext || > This->wineD3DDevice->activeContext->tid != GetCurrentThreadId()) Wouldn't it be better to activate a context after the thread check? Ie, don't activate a context when we know that we can't make use of the GL query anyway?

2 2

Re: Potential patch for an oddity in dlls/d3d9/device.c
by Henri Verbeet June 26, 2009

June 26, 2009

2009/6/25 Gerald Pfeifer <gerald(a)pfeifer.com>: > So, I wonder whether something like the patch below is the right fix, or > whether there is a deeper problem? > That fix is correct.

1 0