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

Re: Removing active maintainers
by Vitaliy Margolen June 26, 2009

June 26, 2009

mellery wrote: > He has removed useful comments on apps I maintain too. I don't want to > complain on the dev-list but if you know who i should email about it, > I'd send an email. This is the only place that you can/should discuss this. Vitaliy

1 0

Re: [5/10] d3dx9: Implement D3DXLoadSurfaceFromSurface
by Stefan Dösinger June 25, 2009

June 25, 2009

Am Thursday 25 June 2009 20:26:01 schrieb Tony Wasserka: 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).

1 0

Re: drmclien: add stub dll
by Stefan Leichter June 25, 2009

June 25, 2009

Am Thursday 25 June 2009 00:47:59 schrieb Austin English: > Makes IE6 installer a little happier > 0002-t2embed-add-stub-dll.txt > From 6b2a780718210b35cff17f519559a2c8faa80a07 Mon Sep 17 00:00:00 2001 > From: Austin English <austinenglish(a)gmail.com> > Date: Mon, 4 May 2009 22:52:37 -0500 > Subject: [PATCH] t2embed: add stub dll > > configure.ac | 1 + > dlls/t2embed/Makefile.in | 13 +++++++++++++ > dlls/t2embed/main.c | 43 +++++++++++++++++++++++++++++++++++++++++++ > dlls/t2embed/t2embed.spec | 25 +++++++++++++++++++++++++ > 4 files changed, 82 insertions(+), 0 deletions(-) > create mode 100644 dlls/t2embed/Makefile.in > create mode 100644 dlls/t2embed/main.c > create mode 100644 dlls/t2embed/t2embed.spec Did you pick the wrong patch ? This dll already exists !

2 1

Re: wine-devel Digest, Vol 47, Issue 86
by Tim Schwartz June 25, 2009

June 25, 2009

> And Ben Klein is not the VOICE of WineHQ! > > Tom It doesn't matter who says something if what they are saying is correct. You sound like the troll to me.

2 1

ActiveX support in IE7
by arcoun June 25, 2009

June 25, 2009

