July 2011 - Wine-devel - list.winehq.org

Re: comdlg32/tests: make sure to use a return value (LLVM/Clang)
by Marvin 26 Jul '11

26 Jul '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=12798 Your paranoid android. === W7PROX64 (32 bit itemdlg) === itemdlg: unhandled exception c0000005 at 75B94C19

1 0

I need someone to present at the Desktop summit in my steed (Berlin)
by Scott Ritchie 26 Jul '11

26 Jul '11

External events are preventing me from leaving the country these next few weeks, and I'll be missing the Desktop Summit in Berlin on Monday, Aug 8th. This is the venue to talk to our friends responsible for Freedesktop.org, Gnome, KDE, Unity, and others. https://www.desktopsummit.org/program https://www.desktopsummit.org/venue The stated topic is "Making Wine less broken", although this can be more constructively phrased as "What Wine needs from the Desktop". Many of the recent problems with the Wine user experience have come from desktop environments breaking some of their historical "windows-like way" of doing things while not considering the Wine case: this conference presents us with an opportunity to engage and have Wine handled properly. Any volunteers? I'd be more than willing to talk with you personally and adapt the presentation however you like. Also if you have any particular content that you'd like to make sure gets said, post it in this thread as well :) Thanks, Scott Ritchie

1 0

Re: [PATCH] mmdevapi: Try loading multiple audio drivers from the registry
by Octavian Voicu 25 Jul '11

25 Jul '11

On Tue, Jul 26, 2011 at 12:46 AM, Andrew Eikum <aeikum(a)codeweavers.com> wrote: + for(p = driver_name; p; p = next + 1){ + next = strchrW(p, ','); + if(next) + *next = '\0'; + + if(load_driver(p)) + return TRUE; + + TRACE("Failed to load driver: %s\n", wine_dbgstr_w(driver_name)); + } This crashes if no driver can be loaded (next will be NULL, then you'll have p = NULL + 1). Octavian

1 0

Re: cmd/tests: Add tests for stdout redirection and appending operators
by Marvin 25 Jul '11

25 Jul '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=12796 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [PATCH 1/3] wineoss.drv: Attempt to verify that the system is actually running OSS
by Alexandre Julliard 25 Jul '11

25 Jul '11

Andrew Eikum <aeikum(a)codeweavers.com> writes: > +/* Attempt to determine if we are running on OSS or ALSA's OSS compatability > + * layer. There is no official way to do that, so just check for validity > + * as best as possible, without rejecting valid OSS implementations. */ > +static BOOL verify_actually_oss(void) > +{ > + int mixer_fd; > + oss_sysinfo sysinfo; > + HKEY key; > + > + static const WCHAR drv_key[] = {'S','o','f','t','w','a','r','e','\\', > + 'W','i','n','e','\\','D','r','i','v','e','r','s',0}; > + static const WCHAR drv_value[] = {'A','u','d','i','o',0}; > + static const WCHAR ossW[] = {'O','S','S'}; > + > + /* if the user has specified a driver explicitly, then succeed > + * if they want OSS and fail if they don't */ > + if(RegOpenKeyW(HKEY_CURRENT_USER, drv_key, &key) == ERROR_SUCCESS){ > + WCHAR driver_name[256]; > + DWORD size = sizeof(driver_name); > + > + if(RegQueryValueExW(key, drv_value, 0, NULL, (BYTE*)driver_name, > + &size) == ERROR_SUCCESS){ > + RegCloseKey(key); > + if(!lstrcmpiW(ossW, driver_name)) > + return TRUE; > + return FALSE; > + } > + > + RegCloseKey(key); > + } It's not the driver's business to check the configuration key. If there's really a need to know if some other driver was configured, this info should be passed from the driver loader. But it would be preferable to avoid that. -- Alexandre Julliard julliard(a)winehq.org

2 4

Re: [PATCH 4/4] shell32/tests: Add verification of known folders relative paths.
by Alexandre Julliard 25 Jul '11

25 Jul '11

Mariusz Pluciński <vshader(a)gmail.com> writes: > Checks relative path for each known folder. This one crashes here: ../../../../wine/tools/runtest -q -P wine -M shell32.dll -T ../../.. -p shell32_test.exe.so ../../../../wine/dlls/shell32/tests/shellpath.c && touch shellpath.ok fixme:shell:_SHGetUserProfilePath unsupported for user other than current or default fixme:shell:knownfolder_GetRedirectionCapabilities 0x23f440 fixme:shell:foldermanager_GetFolderByName L"Windows", 0x23f428 wine: Unhandled page fault at address 0x2ae22d17351a (thread 0021), starting debugger... Unhandled exception: page fault in 64-bit code (0x00002ae22d17351a). fixme:dbghelp_dwarf:compute_location Only supporting one breg (r8/336 -> rcx/330) Register dump: rip:00002ae22d17351a rsp:000000000023dd20 rbp:0000000000000000 eflags:00010246 ( R- -- I Z- -P- ) rax:0000ff000000ffff rbx:000000000023f410 rcx:0000000000000018 rdx:0000000000000000 rsi:00000000ffffffff rdi:ff000000ffffff00 r8:00000000000000ff r9:0000000000000007 r10:000000000023d370 r11:0000000000000000 r12:ff000000ffffff00 r13:00002ae22d17b380 r14:0000000000035e92 r15:0000000000010000 Stack dump: 0x000000000023dd20: 000000000023f410 0000000000000000 0x000000000023dd30: 000000000023f408 00002ae22d17b380 0x000000000023dd40: 0000000000035e92 00002ae22d14a5e2 0x000000000023dd50: 000000000003e1f0 00002ae22d17b3a0 0x000000000023dd60: 0000000000000025 00002ae200000001 0x000000000023dd70: 000000000023ec40 0000000000000000 0x000000000023dd80: 0000000000000000 000000000023f408 0x000000000023dd90: 006c006c00000000 0064007200000000 0x000000000023dda0: 0000000000000680 000000680023e400 0x000000000023ddb0: 000000000023ee50 000000000023ec40 0x000000000023ddc0: 000000000023ea30 000000000023e820 0x000000000023ddd0: 000000000023f270 000000000023f400 Backtrace: =>0 0x00002ae22d17351a wine_dbgstr_wn+0x1ca(str=*** invalid address 0xff000000ffffff00 ***, n=0xffffffff) [/home/julliard/wine/build/obj-elf64/dlls/shell32/tests/../../../../wine/include/wine/test.h:471] in shell32_test (0x0000000000000000) 1 0x00002ae22d14a5e2 test_knownFolders+0x1591() [/home/julliard/wine/build/obj-elf64/dlls/shell32/tests/../../../../wine/include/wine/test.h:66] in shell32_test (0x0000000000000000) 2 0x00002ae22d14c80a func_shellpath+0xb09() [/home/julliard/wine/build/obj-elf64/dlls/shell32/tests/../../../../wine/dlls/shell32/tests/shellpath.c:1555] in shell32_test (0x000000000000001a) 3 0x00002ae22d172b47 run_test+0x126(name="../../../../wine/dlls/shell32/tests/shellpath.c") [/home/julliard/wine/build/obj-elf64/dlls/shell32/tests/../../../../wine/include/wine/test.h:556] in shell32_test (0x00002ae22d185df4) 4 0x00002ae22d173676 main+0x115(argc=<is not available>, argv=0x10710) [/home/julliard/wine/build/obj-elf64/dlls/shell32/tests/../../../../wine/include/wine/test.h:624] in shell32_test (0x0000000000010710) 5 0x00002ae22d17387e __wine_spec_exe_entry+0xcd(peb=<is not available>) [/home/julliard/wine/build/obj-elf64/dlls/winecrt0/../../../wine/dlls/winecrt0/exe_entry.c:36] in shell32_test (0x00002ae225108908) 6 0x000000007b87221f start_process+0xbe(peb=0x7fffffbef000) [/home/julliard/wine/build/obj-elf64/dlls/kernel32/../../../wine/dlls/kernel32/process.c:1056] in kernel32 (0x00002ae22d1737b0) 7 0x00002ae225963bab call_thread_func+0x6a(entry=0x7b872160, arg=0x7fffffbef000, frame=0x0(nil)) [/home/julliard/wine/build/obj-elf64/dlls/ntdll/../../../wine/dlls/ntdll/signal_x86_64.c:3189] in ntdll (0x00007fff728e05c0) 8 0x00002ae22595d486 call_thread_entry_point+0x29() in ntdll (0x00007fff728e05c0) 9 0x00002ae22592e766 start_process+0x15(kernel_start=0x23fec8) [/home/julliard/wine/build/obj-elf64/dlls/ntdll/../../../wine/dlls/ntdll/loader.c:2612] in ntdll (0x00007fff728e05c0) 10 0x00002ae224de2223 wine_call_on_stack+0x12() in libwine.so.1 (0x00007fff728e05c0) 11 0x00002ae224de2279 wine_switch_to_stack+0x8(func=<is not available>, arg=<is not available>, stack=<is not available>) [/home/julliard/wine/build/obj-elf64/libs/wine/../../../wine/libs/wine/port.c:59] in libwine.so.1 (0x00007fffffbef000) 12 0x00002ae22593436e LdrInitializeThunk+0x3dd(kernel_start=0x7b872160, unknown2=<is not available>, unknown3=<is not available>, unknown4=<is not available>) [/home/julliard/wine/build/obj-elf64/dlls/ntdll/../../../wine/dlls/ntdll/loader.c:2668] in ntdll (0x00007fffffbef000) 13 0x000000007b878a32 __wine_kernel_init+0x921() [/home/julliard/wine/build/obj-elf64/dlls/kernel32/../../../wine/dlls/kernel32/process.c:1257] in kernel32 (0x00007fff728e1850) 14 0x00002ae225934da4 __wine_process_init+0x253() [/home/julliard/wine/build/obj-elf64/dlls/ntdll/../../../wine/dlls/ntdll/loader.c:2877] in ntdll (0x00007fff728e1a9c) 15 0x00002ae224de01ff wine_init+0x29e(argc=<is not available>, argv=0x7fff728e2028, error="", error_size=0x400) [/home/julliard/wine/build/obj-elf64/libs/wine/../../../wine/libs/wine/loader.c:831] in libwine.so.1 (0x00007fff728e1b30) 16 0x000000007bf00de1 main+0x70(argc=0x3, argv=0x7fff728e2028) [/home/julliard/wine/build/obj-elf64/loader/../../wine/loader/main.c:228] in <wine-loader> (0x0000000000000003) 17 0x00002ae22536bead __libc_start_main+0xfc(main=<is not available>, argc=<is not available>, ubp_av=<is not available>, init=<is not available>, fini=<is not available>, rtld_fini=<is not available>, stack_end=0x7fff728e2018) [/home/aurel32/eglibc/eglibc-2.13/csu/libc-start.c:228] in libc.so.6 (0x0000000000000000) 18 0x000000007bf00ca9 _start+0x28() in <wine-loader> (0x0000000000000000) 0x00002ae22d17351a wine_dbgstr_wn+0x1ca [/home/julliard/wine/build/obj-elf64/dlls/shell32/tests/../../../../wine/include/wine/test.h:471] in shell32_test: cmpw $0,(%rdi) 471 while (*end) end++; -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [3/5] msi: Don't create a temporary copy of the package.
by Alexandre Julliard 25 Jul '11

25 Jul '11

Hans Leidekker <hans(a)codeweavers.com> writes: > There's no need for it now that we open the package in transacted mode. This breaks the Gecko install: fixme:msi:MSI_OpenDatabaseW open failed r = 80030005 for L"Z:\\home\\julliard\\wine\\wine\\..\\gecko\\wine_gecko-1.2.0-x86.msi" err:appwizcpl:install_file MsiInstallProduct failed: 1627 -- Alexandre Julliard julliard(a)winehq.org

1 0

[PATCH 03/10] winmm: Implement waveOut* on top of MMDevAPI
by Joerg-Cyril.Hoehle＠t-systems.com 25 Jul '11

25 Jul '11

Hi, I spent several evenings reviewing the code, here are my findings. The Good + You did it! + outer layer (wave*) uses hwave, inner layer uses device parameter (except WINMM_Pause/Reset which break this separation). + ValidateAndLock pattern + Invoking driver callbacks outside of critical sections, when all slots are in a sane state again. + Removed overhead of pass-through mapper in case of direct format match. However, this may make computations of position and DoneHeaders more complicated. Indeed, I have not yet understood the logic in MarkDoneHeaders and associated queues. Trivia - Some more comments are needed. - Why does WINMM_Pause call IAC_Stop yet set device->stopped = FALSE? - Document that g_device_handles MUST ONLY be modified within the player thread (otherwise MsgWait operates on undefined data), demonstrating that (part of) wave*Open must be handled there. - Express units of entities in WINMM_DEVICE, like you do with last_clock_pos - if(wait == 1 - WAIT_OBJECT_0) should be WAIT_OBJECT_0 + 1 (same by chance) Same with if(wait == g_devhandle_count - WAIT_OBJECT_0) - The caller of WINMM_BeginPlaying supplying the device argument will have locked it already, thus Enter/LeaveCS therein is superfluous. Generally, functions that take a WINMM_Device* parameter should receive it locked by the caller. - Memory leak in WINMM_PrepareHeader in case of acmStreamPrepareHeader error - WOD_Open/WID_Open:cb_info is unused, memcpy(&cb_info,...) useless. Same for WOD/WID_Close - WINMM_OpenDevice passed_fmt HeapAlloc is unchecked Prefer a stack-allocated WAVEFORMATEX and set passed_fmt = &stack_var - Prefer C structure copy over memcpy Logic - I don't see a protection against waveInClose(waveOUThandle); It would be trivial to add a flag to WINMM_GetDeviceFromHWAVE except in WINMM_Pause/Reset. - WINMM_Pause/Reset should take a device pointer, not hwave (which would additionally resolve the above point). - WAVERR_STILLPLAYING is unknown to waveoutClose. It's not a bug, it's a feature? (close would imply stop like the MCI?? but how to unprepare the headers in such a case? IMHO the WINMM API is not designed for a close while playing and only STILLPLAYING makes sense) - nBlockAlign is not sanitized and copied into device->bytes_per_frame. I mentioned long ago tests I wrote that supply incorrect avgbytes and blockalign to winmm yet don't disturb playback in native. IIRC I did not submit them because Wine would not work correctly with them. - device->bytes_per_frame is misdefined and/or misused. It's initialised from the original format (e.g. MP3) but compared in PushData via queue_frames with PCM frames from IAC::GetBuffer. Design - Too bad out_caps.dwSupport is now set within winmm, not the ALSA/OSS/CoreAudio drivers. I loose hope that one day WAVECAPS_VOLUME will be set according to the host OS caps. - How to avoid code duplication among WINMM_MapDevice and msacm32.drv/wavemap.c:wodOpen? - WAVE_FORMAT_DIRECT is missing. It is said to prevent use of ACM (de)compressors. My understanding (untested) is that ACM transforms (e.g. frequency, channels) would still be used. - WINMM_TryDeviceMapping opens the ACM twice, once with ACM_STREAMOPENF_QUERY, then for real. I recommend to open only once, because opening the ACM is an extremely expensive operation, known for delays. All drivers are loaded and queried in turn. I believe this is why people can't seem to Valgrind the winmm/wave and other tests: it just takes sooo much time repeatedly loading and unloading all the drivers! - It may not be a good idea to handle all of wave*Open within the data push thread. Open may take ages, during which no data will be supplied to concurrently playing or recording sounds. Xruns are likely. - Questionable use of BUFFERFLAGS_SILENT in WOD_PushData. When no data is available now, the buffer is flooded with silence, hence data submitted shortly afterwards will be delayed by as much (PulseAudio will accumulate 2 seconds of buffer data...), not by a minimal amount. - The old drivers used ALSA_NearMatch(rate,pcm_rate). There's nothing like this currently in winmm to prevent using a very different rate. My observation is that snd_pcm_set_rate_near() will happily yield 48000 when asked for 8000! Such a variation should be refused by winmm (accepted by dsound?), or a rate converter be silently plugged in. However the code currently ignores ALSA's actual rate and performs all computations using the original one. - Why do you use EVENTCALLBACK? Wine's mmdevapi (currently) signals events periodically from a timer. Winmm could do that itself. - I'm not sure what to think about the observation that waveOutWrite returns an error when BeginPlaying fails yet the header was inserted into the queue. The app may expect the header and data to be reusable for something else because of the error, while Wine may play it from a subsequent BeginPlaying and hit undefined memory. Well, BeginPlaying as of today always returns OK, but the flaw remains. BeginPlaying should be considered a performance optimization hint (start playing fast instead of after the next timer tick) and therefore not need a return value. After enqueuing, NOERROR should be the only return value. - What about mapping some AUDCLNT_E_* to MMSYSERR_*? Regards, Jörg Höhle

2 1

Re: [docs] winedev: Update code columns limit (resend)
by Francois Gouget 25 Jul '11

25 Jul '11

On Mon, 4 Jul 2011, André Hentschel wrote: [...] > - Code is usually limited to 80 columns. This helps prevent > - mailers mangling patches by line wrap. Also it generally > + Code is usually limited to 100 columns. It generally I'd prefer to keep the 80 columns recommandation. With 80 columns one can nicely fit files side by side on a laptop with a typical 1024 horizontal resolution whereas with 100 colums one would end up with the hair comb effect thus making the code unreadable. Also 100 seems close enough to 80 that I'm not sure it actually provides any of the benefits that longer lines are supposed to provide (if they are supposed to provide any). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The nice thing about meditation is that it makes doing nothing quite respectable -- Paul Dean

7 6

Re: po: Use non-breaking spaces where required by the French typography rules.
by Frédéric Delanoy 25 Jul '11

25 Jul '11

2011/7/23 Francois Gouget <fgouget(a)free.fr>: > > Except where they may be sent to a command line terminal. > --- > > I did some tests and non-breaking spaces don't seem to cause any issue > in the GUI. Did you use thin/normal non-breaking spaces? Keep in mind that the space "width" and breakability rules change slightly between e.g. France and French-speaking Canada, and that some (most?) translation tools don't allow you to easily view/enter those characters. TBH I'm not quite sure it's worth the trouble ATM Frédéric

2 2