- wine-devel - winehq.org

Re: [2/2] gdi32/tests: fix MSVC build in bitmap.c
by Marvin 04 Oct '11

04 Oct '11

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=14695 Your paranoid android. === WNT4WSSP6 (32 bit bitmap) === bitmap: unhandled exception c0000005 at 00416287 === W2KPROSP4 (32 bit bitmap) === bitmap: unhandled exception c0000005 at 00416287 === WXPPROSP3 (32 bit bitmap) === bitmap: unhandled exception 80000003 at 7C90120E === W2K3R2SESP2 (32 bit bitmap) === bitmap: unhandled exception c0000005 at 7C83F11C === WVISTAADM (32 bit bitmap) === bitmap: unhandled exception c0000005 at 7749653F === W2K8SE (32 bit bitmap) === bitmap: unhandled exception c0000005 at 00000000 === W7PRO (32 bit bitmap) === bitmap: unhandled exception c0000005 at 772D5A15 === W7PROX64 (32 bit bitmap) === bitmap: unhandled exception c0000005 at 00000000 === TEST64_W7SP1 (32 bit bitmap) === bitmap: unhandled exception c0000005 at 77593CDB === W7PROX64 (64 bit bitmap) === Timeout === TEST64_W7SP1 (64 bit bitmap) === Timeout

1 0

re: kernel32: Implement GetVolumePathName.
by Dan Kegel 04 Oct '11

04 Oct '11

Fails test here? ../../../tools/runtest -q -P wine -M ntdll.dll -T ../../.. -p ntdll_test.exe.so file.c && touch file.ok Unhandled exception: page fault on read access to 0x00212b18 in 32-bit code (0x7bc47995). Backtrace: =>0 HEAP_CreateFreeBlock+0xbb(subheap=0x110014, ptr=0x122b48, size=0xeffd0) [dlls/ntdll/heap.c:583] 1 HEAP_ShrinkBlock+0x42(subheap=0x110014, pArena=0x122b08, size=0x38) [dlls/ntdll/heap.c:685] 2 RtlAllocateHeap+0x2a8(heap=0x110000, flags=0x2, size=0x38) [dlls/ntdll/heap.c:1699] 3 RtlDosPathNameToNtPathName_U+0x35c(dos_path="C:\windows\system32", ntpath=0x32fbb4, file_part=(nil), cd=(nil)) [dlls/ntdll/path.c:394] 4 GetVolumePathNameW+0x107(filename="C:\windows\system32", volumepathname="?Ir\sandbox\slave\(", buflen=0x14) [dlls/kernel32/volume.c:1767] 5 test_file_name_information+0x179() [dlls/ntdll/tests/file.c:1304] 6 func_file+0x374() [dlls/ntdll/tests/file.c:1726] 7 run_test+0x9e(name="file.c") [include/wine/test.h:556] 8 main+0x23a(argc=<?>, argv=0x1103c8) [include/wine/test.h:624] 0x7bc47995 HEAP_CreateFreeBlock+0xbb [dlls/ntdll/heap.c:583] in ntdll: movl 0x0(%eax),%eax 583 (*(DWORD *)((char *)ptr + size) & ARENA_FLAG_FREE))

4 5

Regression by author list?
by Damjan Jovanovic 04 Oct '11

04 Oct '11

Hi Where do we find that list of regressions by author, that was in Alexandre's keynote at Wineconf? Thank you Damjan Jovanovic

2 1

unable to compile wine from latest git
by Vijay Kiran Kamuju 04 Oct '11

04 Oct '11

Hi, I just downloaded the git and tried compile it. I just issued `make` command after doing `./configure` But it gave the below errors: make[1]: Leaving directory `/media/PENDRIVE/devel/repo/wine/tools/wrc' make[1]: Entering directory `/media/PENDRIVE/devel/repo/wine/include' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/media/PENDRIVE/devel/repo/wine/include' make[1]: Entering directory `/media/PENDRIVE/devel/repo/wine/dlls/adsiid' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/media/PENDRIVE/devel/repo/wine/dlls/adsiid' rm -f dlls/libd3dcompiler.def && cp -p d3dcompiler_43/libd3dcompiler.def dlls/libd3dcompiler.def cp: cannot stat `d3dcompiler_43/libd3dcompiler.def': No such file or directory make: *** [dlls/libd3dcompiler.def] Error 1 Since the build of wine has changed a bit, i am unable to understand how to fix this issue. Thanks, Vijay

3 6

re: [1/3] kernel32/tests: Test K32GetProcessImageFileNameA() and improve the QueryFullProcessImageNameA() tests.
by Dan Kegel 04 Oct '11

04 Oct '11

Build fails here with -Werror: process.c: In function ‘test_GetProcessImageFileNameA’: process.c:1646: error: unused variable ‘image’ You seem to have two copies of that variable, one shadowing the other?

1 0

Alexandre's keynote
by Jeremy White 03 Oct '11

03 Oct '11

Thanks to Jon Parshall's hard work, we have Alexandre's keynote available here: http://www.youtube.com/watch?v=2rdDvMonTnQ Remember to have your libation at hand so you can play the game... <grin> Cheers, Jeremy

6 6

Re: [po]updated korean resource(2011-09-30)
by Francois Gouget 01 Oct '11

01 Oct '11

On Fri, 30 Sep 2011, Hwang YunSong(황윤성) wrote: [...] > #: winecfg.rc:88 > -#, fuzzy > msgid "(None)" > -msgstr "없음" > +msgstr "(없음)" I think you're missing a closing parenthesis here. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ question = ( to ) ? be : ! be; -- Wm. Shakespeare

1 0

Script for bisecting conformance test failures
by Francois Gouget 01 Oct '11

01 Oct '11

