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

Re: imm32: Change the default IME window to better reflect applications request

by Byeong-Sik Jeon

It looks good to me. Thanks to Aric :) Aric Stewart wrote: > First part of this change was proposed by Byeong-Sik Jeon > <wjsqudtlr(a)gmail.com> > Use a tooltip window instead to avoid stealing focus from the application. > Additionally respect parameters give to us by ImmSetCompositionWindow > for placement of the composition window.

March 29, 2007

Re: Nine good SoC propsals!

by Dan Kegel

On 3/28/07, Bryan DeGrendel <sirnuke(a)gmail.com> wrote: > Do you have any idea how many will be accepted? Six, maybe? It's hard to say, they juggle the slots right up until the last moment.

March 29, 2007

Re: Wine Benchmarks and CAPS

by Tom Wickline

On 3/29/07, Frank Richter <frank.richter(a)gmail.com> wrote: > > However, presence of a cap is not always better: for example > D3DPTEXTURECAPS_CUBEMAP_POW2 - MSDN says that this means "Device > requires that cube texture maps have dimensions specified as powers of > two." So it's actually better if the flag is absent (as that means > cubemaps can be non-POW2). It would be nice if the visual hint could > reflect that - this way a red background would be a clear signal that > "this needs work". I personally think any value that doesn't match, better or worse should be highlighted in red as it doesn't match that of Windows. > > -f.r. -- Tom Wickline Respectable computing - Linux/FOSS

March 29, 2007

Re: Wine Benchmarks and CAPS

by Frank Richter

On 29.03.2007 09:41, Tom Wickline wrote: > CAPS results: > http://wiki.winehq.org/DirectX-Caps Some note on the coloring: presumably, a green coloring in the Wine row means "better", red means "worse". For true/false caps those that Wine has but native doesn't are green, while those that Wine does not have but native not are red. However, presence of a cap is not always better: for example D3DPTEXTURECAPS_CUBEMAP_POW2 - MSDN says that this means "Device requires that cube texture maps have dimensions specified as powers of two." So it's actually better if the flag is absent (as that means cubemaps can be non-POW2). It would be nice if the visual hint could reflect that - this way a red background would be a clear signal that "this needs work". -f.r.

March 29, 2007

re: Improvement of WSAIoctl

by Axel Petzold

Hi Dan, > > I'm thrilled you're doing this. What's your software called? > The software is called FuturERS. If you are interested on further info, you can look at http://www.futura4retail.com. > > But you can't do this: > >> + * Copyright (C) the Wine project > > as there's no legal entity called "the Wine project". You have > to use your company's name, I think. (And be sure they've > granted permission.) Or if you have the rights to what you > do in your spare time, your own name is fine. > I copied the header from another file in the include directory. I've done it in my spare time and I don't insist on any copyrights on this patch. So, I thought to copy this as it is, was a good idea. Cheers, Axel

March 29, 2007

Re: More Direct3D settings in winecfg (was: Enabling GLSL in winecfg)

by Christoph Frick

On Thu, Mar 29, 2007 at 12:25:31PM +0200, Vit Hrachovy wrote: > Please share Your opinion. ok you asked for it ;) > Available Video Memory (text input box) > ---------------------- > User will input here the RAM size of his graphic card. According to > Stefan: "There are vendor dependent ways to read it, but implementing > them is pretty nasty(requires some private to winex11.drv). Altough we > had that discussion a number of times already and we only agreed on a > registry key so far." go for it! since there where a registry key for this i had to fix it source every time. there are games out there that wont work without proper setting (e.g. Richard Burns Rally in my case 1600x1200). a text input is simple and easy - everyone, who does not know what to do will leave it alone and the others will see the wrong number and fix it. later when there are better ways to acquire this number one still might be able to change/correct it there if the algorithms fail or for people with graphics-cards, that does not allow reading the value. > Enable GLSL (checkbox) > ----------- > GLSL should be made default in 1.0. However, according to Stefan: "some > drivers(*cough* macos *cough*) have serious problems with glsl". Until > there is a specification in 1.0 requirements that these issues have to > be resolved prior 1.0, this checkbox would be useful even past 1.0. dont go for it! if it is supposed to be the default enable it and keep the key for the developers. for osx: change the default at compile time using autohell? -- cu

March 29, 2007

More Direct3D settings in winecfg (was: Enabling GLSL in winecfg)

by Vit Hrachovy