Hello, It is my understanding that IE7 installed in Wine (for exemple, by following instructions at http://www.wine-reviews.net/wine-reviews/applications/ie-7-on-linux-with-wi…) has no support for ActiveX. Does anyone know what are the missing parts (in Wine or by adding more native DLLs) to make it work ? Which native DLL is responsible for all the ActiveX stuff ? If we've got a clear understanding of what is missing and if a Wine dev is interested, I can sponsor it through a bounty. Regards, -- arcoun

5 6

Intermittent crashes in the ole32:clipboard tests
by Paul Vriens June 25, 2009

June 25, 2009

Hi Huw, I'm having (and more systems according to test.winehq.org) intermittent crashes in these mentioned tests. It is happening in the while() loop in test_enum_fmtetc(), at least for W2K and XP. I'm able to reproduce on W2K (once every 10 runs or so) but I can't put my finger on it. Vista and higher crash intermittently as well but at another place (test_getdatahere() ?) Any ideas? -- Cheers, Paul.

1 1

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

June 25, 2009

Davide Pizzetti wrote: > Here's the italian translation for winedbg > This is wrong of course - you broke English resource file. You need to create a new file here with same naming convention (rsrc_It.rc) and 'git add' it to your tree before commit.

2 1

Re: [1/8] windowscodecs: add stub implementation of IWICImagingFactory
by Alexandre Julliard June 25, 2009

June 25, 2009

"Vincent Povirk" <vincent(a)codeweavers.com> writes: > +HRESULT register_classes(void) > +{ > + int i; > + HKEY clsid_key, ips32_key; > + LONG res=0; > + HRESULT hr=S_OK; > + static const WCHAR inprocserver32W[] = {'I','n','P','r','o','c','S','e','r','v','e','r','3','2',0}; > + > + for (i=0; wic_classes[i].classid; i++) > + { > + hr = get_clsid_key(wic_classes[i].classid, KEY_READ|KEY_WRITE, &clsid_key); > + if (!SUCCEEDED(hr)) break; > + > + res = RegCreateKeyExW(clsid_key, inprocserver32W, 0, NULL, 0, > + KEY_READ|KEY_WRITE, NULL, &ips32_key, NULL); > + if (res == ERROR_SUCCESS) > + { > + res = RegSetValueExA(ips32_key, NULL, 0, REG_SZ, (CONST BYTE*)"windowscodecs.dll", lstrlenA("windowscodecs.dll") + 1); > + if (res != ERROR_SUCCESS) > + break; > + res = RegSetValueExA(ips32_key, "ThreadingModel", 0, REG_SZ, (CONST BYTE*)"Apartment", lstrlenA("Apartment") + 1); > + if (res != ERROR_SUCCESS) > + break; > + } > + else > + break; > + > + RegCloseKey(clsid_key); > + } > + > + if (res != 0) hr = HRESULT_FROM_WIN32(res); > + > + return hr; > +} Please copy the standard regsvr.c registration code instead. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: cmdlgtst italian translation
by Nikolay Sivov June 25, 2009

June 25, 2009

Davide Pizzetti wrote: > Here's the italian translation for cmdlgtst > - MENUITEM "Pa&ge Setup", CM_U_PAGESETUP + MENUITEM "Installazione Pa&gina", CM_U_PAGESETUP } Correct me if I'm wrong, but it looks like you treated this as 'installation page', but it really means 'print page setup' - printing properties. Looking at notepad It.rc I've found: MENUITEM "&Imposta pagina...", CMD_PAGE_SETUP for similar 'Page Setup'. Nikolay S.

1 0

Re: AW: Shameless call for game testing
by Stefan Dösinger June 25, 2009

June 25, 2009

Am Thursday 25 June 2009 11:45:19 schrieb Joerg-Cyril.Hoehle(a)t-systems.com: > Stefan, > > >Generally, turning off GLSL turns down the advertised shader > >model to 1.x, which is the d3d8 feature set. > > Is this still the case since your mail > http://www.winehq.org/pipermail/wine-devel/2009-June/076766.html No - it is 2.0 now, or even 3.0 with the NV extensions. However, if the hardware supports less than 256 vertex shader constants, we still advertise SM 1.x. That is usually the case on HW that does not support more than SM 1.x anyway. If we advertised SM 2.0 on these cards, many shaders would very likely fall back to software rendering. > Does the Intel i915 qualify? How do I tell? How is this related to Mesa? > Would it require a Mesa much newer than Ubuntu 8.10 (yeah, I know 9.04 is > around)? In theory SM 2.0 with ARB. Mesa drivers are generally in a bad shape, especially the ones that are shipped by ubuntu, so many games are expected to fail. Shaders are just a small part of the equation. This ARB works helps Mesa insofar because it gives somewhat decent shader support without requiring a GLSL compiler. A GLSL compiler has to be pretty darn good to work properly with Wine, so before Gallium3D is stable and in use, I don't expect GLSL to work well in complex games with open source drivers. I talked to some Mesa developers on #winehackers, they might introduce their own ATI/Intel/Mesa specific extensions for SM 3.0 support on top of ARB shaders. Ie, a subset of the NV extensions that ATI cards support. (Nvidia HW supports more things than D3D makes available, and ATI cards can't support the full NV asm extensions)

1 0

Re: wined3d: fix a compiler warning
by Michael Stefaniuc June 25, 2009

June 25, 2009

Hello Austin, On Tue, Jun 23, 2009 at 12:47:18AM -0500, Austin English wrote: > Okay'ed by Henri > are you reinventing strcpy? > diff --git a/dlls/wined3d/arb_program_shader.c > b/dlls/wined3d/arb_program_shader.c > index 44b4fce..f759372 100644 > --- a/dlls/wined3d/arb_program_shader.c > +++ b/dlls/wined3d/arb_program_shader.c > @@ -922,11 +922,11 @@ static void shader_arb_get_register_name(const > struct wined3d_shader_instruction > { > if(This->baseShader.reg_maps.shader_version.major < 3) > { > - sprintf(register_name, > ctx->texcrd_output[reg->idx]); > + sprintf(register_name, "%s", ctx->texcrd_output[reg->idx]); > } > else > { > - sprintf(register_name, ctx->vs_output[reg->idx]); > + sprintf(register_name, "%s", ctx->vs_output[reg->idx]); > } > } > break; bye michael

5 6

Re: mshtml: Add slovenian transtaltion
by Paul Vriens June 25, 2009

June 25, 2009

Matej Spindler wrote: > My first patch to wine. Am I doing this right? > > > ------------------------------------------------------------------------ > > Hi Matej, Looks fine to me although I can't comment on the actual translations ;) Thanks for helping Wine and looking forward to more translation patches. (There is a typo in the email subject btw, should be "translation". No need to resend though I think) -- Cheers, Paul.

1 0

Re: [1/3] [wined3d] add ps_np2fixup_info structure (resend)
by Stefan Dösinger June 24, 2009

June 24, 2009

Am Wednesday 24 June 2009 17:51:44 schrieb Tobias Jakobi: The patches look ok to me

1 0

Shameless call for game testing
by Stefan Dösinger June 24, 2009

June 24, 2009

Hi, I need some help for people who spectate this list and use Wine mostly for gaming. In the past weeks, I have improved our ARB shader backend to support Shader Model 3.0 on cards that support GL_NV_vertex_program3 and GL_NV_fragment_program2(Geforce 6+), and 2.0 on other cards that have support for the needed shader constants(ATI Radeon 9500+, intel chips). What is this good for: *) Works better on platforms with bad GLSL support, like Macs and Mesa *) Deal with some corner cases, like texldd support on dx9 nvidia cards *) Slightly better performance in some games However, GLSL is the default right now, and we don't want to change this anytime soon, but I'd still like to get some testing of the ARB code. So I'd be happy if some people could disable GLSL(HKEY_CURRENT_USER/Software/Wine/Direct3D/UseGLSL="disabled") and see how their games work? In the ideal world, the results are like this: *) Everything that works with GLSL works with ARB on NV cards *) The ARB backend is slightly faster(I've seen approx. +10%) Can you test your games, and if something does not work that works with GLSL file a bug and assign it to me? Also please file a bug if there is a noticeable performance loss, or if ARB is MUCH faster(hints towards a GLSL shader code bug). If the game runs just fine, feel free to reply to this mail with your results and GLSL performance comparisons. Note that ATI cards do not support SM 3.0 with ARB. This is NOT a bug. Those cards just don't have any extensions that provide the additional features with ARB shaders, so you have to use GLSL there if you need SM 3.0. Thanks for your help, Stefan

1 0

Re: italian translations for winecfg
by Nikolay Sivov June 24, 2009

June 24, 2009

Davide Pizzetti wrote: > i've got a question: how i produce a patch with 'git diff'? what is the > correct syntax of the command? > Il giorno mer, 24/06/2009 alle 19.17 +0400, Nikolay Sivov ha scritto: > >> Davide Pizzetti wrote: >> >>> Here are the italian translations for winecfg. >>> >>> >> 1. Use 'git diff' format to produce patches >> 2. Use plain text attachments. >> >> Feel free to ask here any related questions Actually it's a correct format itself: 'git diff' from a git-tree. If you did commits to your local tree use 'git format-patch' as described http://www.winehq.org/sending_patches 'git format-patch --stdout --keep-subject origin' this will output all local commits with info headers. If you didn't commit you could just use 'git diff' output which will contain all changes from current head. Also add a more descriptive subject, something like: 'winecfg: Update Italian resources' with module you're working on as a prefix. Note that your attachment should be plain text without any additional formatting (no html messages, no wrapping).

1 0

Re: italian translations for winecfg
by Nikolay Sivov June 24, 2009

June 24, 2009

Davide Pizzetti wrote: > Here are the italian translations for winecfg. > 1. Use 'git diff' format to produce patches 2. Use plain text attachments. Feel free to ask here any related questions.

1 0

Re:
by Austin English June 24, 2009

June 24, 2009

2009/6/24 Pavel Procházka <pavelvonlostice(a)seznam.cz>: Howdy Pavel, A few minor things: A) Please use a descriptive subject, and put your message in the e-mail body. It's easier for those that don't read every patch but only care about certain areas to skim the mailing list that way. Also, it's hard to search the archives when there's no subject on the e-mail. B) +/*MULTIBUFFERING PART*/ It's not a huge deal, but please add spaces around comments, they're hard to read that way. C) @@ -2716,5 +2909,5 @@ START_TEST(visual) return ; cleanup: - releaseObjects(); + releaseObjects(); } Now sure why that was changed...did you accidentally change the encoding or something? -- -Austin

2 1

Re: Re: wine compatible logo needed
by M. Stefanov June 24, 2009

June 24, 2009

You're right. I'll use the full version. And an electronic manual wouldn't be practical in my case. Which is: begin "We need this." repeat "Is this what you need?"; "No, modify"; Mod_soft; until Response = "OK, this is it."; write(manual); burn(CD); install_all; end. So basically it's the end of the development cycle for that specifical program. That's why I think to specify the particular version of wine and linux distro that I'm certain it works with and throw in a note that experiences with other wine versions / linux distros / different OS may be different (with other words of course). And when/if the time comes for a v 2.0 of my soft, I'll test that against the latest wine that exists at the time of 2.0 release, and if it works, do the same with the 2.0 manual. Basically I was asking if there was a pre-existing template for such a case - a finished program which works out-of-the-box under wine at the time of the soft finalization...

2 1