Would something like this be useful to include in Wine? If that's deemed interesting I can clean it up and submit it. I'm posting it here early in case it's useful for WineConf. It's a tool which you can use with git bisect to find the patch that causes a regression in a conformance test. It's used like this: git bisect start <bad> <good> git bisect run ./tools/testbisect dlls/gdi32/tests bitmap Come back a bit later and you have the bad patch. It can also be used with flaky tests by specifying the number of times to run a test. So if a test fails in 30% of the time you could only consider that it works if it succeeds 10 times in a row. You can even grep for a specific error if the test has other errors you don't care about. Finally you can also use it without git just to figure out if a test is flaky or not. For instance: $ ./tools/testbisect dlls/random/tests flaky 100 100 Failed 42 time(s) in 100 run(s) -> definitely flaky -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Indifference will certainly be the downfall of mankind, but who cares?

1 0

re: [PATCH 2/2] cmd: Handle truncation for console reads
by Dan Kegel 01 Oct '11

01 Oct '11

What's motivating this change? Are you quite sure you know how ReadConsole behaves? I bet one could write a test for this that used SendInput to send keystrokes to be read by ReadConsole, and verify the end of line and end of buffer behavior...

2 1

re: [PATCH 1/2] cmd: Improve WCMD_fgets documentation
by Dan Kegel 01 Oct '11

01 Oct '11

+ * We can't use the native f* functions because of the filename syntax differences + * between DOS and Unix. That doesn't belong in a function comment; it's an implementation detail that belongs, at most, inside the function.

2 1

Favorite bug: deadlock preventing backtraces?
by Dan Kegel 01 Oct '11

01 Oct '11