Hi, according to Stefan, Direct X options regarding * Available Video Memory * Enable GLSL will be useful in winecfg / Graphics section. However there is still missing consensus to how and whether to implement user accessible way to enable/disable GLSL in winecfg. Ray Jones, Stefan and me would like this in winecfg. Please share Your opinion. According to the discussion results, I'm going to add either only Available Video Memory text input box, or both Memory and GLSL toggle checkbox to winecfg. Summary of previous discussion follows: Available Video Memory (text input box) ---------------------- User will input here the RAM size of his graphic card. According to Stefan: "There are vendor dependent ways to read it, but implementing them is pretty nasty(requires some private to winex11.drv). Altough we had that discussion a number of times already and we only agreed on a registry key so far." Enable GLSL (checkbox) ----------- GLSL should be made default in 1.0. However, according to Stefan: "some drivers(*cough* macos *cough*) have serious problems with glsl". Until there is a specification in 1.0 requirements that these issues have to be resolved prior 1.0, this checkbox would be useful even past 1.0. Stefan Dosinger with H. Verbeet pointed out that this option should be in Vertex Shader dropdown box, but after inspecting code, I've found wouldn't blend well with the rest of Vertex Shader idea. This is due to GLSL registry key differs from Vertex Shader registry key. Should they be merged into one? Ivan Gyurdiev pointed out that GLSL can be both enabled for hardware vertex shader and software vertex shader, so the idea of merging GLSL with Vertex Shader dropdown box would result in two menu options - 'GLSL with HW support' and 'GLSL with SW support'. Another stance is to make GLSL enabled by default in next Wine versions. Offscreen Rendering (dropdown box) ------------------- Default option will be 'fbo', optional is backbuffer. Stefan doesn't consider it worthy adding to winecfg. Regards Vit

March 29, 2007

Re: ntdll: "add" ZwAreMappedFilesTheSame to ntdll.spec

by Dmitry Timoshkov

"Louis. Lenders" <xerox_xerox2000(a)yahoo.co.uk> wrote: > diff --git a/dlls/ntdll/ntdll.spec b/dlls/ntdll/ntdll.spec > index e315057..3377db3 100644 > --- a/dlls/ntdll/ntdll.spec > +++ b/dlls/ntdll/ntdll.spec > @@ -948,7 +948,7 @@ > # @ stub ZwAllocateUserPhysicalPages > @ stdcall ZwAllocateUuids(ptr ptr ptr) NtAllocateUuids > @ stdcall ZwAllocateVirtualMemory(long ptr ptr ptr long long) NtAllocateVirtualMemory > -# @ stub ZwAreMappedFilesTheSame > +@ stub ZwAreMappedFilesTheSame > # @ stub ZwAssignProcessToJobObject > @ stub ZwCallbackReturn > # @ stub ZwCancelDeviceWakeupRequest It seems you haven't read an introducing comment in the first lines of ntdll.spec before changing it. -- Dmitry.

March 29, 2007

What is the X11 lock?

by Shachar Shemesh

Hi list, Can anyone please explain to me what the x11 lock is used for? I can see that SOME X11 functions (e.g. - read description on X11DRV_KEYBOARD_DetectLayout) require a lock, while others seem to call X11 functions with no lock. I can see that sometimes the x11 lock is obtained around a single X11 call. Is there any guideline I can follow that will tell me whether I need a lock for code I'm writing? What is the race this lock was designed to fix? Thanks, Shachar

March 29, 2007

extracting info from a minidump via winedbg

by Dennis Schridde

Hello Wine users! I've got a minidump from a ("real") Windows user of our game and would like to extract information from it using winedbg. The information winedbg gives me by default, is this: WineDbg starting on minidump on pid 068c warzone2100.exe was running on #1 Intel ???-0.521 CPU on Windows XP (2600) Register dump: CS:001b SS:0023 DS:0023 ES:0023 FS:003b GS:0000 EIP:0051008b ESP:0022f844 EBP:0022f858 EFLAGS:00010a87( - 00 ROISP1C) EAX:c7b054d8 EBX:19ff502e ECX:00000040 EDX:0000000f ESI:02010101 EDI:00000000 Stack dump: 0x0022f844: 00000000 00000000 00000000 3f800000 0x0022f854: 00000000 0022f8c8 0050e796 19ff502e 0x0022f864: 3f800000 00000000 00000000 00000000 0x0022f874: 00000000 00000000 00000000 ff4a4a4a 0x0022f884: 00000005 02010101 00000000 00000000 0x0022f894: 00000000 0022f8c8 00000000 00000000 Backtrace: =>1 0x0051008b (0x0022f858) 2 0x0050e796 (0x0022f8c8) 3 0x00410c3b (0x0022f948) 4 0x0041172d (0x0022f9c8) 5 0x004b2272 (0x0022f9d8) 6 0x004aa97b (0x0022f9f8) 7 0x004b615a (0x0022fab8) 8 0x004b663f (0x0022fad8) 9 0x004b67e1 (0x0022faf8) 10 0x0041e39e (0x0022fb28) 11 0x00459d3e (0x0022fb58) 12 0x0045b2ee (0x0022fca8) 13 0x0055e77b (0x0022fcf8) 14 0x0055e932 (0x0022fef8) 15 0x0055e483 (0x0022fff0) 16 0x00000000 (0x00000000) WineDbg starting on pid 068c Which is pretty rare. Via addr2line I can translate the backtrace to possibly valid locations in our sourcefiles. My questions are: - Why doesn't winedbg extract the sourcecode locations itself? - Why doesn't winedbg show me the other information included in the minidump, like the loaded modules, commandline options or version information? - How can I get the parameters to the last called function(s)? If winedbg is missing the commands/functions to achive the above, I may be able to provide it. The minidump functions seem to be documented rather good on msdn and it would just require printing it to the console. Thanks in advance, Dennis

March 29, 2007