free software replacement for MFC?
by karl＠gnu.org June 24, 2009

June 24, 2009

In the course of reviewing some possible projects for GNU, Richard Stallman asked me if there was any active work going on to write a free software replacement for MFC. >From the MFC pages I found on the Wine web site (http://www.winehq.org/docs/winelib-guide/mfc) which talk about ways of working with the Microsoft classes and don't mention any alternatives, I gather this isn't a current goal of Wine itself. But still, I figured that this would be the most likely place for any such project would be known about, or even find possible developers if one was to be started. Looking on the web, all I found was the old ofc.sf.net, which appears not to have gotten very far and to have been abandoned years ago, judging from the source repository. The other projects I came across, such as wxWidgets and SmartC++, appear not to try to be a compatible replacement for MFC, but rather a functional alternative. If anyone here has corrections, additions, suggestions related to those, I'd be grateful for any replies. Thanks, karl(a)gnu.org

3 2

Re: [put the subject here]
by Dmitry Timoshkov June 24, 2009

June 24, 2009

"Pavel Procházka" <pavelvonlostice(a)seznam.cz> wrote: > Subject:[2/3] wined3d: IWineGDISwapChainImpl_Present relevant to windows implementation > Making multibuffering working well when flip - sequence is W RGB, R GBW, G BWR, B WRG, W RGB. When W = WHITE, R = > RED, G = GREEN, B = BLUE. It is doing well for any count of backbuffers - for 1 too. Please try to make the patch subject short and clear. All additional comments put in the patch body. > - back = (IWineD3DSurfaceImpl *) This->backBuffer[0]; > + back = *((IWineD3DSurfaceImpl *)This->backBuffer[0]); /*this value can not be pointer*/ Any reason for the above change and comment? > + /*moving data from backbuffers to left - no pointers!*/ > + for(i=0;i<This->presentParms.BackBufferCount-1;i++) Some spaces wouldn't hurt, and would better match the code you are changing. -- Dmitry.

1 0

Re: avifil32: Romanian translation
by Michael Stefaniuc June 24, 2009

June 24, 2009

Paul, Paul Chitescu wrote: > Changelog: > avifil32: Romanian translation it looks like you are missing the #pragma code_page(65001) around the translation. bye michael

1 0

Re: programs/taskmanager: Fixed missing Dutch translations
by Paul Vriens June 24, 2009

June 24, 2009

Frans Kool wrote: > > > ------------------------------------------------------------------------ > > Beat you to it ;) http://www.winehq.org/pipermail/wine-patches/2009-June/074719.html -- Cheers, Paul.

1 0

Re: [1/3][resend] wined3d: Allowing infinity count of backbuffers
by paulo lesgaz June 24, 2009

June 24, 2009

--- En date de : Mer 24.6.09, Henri Verbeet <hverbeet(a)gmail.com> a écrit : De: Henri Verbeet <hverbeet(a)gmail.com> Objet: Re: [1/3][resend] wined3d: Allowing infinity count of backbuffers À: wine-devel(a)winehq.org Date: Mercredi 24 Juin 2009, 11h13 2009/6/24 Pavel Procházka <pavelvonlostice(a)seznam.cz>: > Please set a proper subject on your mails. I think this has been asked before. You can't just remove the check without making it work first, the patch has to make sense on its own. I don't get what you mean. Do you suggest that Pavel merges the two first patches in one single, with a title like "Allows multibuffering in ddraw" ? David

2 1

Re: [1/3][resend] wined3d: Allowing infinity count of backbuffers
by Henri Verbeet June 24, 2009

June 24, 2009

2009/6/24 Pavel Procházka <pavelvonlostice(a)seznam.cz>: > Please set a proper subject on your mails. I think this has been asked before. You can't just remove the check without making it work first, the patch has to make sense on its own.

1 0

Developers-Hints wiki page: Character encoding in resource file translations
by Frédéric Delanoy June 24, 2009

June 24, 2009

Hi all, According to http://wiki.winehq.org/Developers-Hints on the "http://wiki.winehq.org/Developers-Hints", AFAICT the resource files should generally - use the default Windows codepage for the specified language or - use UTF-8 surround with "#pragma code_page(65001)" at the top of the file and "#pragma code_page(default)" at the bottom Which of the encoding is preferred? UTF-8 ? Furthermore, - the "65001" should probably be replaced by "utf8" (I checked in tools/wrc/parser.l:373) [ which would be better IMNSHO in new/updated resource file] - the link to the list of codepages is broken; it should be http://msdn.microsoft.com/en-us/library/dd317756(VS.85).aspx Frédéric

4 3