On one of my boxes, if I run winmm/midi.ok in a loop, it will eventually deadlock/crash ( http://bugs.winehq.org/show_bug.cgi?id=28388 ): err:ntdll:RtlpWaitForCriticalSection section 0x110060 "heap.c: main process heap section" wait timed out in thread 0022, blocked by 001f, retrying (60 sec) wine: Critical section 00110060 wait failed at address 0x7bc3484a (thread 0022), starting debugger... err:ntdll:RtlpWaitForCriticalSection section 0x110060 "heap.c: main process heap section" wait timed out in thread 0022, blocked by 001f, retrying (60 sec) Sadly, no backtrace follows ( http://bugs.winehq.org/show_bug.cgi?id=28265 ). Since I'm not around when it finally happens, I haven't tried btall yet. I suppose I should write a shell script to watch for that error message in the log, and run btall then... any better ideas? (I did try giving winedbg a private heap, didn't seem to prevent the deadlock.)

2 2

Using ApiTrace to improve D3D/OpenGL performance
by Emanuele Oriani 30 Sep '11

30 Sep '11

Dear all, Just wanted to bring to your attention ApiTrace 2.0, http://zrusin.blogspot.com/2011/09/apitrace-20.html . Apparently this tool is quite fast and should allow to play back GL commands, to analyse performance and replay commands. This might be useful to understand where some bottlenecks of wined3d might be? What do you think? Cheers

2 2

design comments in code or in tests?
by Joerg-Cyril.Hoehle＠t-systems.com 30 Sep '11

30 Sep '11

Hi, here's another one you WineConf folks may want to discuss. I've already expressed that there are not enough comments in mmdevapi's code. I thought about adding some, but wondered whether there's any value in using the header format that old code in Wine uses/used for automated doc. Generation (whatever the exact format was). For instance, comments ought to document GetPosition's contract in sufficient detail: - 0 <= GetPosition <= sum of written samples (modulo Frequency) - underruns don't count, it's no wall clock - monotically increasing(?) - should reflect speaker position, not buffering (MSDN says that) Don't look up MSDN. If that were complete enough, I would not have had the need to write as many tests as I did. Then I thought about placing comments in dlls/*/tests/ instead, because the test code is thrown away less often than the dll code. Seriously. Regards, Jörg Höhle

1 0

Subject: [PATCH 1/2 (try2)] mmdevapi: Don't fail if dwChannelMask is not set correctly
by Joerg-Cyril.Hoehle＠t-systems.com 30 Sep '11

30 Sep '11

Hi, Andrew Eikum writes: >(try2): Remove the test found by testbot. My Win7 Home VM passed that >test, so it seems we can expect any behavior. I object to the removal of the test like that. It should be replaced with a comment to explain that the behaviour of IsFormatSupported is very surprising, hence skipped. Actually, that behaviour begs for even more tests to understand what's going on. So far I believed in the invariant: IsFormatSupported == S_OK <=> Initialize == S_OK which is verified using all standard formats (1-2 channels), with one exception on testbot: render.c:396: Initialize (1, 48000x16x1) returns 8889000f unlike IsFormatSupported ^1^ means in exclusive mode, and only there. Now you experienced A. on testbot: IsFormatSupported(dwChannelMask==FFFF) == S_OK, like Initialize which conforms to the above invariant and simply suggests that ChannelMask is not checked at all, therefore this code in Wine seems too much: + fmtex->dwChannelMask != 0 && + fmtex->dwChannelMask != get_channel_mask(pwfx->nChannels)) B. your own Win7 Home system, with dwChannelMask=ffff, IsFormatSupported returns + ok(hr == S_FALSE || hr == AUDCLNT_E_UNSUPPORTED_FORMAT while Initialize returns + ok(hr == S_OK, which is weird. When does IFS return UNSUPPORTED_FORMAT? When does it return S_FALSE? In the latter case, is the suggested format anything else than GetMixFormat? What does exclusive mode return? Unlike in Wine, the shared mode "audio engine" mixer is a completely different SW entity than the exclusive mode "audio device", so it's important to check both. This needs more testing. In particular, tests performed on HW that supports more than 2 channels are welcome. Based on your surprising test result, I'd guess yours is such a system. Unlike DSound, mmdevapi has no GetSpeakerConfig that I'm aware of (short of Device Topology), so I don't know how apps find out about multi-channel abilities. BTW, I believe + fmtex->dwChannelMask != get_channel_mask(pwfx->nChannels)) in Wine is bogus anyway, because it's arbitrary. There exist different 3/4/5/6 channel configurations. Regards, Jörg Höhle

1 0

winscard
by Vincent Hardy 30 Sep '11

30 Sep '11

Hi all, Here are four patches that are a partial but functional implementation of winscard. I installed "Belgian Electronic Identity Card MiddleWare" (http://eid-mw.googlecode.com/files/BeidMW35-6995.msi) I tested winscard by starting beid35gui.exe and I can see my identity card data. Moreover, this should help to solve this bug http://bugs.winehq.org/show_bug.cgi?id=26978. Are these 4 patches good enough to be sent to wine-patch ? winscard is really useful for me and probably for other people too. Vincent

5 4

Re: user32: Prioritize focus for dialog owner on EndDialog.
by Marvin 30 Sep '11

30 Sep '11

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=14644 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout === TEST64_W7SP1 (64 bit msg) === Timeout

2 1

Buildbot status
by Dan Kegel 30 Sep '11

30 Sep '11

The buildbot is alive and well and has been finding real problems of various sorts roughly once a day for some time. I'm not spending much time on it anymore, just watching and tweaking occasionally. The number of spurious failures is tapering off as I slowly expand the blacklist and polish up the scripts. I plan to turn on email notifications to wine-devel once there have been no spurious failure reports for five days, probably sometime in October. http://wiki.winehq.org/BuildBot is up to date in case anyone's interested in details.

4 6

Re: [1/3] kernel32: Reset LastError if GetModuleFileName() succeeds.
by Francois Gouget 30 Sep '11

30 Sep '11

On Fri, 30 Sep 2011, Francois Gouget wrote: > This is necessary because LastError may already be set to > ERROR_INSUFFICIENT_BUFFER which would mislead the caller. And of course the older versions of Windows (up to XP SP3!) don't reset lasterror so the test bit of the patch cannot go in. I'd still argue that GetModuleFileNameW() should reset LastError though. -- Francois Gouget <fgouget(a)codeweavers.com>

1 0

Re: [1/3] kernel32: Reset LastError if GetModuleFileName() succeeds.
by Marvin 30 Sep '11

30 Sep '11

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=14640 Your paranoid android. === WNT4WSSP6 (32 bit module) === module.c:50: Test failed: LastError was not reset: -559038737 module.c:58: Test failed: LastError was not reset: -559038737 module.c:50: Test failed: LastError was not reset: -559038737 module.c:58: Test failed: LastError was not reset: -559038737 === W2KPROSP4 (32 bit module) === module.c:50: Test failed: LastError was not reset: -559038737 module.c:58: Test failed: LastError was not reset: -559038737 module.c:50: Test failed: LastError was not reset: -559038737 module.c:58: Test failed: LastError was not reset: -559038737 === WXPPROSP3 (32 bit module) === module.c:50: Test failed: LastError was not reset: -559038737 module.c:58: Test failed: LastError was not reset: -559038737 module.c:50: Test failed: LastError was not reset: -559038737 module.c:58: Test failed: LastError was not reset: -559038737

1 0

Re: gdiplus: Include an alpha channel in HBITMAPs created from Bitmaps.
by Vincent Povirk 29 Sep '11

29 Sep '11

Don't commit this. Seems I forgot about top-down vs. bottom-up dibs. On Thu, Sep 29, 2011 at 12:03 PM, Vincent Povirk <madewokherd(a)gmail.com> wrote: > For bug 55549. >

1 0

Status for the ID3DXEffect interface
by Rico Schüller 29 Sep '11

29 Sep '11

Hi, I'd like to say a word for the effect interface in d3dx9_xx.dll, what's already done and what's on the todo list. The parser for binary effects works pretty much. It should nearly parse the effect files completely, but it should fail on effect files which contain functions (if anyone has a binary effect with a function, I'd be interested in it). It is also possible to Get/Set some values, but not yet all, because there are some tricky cases which I haven't figured out completely yet (an example is GetVector() on an D3DXPT_INT). I'm currently working on the correct applying for the states and making some progress with that. But it seems to me that there are a lot of special cases in that. Todo: - Apply the states - Handle parameter blocks - State savings: State saving and restoring in Begin/End is needed. - ASCII effects: The effect could be supplied as byte code or as ASCII text. - ID3DXEffectPool: The support for effect pools is needed. I'm not sure if it might be useful to post an example of a commented binary effect file to make the format "visible" without reading the code. At least it could help when writing the ASCII effect parser. Cheers Rico

1 0

[PATCH 0/5] CMD command line parsing (try 5)
by Martin Wilck 29 Sep '11

29 Sep '11

Contrary to what I said before, here is another attempt for my CMD patch series. Thanks to Frederic for reviewing this again, I made the suggested changes. Martin Wilck (5): cmd/tests: add tests for command line parsing cmd: use GetCommandline() rather than argv cmd: improve parsing of quotes in command line cmd: fix handling of special characters in command line cmd: fix parameter parsing of quotes and special chars programs/cmd/batch.c | 83 ++++++--- programs/cmd/tests/rsrc.rc | 6 + programs/cmd/tests/test_builtins.cmd.exp | 8 +- programs/cmd/tests/test_cmdline.cmd | 158 +++++++++++++++++ programs/cmd/tests/test_cmdline.cmd.exp | 77 +++++++++ programs/cmd/wcmdmain.c | 276 ++++++++++++------------------ 6 files changed, 407 insertions(+), 201 deletions(-) create mode 100644 programs/cmd/tests/test_cmdline.cmd create mode 100644 programs/cmd/tests/test_cmdline.cmd.exp -- 1.7.3.4

1 0

[PATCH 0/5] (4th attempt) CMD command line parsing
by Martin Wilck 29 Sep '11

29 Sep '11

This is my 4th attempt at fixing the cmd command line treatment. All patches pass the cmd tests with 0 errors both under wine and on the Test Bot, including NT. Whitespace issues are fixed, too. Apart from that, the code is the same as before. The size of my patches has been criticized - only patch 2/5 is really big, but it has to be that way to pass the tests. This will also be my last attempt to get this merged. If the patches don't get applied this time, I hope that the cmd Gurus (Frederic or Dan) will take up the bits they like and get them in over time. If there are any technical issues or bugs in my code, I'll of course take care (please email me privately, as I'm not monitoring wine-devel). A private side note: I estimate that I have spent at least 10x more effort and time to get the tests right and the patches submission-ready than I spent on fixing the actual Wine code. I believe this project needs to think over its policies. I fully understand that a project this big needs to take a lot of care to maintain qualitiy standards. But the way this is currently working is discouraging and frustrating for casual contributors like myself. Martin Wilck (5): cmd/tests: add tests for command line parsing cmd: use GetCommandline() rather than argv cmd: improve parsing of quotes in command line cmd: fix handling of special characters in command line cmd: fix parameter parsing of quotes and special chars programs/cmd/batch.c | 82 ++++++--- programs/cmd/tests/rsrc.rc | 6 + programs/cmd/tests/test_builtins.cmd.exp | 8 +- programs/cmd/tests/test_cmdline.cmd | 158 +++++++++++++++++ programs/cmd/tests/test_cmdline.cmd.exp | 77 +++++++++ programs/cmd/wcmdmain.c | 276 ++++++++++++------------------ 6 files changed, 406 insertions(+), 201 deletions(-) create mode 100755 programs/cmd/tests/test_cmdline.cmd create mode 100755 programs/cmd/tests/test_cmdline.cmd.exp -- 1.7.3.4

4 6

Re: [PATCH] winex11: Make MapColor fall back to GetNearestIndex
by Alex Henrie 29 Sep '11

29 Sep '11

2011/9/29 David Kiefer <hevanen(a)googlemail.com>: > A possible solution is to have MapColor call GetNearestIndex as a last > resort instead. This both fixes the problem and results in acceptable > performance. Thanks for the tip. I've submitted a new patch which uses this solution instead, and it works better. 2011/9/29 Roderick Colenbrander <thunderbird2k(a)gmail.com>: > I'm not really sure how useful it is to try to optimize parts of the > X11 code now that the DIB engine is progressing nicely. Once the DIB > engine is done this code will disappear anyway. No need for horrible > X11 hacks to offload any DIB rendering and converting the X11 result > back into a DIB. You're right: the DIB engine would be much better. What needs to be done to get the DIB engine to work with Age of Empires II? -Alex

1 0

Re: [PATCH] Enable X11DRV_DIB_GetImageBits_8 in all cases and optimize X11DRV_DIB_GetNearestIndex to fix bug 2666 and other strange behavior
by David Kiefer 29 Sep '11

29 Sep '11

While this patch indeed fixes bug 2666, it also kills performance, at least with Age of Empires II. The frame rate in the menu for me is about one frame every three seconds and about 1 fps in-game. With the patch, the work previously done by X11DRV_DIB_MapColor is now done by X11DRV_DIB_GetNearestIndex. Unlike GetNearestIndex, MapColor avoids traversing the entire palette most of the time by reusing the previous index in the destination bitmap if the color has not changed. However, MapColor only checks for exact matches and returns the first palette entry if none was found, effectively causing bug 2666. A possible solution is to have MapColor call GetNearestIndex as a last resort instead. This both fixes the problem and results in acceptable performance. David

2 1

Odd audio regression (interaction between two commits)
by Erich Hoover 29 Sep '11

29 Sep '11

A: 64b14c0ecdd13530a92ff636c451523a99253a0b (quartz: Start DirectSound renderer as soon as possible.) B: e786998daff4ad49521a4c9c39c172ddcdcad82a (dsound: Reimplement rendering devices on mmdevapi.) I've been working with the audio in Fallout 3 and Fallout New Vegas for some time and I noticed a regression recently where the audio stopped working properly after the main menu (commit B). This triggered a memory of a similar experience I had where commit A caused the same behavior, but it only did so for PulseAudio users. So, on a hunch, I reverted commit A on the latest git and found that the audio went back to normal again. I'm not entirely sure what commit A could do to cause this problem, and I know you guys are busy with the audio changes, so if someone could point me in the right direction then I will try and track this issue down. Thanks! Erich Hoover ehoover(a)mines.edu

1 0

winecfg: Remove driver selection from Audio tab.
by Joerg-Cyril.Hoehle＠t-systems.com 29 Sep '11

29 Sep '11

Hi, I'm not satisfied with the removal of the audio tree from winecfg. Beside allowing to switch or disable drivers, one key feature was to allow inspecting the devices that winmm found on this system. For instance, I've not yet had time to report a bug that since wine-1.3.25, one such entry shows an empty name IIRC. It allowed users to easily check whether e.g. Timidity was recognized or whether "MIDI through" was the only output. It allowed users to easily tell whether their 5:1 sound card was recognized beside the default device. Bugzilla shows 350 entries about winecfg & audio. It had a use. What are users supposed to do now? Regards, Jörg Höhle

9 18

Favorite bug: deadlock preventing backtraces?
by Joerg-Cyril.Hoehle＠t-systems.com 29 Sep '11

29 Sep '11

Dan Kegel wrote: >Sadly, no backtrace follows I've not had midi.ok crash on me, but now that you mention it, I've had occasional crashes of random reasons in various apps yet got no backtrace. I seem to remember that there have been times where backtraces would be produced more reliably. So perhaps 1/2 a suggestion would be to try how an older version behaves. It shouldn't matter with midi. But which older version to choose? Regards, Jörg Höhle

1 0

Re: d3dx9_26: Add custom ID3DXEffect interface.
by Erich Hoover 29 Sep '11

29 Sep '11

SetRawValue is at the end of the table, so it being extra will not influence any older application. So, you should be able to get the same functionality with way less code by adding that alternative GUID to the QueryInterface in d3dx9_36. Erich Hoover ehoover(a)mines.edu

5 8

Re: [PATCH] Enable X11DRV_DIB_GetImageBits_8 in all cases and optimize X11DRV_DIB_GetNearestIndex to fix bug 2666 and other strange behavior
by Frédéric Delanoy 29 Sep '11

29 Sep '11

Please do not include bug number in commit message summary line. Put something like 'fixes bug 123 in the commit header See http://wiki.winehq.org/SubmittingPatches for more info (e.g. "subject line" and "include a description" sections) Frédéric

2 3

Re: d3dx9_26: Add custom ID3DXEffect interface
by luis.busquets＠ilidium.com 29 Sep '11

29 Sep '11

And what about introducing wined3dx to wrap up all d3dx9, d3dx10, ... functions?

1 0

CreateDC and DRIVER_GetDriverName
by Bruno Jesus 28 Sep '11

28 Sep '11

Hi, I'm seeking advice as I really don't understand anything about wine display drawing (gdi, x11, ...). Every game created with an old win3.11 tool called Klik & Play do not work in wine because a driver called DIB is passed as parameter to CreateDC. Till today I've only seen a driver called DISPLAY being used by all sorts of applications. Looking at the DRIVER_GetDriverName [1] function I can see a list where 3 different drivers are supported. In an attempt to run an old game called Mortuum [2] I can see that it always fail due to this missing DIB driver: err:dc:CreateDCW no driver found for L"DIB" My lack of knowledge made me do a dirty hack in the CreateDCW function forcing the driver DISPLAY to be used instead of DIB and when I started the game it draw it's first screen and then crashed. What should be done to support the DIB driver name now that DIB is implemented in wine? [1] = http://source.winehq.org/source/dlls/gdi32/driver.c#L800 [2] = ftp://ftp.padua.org/pub/msdos/windows/games/local/mortuum.zip Best wishes, Bruno -- universe* god::bigbang (void); //and then it all began...

1 0

Re: [PATCH] d3dx9_36: avoid using fabsf/fmaxf
by Marvin 28 Sep '11

28 Sep '11

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=14617 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [PATCH] d3dx9_36: avoid using fabsf/fmaxf
by Austin English 28 Sep '11

28 Sep '11

On Wed, Sep 28, 2011 at 01:51, Natanael Copa <ncopa(a)alpinelinux.org> wrote: > This fixes compiling on Alpine Linux and other uClibc based distros. > > This is related bug 28247 and commit 4cddd5ffdf0c568445365c6c62e7788d7dbbca7d > --- > dlls/d3dx9_36/tests/mesh.c | 14 +++++++------- > 1 files changed, 7 insertions(+), 7 deletions(-) > > diff --git a/dlls/d3dx9_36/tests/mesh.c b/dlls/d3dx9_36/tests/mesh.c > index 6a78e64..c09607f 100644 > --- a/dlls/d3dx9_36/tests/mesh.c > +++ b/dlls/d3dx9_36/tests/mesh.c > @@ -6160,7 +6160,7 @@ static void check_vertex_components(int line, int mesh_number, int vertex_number > { > FLOAT *got = (FLOAT*)(got_ptr + decl_ptr->Offset); > FLOAT *exp = (FLOAT*)(exp_ptr + decl_ptr->Offset); > - FLOAT diff = fabsf(*got - *exp); > + FLOAT diff = abs(*got - *exp); > ok_(__FILE__,line)(diff <= FLT_EPSILON, "Mesh %d: Got %f for vertex %d %s, expected %f.\n", > mesh_number, *got, vertex_number, usage_strings[decl_ptr->Usage], *exp); > break; > @@ -6169,7 +6169,7 @@ static void check_vertex_components(int line, int mesh_number, int vertex_number > { > D3DXVECTOR2 *got = (D3DXVECTOR2*)(got_ptr + decl_ptr->Offset); > D3DXVECTOR2 *exp = (D3DXVECTOR2*)(exp_ptr + decl_ptr->Offset); > - FLOAT diff = fmaxf(fabsf(got->x - exp->x), fabsf(got->y - exp->y)); > + FLOAT diff = max(abs(got->x - exp->x), abs(got->y - exp->y)); > ok_(__FILE__,line)(diff <= FLT_EPSILON, "Mesh %d: Got (%f, %f) for vertex %d %s, expected (%f, %f).\n", > mesh_number, got->x, got->y, vertex_number, usage_strings[decl_ptr->Usage], exp->x, exp->y); > break; > @@ -6178,8 +6178,8 @@ static void check_vertex_components(int line, int mesh_number, int vertex_number > { > D3DXVECTOR3 *got = (D3DXVECTOR3*)(got_ptr + decl_ptr->Offset); > D3DXVECTOR3 *exp = (D3DXVECTOR3*)(exp_ptr + decl_ptr->Offset); > - FLOAT diff = fmaxf(fabsf(got->x - exp->x), fabsf(got->y - exp->y)); > - diff = fmaxf(diff, fabsf(got->z - exp->z)); > + FLOAT diff = max(abs(got->x - exp->x), abs(got->y - exp->y)); > + diff = max(diff, abs(got->z - exp->z)); > ok_(__FILE__,line)(diff <= FLT_EPSILON, "Mesh %d: Got (%f, %f, %f) for vertex %d %s, expected (%f, %f, %f).\n", > mesh_number, got->x, got->y, got->z, vertex_number, usage_strings[decl_ptr->Usage], exp->x, exp->y, exp->z); > break; > @@ -6188,9 +6188,9 @@ static void check_vertex_components(int line, int mesh_number, int vertex_number > { > D3DXVECTOR4 *got = (D3DXVECTOR4*)(got_ptr + decl_ptr->Offset); > D3DXVECTOR4 *exp = (D3DXVECTOR4*)(exp_ptr + decl_ptr->Offset); > - FLOAT diff = fmaxf(fabsf(got->x - exp->x), fabsf(got->y - exp->y)); > - diff = fmaxf(diff, fabsf(got->z - exp->z)); > - diff = fmaxf(diff, fabsf(got->w - exp->w)); > + FLOAT diff = max(abs(got->x - exp->x), abs(got->y - exp->y)); > + diff = max(diff, abs(got->z - exp->z)); > + diff = max(diff, abs(got->w - exp->w)); > ok_(__FILE__,line)(diff <= FLT_EPSILON, "Mesh %d: Got (%f, %f, %f, %f) for vertex %d %s, expected (%f, %f, %f, %f).\n", > mesh_number, got->x, got->y, got->z, got->w, vertex_number, usage_strings[decl_ptr->Usage], exp->x, exp->y, exp->z, got->w); > break; > -- > 1.7.6.1 fmaxf was already removed in http://source.winehq.org/git/wine.git/commitdiff/49064869595a8d0c97a79055eb… -- -Austin

1 0

Re: [2/3] cmd: Avoid checking whether we're in console mode for every read (try 2)
by Eric Pouech 28 Sep '11

28 Sep '11

Le 28/09/2011 01:01, Frédéric Delanoy a écrit : > --- > programs/cmd/batch.c | 9 ++++----- > programs/cmd/builtins.c | 4 ++-- > programs/cmd/wcmd.h | 5 +++-- > programs/cmd/wcmdmain.c | 21 +++++++++++++-------- > 4 files changed, 22 insertions(+), 17 deletions(-) actually, console handles have their 2 lower bit set you could use it to even simplify further the code A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

1 0

Re: [PATCH 1/2] mmdevapi: Don't fail if dwChannelMask is not set correctly
by Marvin 28 Sep '11

28 Sep '11

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=14610 Your paranoid android. === WVISTAADM (32 bit render) === render.c:232: Test failed: IsFormatSupported(dwChannelMask = 0xffff) call returns 00000000 === W2K8SE (32 bit render) === render.c:232: Test failed: IsFormatSupported(dwChannelMask = 0xffff) call returns 00000000 === W7PRO (32 bit render) === render.c:232: Test failed: IsFormatSupported(dwChannelMask = 0xffff) call returns 00000000 === W7PROX64 (32 bit render) === render.c:232: Test failed: IsFormatSupported(dwChannelMask = 0xffff) call returns 00000000 === TEST64_W7SP1 (32 bit render) === render.c:232: Test failed: IsFormatSupported(dwChannelMask = 0xffff) call returns 00000000 === W7PROX64 (64 bit render) === render.c:232: Test failed: IsFormatSupported(dwChannelMask = 0xffff) call returns 00000000 === TEST64_W7SP1 (64 bit render) === render.c:232: Test failed: IsFormatSupported(dwChannelMask = 0xffff) call returns 00000000

1 0

Re: browseui/tests: Skip some tests if IEnumACString is not supported.
by Marvin 28 Sep '11

28 Sep '11

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=14608 Your paranoid android. === WNT4WSSP6 (32 bit autocomplete) === autocomplete.c:250: Test failed: CoCreateInstance(&CLSID_ACLMulti, NULL, CLSCTX_INPROC, &IID_IEnumString, (LPVOID *)&obj) failed: 80040154 === WXPPROSP3 (32 bit autocomplete) === autocomplete.c:261: Test failed: QueryInterface(IID_IEnumACString) failed: 0 === W2K3R2SESP2 (32 bit autocomplete) === autocomplete.c:261: Test failed: QueryInterface(IID_IEnumACString) failed: 0 === WVISTAADM (32 bit autocomplete) === autocomplete.c:261: Test failed: QueryInterface(IID_IEnumACString) failed: 0 === W2K8SE (32 bit autocomplete) === autocomplete.c:261: Test failed: QueryInterface(IID_IEnumACString) failed: 0 === W7PRO (32 bit autocomplete) === autocomplete.c:261: Test failed: QueryInterface(IID_IEnumACString) failed: 0 === W7PROX64 (32 bit autocomplete) === autocomplete.c:261: Test failed: QueryInterface(IID_IEnumACString) failed: 0 === TEST64_W7SP1 (32 bit autocomplete) === autocomplete.c:261: Test failed: QueryInterface(IID_IEnumACString) failed: 0 === W7PROX64 (64 bit autocomplete) === autocomplete.c:261: Test failed: QueryInterface(IID_IEnumACString) failed: 0 === TEST64_W7SP1 (64 bit autocomplete) === autocomplete.c:261: Test failed: QueryInterface(IID_IEnumACString) failed: 0

1 0

Re: [1/3] cmd: Avoid reading char by char from console (try 2)
by Alexandre Julliard 28 Sep '11

28 Sep '11

Frédéric Delanoy <frederic.delanoy(a)gmail.com> writes: > @@ -181,13 +181,21 @@ WCHAR *WCMD_parameter (WCHAR *s, int n, WCHAR **where, WCHAR **end) { > * the LF (or CRLF) from the line. > */ > > -WCHAR *WCMD_fgets (WCHAR *s, int noChars, HANDLE h) { > - > - DWORD bytes; > - BOOL status; > +WCHAR *WCMD_fgets (WCHAR *s, int noChars, HANDLE h) > +{ > + DWORD bytes, charsRead, dummy; > + BOOL status, is_console_handle; > WCHAR *p; > > p = s; > + is_console_handle = !!GetConsoleMode(h, &dummy); > + if (is_console_handle) { > + status = ReadConsoleW(h, s, noChars, &charsRead, NULL); ReadConsole will fail if it's not a console, the check is redundant. -- Alexandre Julliard julliard(a)winehq.org

2 2

mmdevapi performance analysis
by Joerg-Cyril.Hoehle＠t-systems.com 28 Sep '11

28 Sep '11

Hi, While the 3D guys work on performance improvements, we audio guys kill it. Luckily gfx data is shuffled around in MB/s, audio only in hundred kB/s, so hopefully it doesn't weight that much. Let's have a look at how data wanders around with dsound, winmm and mmdevapi. waveOutWrite with mmdevapi: copy to mmdevapi ALSA/OSS buffer copy some in case of mmdevapi buffer wrap around write buffer to ALSA/OSS waveOutWrite old driver model: write header to ALSA/OSS waveOutWrite involving MSACM with mmdevapi: convert PCM to MSACM, writing to new buffer copy to mmdevapi ALSA/OSS buffer copy some in case of buffer wrap around write to ALSA/OSS Here, if msacm/waveform.c had the courage to delay conversion until GetBuffer time, some copying could be avoided as msacm would write directly into mmdevapi's buffer. Being overly protective ("I should convert before GetBuffer because afterwards I might not have enough time") ends up wasting CPU cycles, hence paradoxically increasing the probability of being late thus causing underruns. The cause for the impedance mismatch between winmm and mmdevapi is what I call "owner inversion". The app supplies winmm with a pointer to its data buffers. As mmdevapi does the same, some transfer is needed between both. Arguably, mmdevapi is not the best target for winmm in Wine... DSOUND_WaveQueue newest "reimplement rendering on mmdevapi" in 1.3.30: write to dsound secondary buffer mix secondary to primary buffer copy to mmdevapi buffer copy some more in case of mmdevapi buffer wrap around write buffer to ALSA/OSS It looks like the new code misses the opportunity to equate device buffer with primary buffer. Instead we've got a cascade of buffers. Why is dsound's primary (mixing target) not mmdevapi's buffer? What's the goal? Ideally, 1. ALSA's mmdevdrv Get/ReleaseBuffer use snd_pcm_mmap_begin/commit, avoiding copying from mmdevapi to ALSA; 2. mmdevapi's buffer becomes DSound's primary, avoiding copying from dsound to mmdevapi. This applies even to CoreAudio where there's not really an mmdevapi buffer. The result: DSound's mixer talks straight with the HW. This should be no surprise. mmdevapi's shared mode mixer probably has roots in dsound's. BTW, what prevents equating dsound's secondary buffers with mmdevapi's shared mode streams and let the underlying device perform the mixing? Regards, Jörg Höhle

1 0

Update on testbot
by Maarten Lankhorst 28 Sep '11

28 Sep '11

Hi all, I moved the windows 7 x64 vm with sp1 applied to the base pool now. This means that all submitted patches will be run on that vm as well. The original win7 vm is still available under its own name. Since all tests pass on that according to winehq tests I'm keeping it in the base pool. I hope to see all tests on the new vm fixed as well. They mostly appear to be related to the ie9 update, but msctf:inputprocessor and msi:install fail as well. ~Maarten

2 1

Re: mscoree: Add ICorDebug interface support (try 3)
by Vincent Povirk 28 Sep '11

28 Sep '11

It's OK to call CLRMetaHost methods directly with a NULL ICLRMetaHost instance. It's a singleton, and none of the methods use the interface. You might want to check whether you get a new ICorDebug interface every time you request one. I suspect you do. On Wed, Sep 28, 2011 at 1:21 AM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Hi, > Changed to use ICLRRuntimeInfo::GetInterface, suggest by Vincent. > Moved the #undef to the header. > > > Changelog: > mscoree: Add ICorDebug interface support > > > Best Regards > Alistair Leslie-Hughes > > > > > >

1 0

Re: mscoree: Add ICorDebug interface support (try 3)
by Marvin 28 Sep '11

28 Sep '11

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=14599 Your paranoid android. === W2K3R2SESP2 (32 bit debugging) === debugging.c:82: Test failed: CreateDebuggingInterfaceFromVersion returned 80070057

1 0

re: dsound: Place storage class before type qualifier
by Dan Kegel 28 Sep '11

28 Sep '11

Hi Andrew, doesn't seem to apply here: $ patch -p1 < 79377.patch patching file dlls/dsound/dsound_main.c Hunk #1 FAILED at 319. 1 out of 1 hunk FAILED -- saving rejects to file dlls/dsound/dsound_main.c.rej ---------- Forwarded message ---------- From: <buildbot(a)kegel.com> Date: Tue, Sep 27, 2011 at 2:50 PM Subject: Re: 79377: dsound: Place storage class before type qualifier To: dank(a)kegel.com, wine-tests-results(a)winehq.org This is an experimental automated build and test service. Please feel free to ignore this email while we work the kinks out. For more info about this message, see http://wiki.winehq.org/BuildBot The Buildbot has detected a failed build on builder runtests-default while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests-default/builds/128 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) BUILD FAILED: failed git Errors: error: patch failed: dlls/dsound/dsound_main.c:319 error: dlls/dsound/dsound_main.c: patch does not apply

1 0

Re: [PATCH] kernel32: make it possible to create a backtrace from a RaiseException exception in gdb
by Alexandre Julliard 27 Sep '11

27 Sep '11

Bernhard Loos <bernhardloos(a)googlemail.com> writes: > @@ -60,6 +60,17 @@ static PTOP_LEVEL_EXCEPTION_FILTER top_filter; > typedef INT (WINAPI *MessageBoxA_funcptr)(HWND,LPCSTR,LPCSTR,UINT); > typedef INT (WINAPI *MessageBoxW_funcptr)(HWND,LPCWSTR,LPCWSTR,UINT); > > +#ifdef __i386__ > +/* without this, it's impossible to get a backtrace from the raised > + * exception in winedbg in gdb mode */ > +void RaiseException_helper(EXCEPTION_RECORD *r, void *f) DECLSPEC_HIDDEN; > +__ASM_GLOBAL_FUNC(RaiseException_helper, > + "mov 0x4(%esp),%eax\n\t" > + "push %eax\n\t" > + "mov 0xc(%esp),%eax\n\t" > + "call *%eax\n\t" > + "ret") > +#endif You shouldn't need anything like that. -- Alexandre Julliard julliard(a)winehq.org

2 3

re: winmm: waveOutReset returns all buffers.
by Dan Kegel 27 Sep '11

27 Sep '11

Fails to apply here. (Requires fuzz, which Alexandre says is verboten.) ---------- Forwarded message ---------- From: <buildbot(a)kegel.com> Date: Mon, Sep 26, 2011 at 2:35 AM Subject: Re: 79321: winmm: waveOutReset returns all buffers. To: dank(a)kegel.com, wine-tests-results(a)winehq.org This is an experimental automated build and test service. Please feel free to ignore this email while we work the kinks out. For more info about this message, see http://wiki.winehq.org/BuildBot The Buildbot has detected a failed build on builder runtests-default while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests-default/builds/63 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) BUILD FAILED: failed git Errors: error: patch failed: dlls/winmm/waveform.c:1653 error: dlls/winmm/waveform.c: patch does not apply

2 2

Re: [PATCH] ntdll/signal_i386.c: RtlCaptureContext locals + args are 12 bytes instead of 8 (return address + CONTEXT * arg + %eax local
by Alexandre Julliard 27 Sep '11

27 Sep '11

Bernhard Loos <bernhardloos(a)googlemail.com> writes: > @@ -1181,7 +1181,7 @@ __ASM_STDCALL_FUNC( RtlCaptureContext, 4, > __ASM_CFI(".cfi_adjust_cfa_offset 4\n\t") > "popl 0xc0(%eax)\n\t" /* context->EFlags */ > __ASM_CFI(".cfi_adjust_cfa_offset -4\n\t") > - "leal 8(%esp),%edx\n\t" > + "leal 0xc(%esp),%edx\n\t" > "movl %edx,0xc4(%eax)\n\t" /* context->Esp */ That's not really more correct, it's supposed to return the caller frame but there's no good way of doing that. What are you trying to fix? -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: mscoree: Add ICorDebug interface support (try 2)
by Vincent Povirk 27 Sep '11

27 Sep '11

You really should implement the .NET 4 version of this first (MSDN helpfully points to ICLRRuntimeInfo::GetInterface, which is CLRRuntimeInfo_GetInterface in our code), then implement the legacy version based on that, so everything is in one place. On Tue, Sep 27, 2011 at 6:34 AM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Hi, > Add missing test file. > > Changelog: > mscoree: Add ICorDebug interface support > > > Best Regards > Alistair Leslie-Hughes > > > > >

1 0

Re: mscoree: Add ICorDebug interface support
by Vincent Povirk 27 Sep '11

27 Sep '11

Why aren't you using CLRRuntimeInfo_GetInterface for this?

1 0

Complaint about mmdevapi (COM?) logging
by Joerg-Cyril.Hoehle＠t-systems.com 27 Sep '11

27 Sep '11

Hi, I'm not satisfied with the current winmm+mmdevapi logging. I suspect that COM logging of other components is similarly bad. Consider the following snippet. It looks like a +relay log, not showing what I want to see. 0022:trace:winmm:waveOutWrite (0xc000, 0x21f140, 32) 0020:trace:winmm:WOD_PushData (0xc000) 0020:trace:alsa:AudioClient_GetBufferSize (0x48f7700)->(0x4b0e9c4) 0020:trace:alsa:AudioClient_GetCurrentPadding (0x48f7700)->(0x4b0e9c8) 0020:trace:alsa:AudioClock_GetFrequency (0x48f7700)->(0x4b0e930) 0020:trace:alsa:AudioClock_GetPosition (0x48f7700)->(0x4b0e928, (nil)) 0020:trace:alsa:AudioClient_GetCurrentPadding (0x48f7700)->(0x4b0e8b4) 0020:trace:alsa:AudioRenderClient_GetBuffer (0x48f7700)->(256, 0x4b0e9c0) 0020:trace:alsa:AudioClient_GetCurrentPadding (0x48f7700)->(0x4b0e938) 0020:trace:alsa:AudioRenderClient_ReleaseBuffer (0x48f7700)->(256, 0) 0020:trace:winmm:WOD_PushData (0xc000) I don't want those %p pointers, I want values. - What's the position? - What's the low-level driver's padding? - What's the mmdevapi padding? - How many samples did waveOutWrite() supply? - Where's any log line from the intermittent mmdevapi periodic timer callback? + The current log is easily compressible :-) The only concrete data is from GetBuffer/ReleaseBuffer: 256 frames, so GetCurrentPadding probably returned GetBuffersize (whose value I derive from the call to Initialize, not shown here) minus 256. The bad news is that you derive more from what you *don't* see in the log than what's written therein. This costs time and effort. E.g. GetBuffer wasn't called means buffer was full -- wait, perhaps there was no more queued data? Help! Why do I believe that logging of other COM dlls may be similarly bad? The anti-pattern is to have a TRACE at function entry! I'd rather move that down a few lines, after basic checking of parameters. At that time you can TRACE some meaningful values instead of pointers. Then you may even decide to put the TRACE at the end of the function, e.g. for GetCurrentPadding that makes a lot of sense, without the added cost of two TRACE lines. Basically, there's little value in an early TRACE because only in rare case will you want to know that the call may have been aborted by E_INVALIDARG or AUDCLNT_E_NOT_INITIALIZED -- not to mention that those return values are almost never logged, not even with +relay. Actually, the useful amount of logging is a function of code maturity. Initially, you're happy with logging every API call. Once you've tested that the basic input checks work exactly like in native, you want to see more from the inside. IOW, initial stubs contain nothing but TRACE. When you fill the function body, it is an error to leave the TRACE at the top, it should move down to the heart of the function where the interesting stuff happens. Regards, Jörg Höhle

2 1

Re: mscoree: Add ICorDebug interface support (try 2)
by Alexandre Julliard 27 Sep '11

27 Sep '11

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > +#include "initguid.h" > +/* We need to undefine the MACRO CreateProcess since the ICorDebug interface > + has a function with this name. (Stops a compile issue). > + */ > +#undef CreateProcess > +#include "cordebug.h" This should go in the header. Check how other idl files are doing it. -- Alexandre Julliard julliard(a)winehq.org

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel