Re: [PATCH 2/4] kernel32, ntdll, server: implement permission checks for named pipes
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=12777 Your paranoid android. === WNT4WSSP6 (32 bit pipe) === Timeout
Re: [PATCH 3/4] ntdll: implement the NamedPipeConfiguration value for the FilePipeLocalInformation class of NtQueryInformati
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=12778 Your paranoid android. === WNT4WSSP6 (32 bit pipe) === Timeout
Re: [PATCH 1/4] server, ntdll: get rid of the blocking parameter for ioctls. blockingness depends on the overlapped flag for
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=12776 Your paranoid android. === WNT4WSSP6 (32 bit pipe) === Timeout
Re: cmd: mkdir should complain if directory already exists
On Sun, Jul 24, 2011 at 20:58, Dan Kegel d...@kegel.com wrote:
Fixes bug 27383.
There's trailing whitespace on the line preceding if
(!create_full_path(param1)) {
Seems ok otherwise
Re: Statur of DIB Engine
On Sun, Jul 24, 2011 at 07:10:46PM +0300, Octavian Voicu wrote: Disclaimer: these comments are based only on what I gather from following commits and looking at the code, so can't guarantee it's 100% accurate; Huw or Alexandre would know better. This is a good summary of where we're at - nicely done Octavian. The next step is cross-device blitting, which is what Alexandre and I are working on at the moment. Huw.
Re: po: Use non-breaking spaces where required by the French typography rules.
On Sun, 24 Jul 2011, Frédéric Delanoy wrote: [...] Did you use thin/normal non-breaking spaces? I used regular 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. Just for information, what are the differences? -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.
Re: Statur of DIB Engine
Il 25/07/2011 10:20, Huw Davies ha scritto: On Sun, Jul 24, 2011 at 07:10:46PM +0300, Octavian Voicu wrote: Disclaimer: these comments are based only on what I gather from following commits and looking at the code, so can't guarantee it's 100% accurate; Huw or Alexandre would know better. This is a good summary of where we're at - nicely done Octavian. The next step is cross-device blitting, which is what Alexandre and I are working on at the moment. Huw. Indeed that one was the big problem of my engine, impossible to do efficently without support from underlying drivers (winex11). Is font support for DIBS foreseen in short time ? Max
Re: [docs] winedev: Update code columns limit (resend)
André Hentschel wrote: Am 24.07.2011 00:02, schrieb Francois Gouget: 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). I see your point, but looking at the code it's already quite often around 100 and AJ also stated that 100 is more or less the actual limit. Otherwise i wouldn't have sent the patch. Yepp, 100 is the preferred line length for Wine for over a year now. Personally I would have gone for 120 but Alexandre said that 100 is enough. So all my janitorial patches since then have cleaned up the line length to 100 en passant. bye michael
[PATCH 03/10] winmm: Implement waveOut* on top of MMDevAPI
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
Re: [PATCH 1/3] wineoss.drv: Attempt to verify that the system is actually running OSS
On 07/24/2011 06:56 PM, Vitaliy Margolen wrote: On 07/22/2011 08:35 AM, Andrew Eikum wrote: This is really crude, but does seem to work. I tested it correct with just ALSA 1.0.24; ALSA 1.0.24's snd-pcm-oss and snd-pcm-mixer modules; and on OSS4.2. It was also tested by Gerald Pfeifer on FreeBSD 8.2 and 9.0. This lets us attempt to load the OSS driver, and if that fails, then try the ALSA driver. Automatic driver selection! You forgetting, that users can select multiple drivers in winecfg now. And that's what some people have in their registry. They can, but it's non-functional by design in MMDevAPI. winecfg even says, Selecting multiple drivers is not recommended. The actual approach is seems fishy to me as well. The reason ALSA driver is 1st is because most systems has it as the main sound subsystem. Putting something [oss] first in the list, and failing if it wasn't explicitly asked for defeats the whole idea about something being default, and having alternate fallback(s). With same logic one would add all other sound drivers and make them fail, unless explicitly asked for. I don't really understand. Maybe you're misunderstanding the logic in verify_actually_oss(). The registry entry check only occurs if the user has a driver specified in the registry. If there is no driver in the registry, as in a clean prefix, then the rest of the check will be run. The idea is that if the user specifically requests OSS in the registry, then we should not fail to load the OSS driver, even if the oss_sysinfo struct looks wrong. The problem is that there is no way to ask the question What audio system is currently being used?, so we have to come up with some other way to make a selection. Between OSS and ALSA, this was the most reliable method I could find. ALSA's OSS compatability doesn't properly fill the oss_sysinfo struct. If that struct looks wrong, then we fail to load the driver and fall back on the next one, ALSA. We could certainly have done it the other way around: try to load ALSA unless we detect that ALSA isn't actually in use, and then fall back on OSS. But there is no reliable way to differentiate between true ALSA, and OSS's ALSA compatability. Andrew
Re: po: Use non-breaking spaces where required by the French typography rules.
2011/7/25 Francois Gouget fgou...@free.fr: On Sun, 24 Jul 2011, Frédéric Delanoy wrote: [...] Did you use thin/normal non-breaking spaces? I used regular 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. Just for information, what are the differences? I didn't find the exact page, but you can check the following: - http://traduc.org/gnomefr/Typographie - http://66.46.185.79/bdl/gabarit_bdl.asp?Al=1id=2039D=Espacement%20avant%20et%20apr%E8s%20les%20signes%20de%20ponctuation traduc mailing list archive may have some additional info on this. Frédéric
Re: [docs] winedev: Update code columns limit (resend)
On 07/23/2011 07:05 PM, James McKenzie wrote: On 7/23/11 3:33 PM, Andrew Eikum wrote: On 07/23/2011 05:02 PM, Francois Gouget wrote: 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. +1 I have never seen a terminal emulator that defaults to anything other than 80 columns. This limit exists because of the old Hollerith cards. You can set the width of your terminal session to whatever you want as a default. James The size of a Hollerith card is based on the size of a dollar bill at the time the standard was set. Dollars have shrunk in more than one sense since that time... Much more to the point is the number of characters that can fit on a (more or less) standard piece of paper. US standard paper is 8 1/2 inches wide and typewriter pitch was something like 10 characters per inch; with no margins, you get an 85 character line. Throw in 1/4 inch margins and you are down to 80. Similar calculations for A4 yield similar numbers. Other standard widths exist. 120 and 132 column formats have their traditional supporters. 72 columns is the usual text width on punched cards with 8 columns reserved for a sequence number field. (If you have ever dropped a 2000+ card program or data deck, you become a strong believer in sequence numbers!) So much for history. My personal preference is for an 80 column standard. That is large enough to allow a reasonable number of 4 column tab stops, and I can get two pages up on a good screen with some slack for scroll bars, boarders and other useful decorations. Wider and conflicts arise with the less expensive kinds of equipment. I've lived with the 80 column for more then 3 decades. It chafes a little at times, but ANY standard will irritate. Max 0112233445566778 123456789012345678901234567890123456789012345678901234567890
Re: [PATCH 1/3] wineoss.drv: Attempt to verify that the system is actually running OSS
Andrew Eikum aei...@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
julli...@winehq.org
Re: [PATCH 1/3] wineoss.drv: Attempt to verify that the system is actually running OSS
On 07/25/2011 09:09 AM, Alexandre Julliard wrote: 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. I see your point. The idea was to give the user an override, in case the OSS detection isn't smart enough and refuses to load a legitimate implementation. If the user explicitly tells us to use OSS, then I think the heuristics in DllMain should be ignored; nothing in there is critical to our OSS driver. MMDevAPI could pass some explicit flag to the driver, but DllMain doesn't take arguments (right?). It looks like we'd have to put the explicit flag into GetEndpointIDs and change MMDevAPI to check that function during driver load time, or create a new Initialize() entry point. Do you prefer either of those options? Should I just go back to the drawing board on the whole idea? Andrew
Re: [PATCH 03/10] winmm: Implement waveOut* on top of MMDevAPI
On 07/25/2011 06:52 AM, joerg-cyril.hoe...@t-systems.com wrote: I spent several evenings reviewing the code, here are my findings. Thanks! Lots of good comments here. I've made notes about your suggestions to come back to later. Some specific responses follow... - Some more comments are needed. - Why does WINMM_Pause call IAC_Stop yet set device-stopped = FALSE? You're right, the usage of stopped is confused. I need to examine it more closely and figure out what it was intended to do. - Express units of entities in WINMM_DEVICE, like you do with last_clock_pos Hmm, I think they all have units. bytes_per_frame is in bytes, samples_per_sec is in samples, ofs_bytes is in bytes, played_frames is in frames (although samples vs frames is a bit ambiguous). :) - 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 All little things worth fixing. Patches welcome, if you would like the credit. - 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) I just wrote a quick little test, and it looks like you're right. It does also let you close a device without unpreparing all of the headers. - 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. You're right. It's treated as if all data is PCM, which it shouldn't. - 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! Good idea. - 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. Theoretically possible, but probably not worth the effort unless we find an app which actually does a lot of opening and closing. - 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. Are you sure? BUFFERFLAGS_SILENT shouldn't silence the whole buffer, just insert avail_frames worth of silence, which is what was intended. We should only accumulate 2 seconds if there is a 2 second underrun from WinMM's client. That seems like sane behavior to me. - Why do you use EVENTCALLBACK? Wine's mmdevapi (currently) signals events periodically from a timer. Winmm could do that itself. I guess. I don't really see the benefit. Callback mode is easier to work with, I think, since we know the driver is ready for data. Andrew
Re: [3/5] msi: Don't create a temporary copy of the package.
Hans Leidekker h...@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 LZ:\\home\\julliard\\wine\\wine\\..\\gecko\\wine_gecko-1.2.0-x86.msi err:appwizcpl:install_file MsiInstallProduct failed: 1627 -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 4/4] shell32/tests: Add verification of known folders relative paths.
Mariusz Pluciński vsha...@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 LWindows, 0x23f428 wine: Unhandled page fault at address 0x2ae22d17351a (thread 0021), starting debugger... Unhandled exception: page fault in 64-bit code (0x2ae22d17351a). fixme:dbghelp_dwarf:compute_location Only supporting one breg (r8/336 - rcx/330) Register dump: rip:2ae22d17351a rsp:0023dd20 rbp: eflags:00010246 ( R- -- I Z- -P- ) rax:ff00 rbx:0023f410 rcx:0018 rdx: rsi: rdi:ff00ff00 r8:00ff r9:0007 r10:0023d370 r11: r12:ff00ff00 r13:2ae22d17b380 r14:00035e92 r15:0001 Stack dump: 0x0023dd20: 0023f410 0x0023dd30: 0023f408 2ae22d17b380 0x0023dd40: 00035e92 2ae22d14a5e2 0x0023dd50: 0003e1f0 2ae22d17b3a0 0x0023dd60: 0025 2ae20001 0x0023dd70: 0023ec40 0x0023dd80: 0023f408 0x0023dd90: 006c006c 00640072 0x0023dda0: 0680 00680023e400 0x0023ddb0: 0023ee50 0023ec40 0x0023ddc0: 0023ea30 0023e820 0x0023ddd0: 0023f270 0023f400 Backtrace: =0 0x2ae22d17351a wine_dbgstr_wn+0x1ca(str=*** invalid address 0xff00ff00 ***, n=0x) [/home/julliard/wine/build/obj-elf64/dlls/shell32/tests/../../../../wine/include/wine/test.h:471] in shell32_test (0x) 1 0x2ae22d14a5e2 test_knownFolders+0x1591() [/home/julliard/wine/build/obj-elf64/dlls/shell32/tests/../../../../wine/include/wine/test.h:66] in shell32_test (0x) 2 0x2ae22d14c80a func_shellpath+0xb09() [/home/julliard/wine/build/obj-elf64/dlls/shell32/tests/../../../../wine/dlls/shell32/tests/shellpath.c:1555] in shell32_test (0x001a) 3 0x2ae22d172b47 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 (0x2ae22d185df4) 4 0x2ae22d173676 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 (0x00010710) 5 0x2ae22d17387e __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 (0x2ae225108908) 6 0x7b87221f start_process+0xbe(peb=0x7fbef000) [/home/julliard/wine/build/obj-elf64/dlls/kernel32/../../../wine/dlls/kernel32/process.c:1056] in kernel32 (0x2ae22d1737b0) 7 0x2ae225963bab call_thread_func+0x6a(entry=0x7b872160, arg=0x7fbef000, frame=0x0(nil)) [/home/julliard/wine/build/obj-elf64/dlls/ntdll/../../../wine/dlls/ntdll/signal_x86_64.c:3189] in ntdll (0x7fff728e05c0) 8 0x2ae22595d486 call_thread_entry_point+0x29() in ntdll (0x7fff728e05c0) 9 0x2ae22592e766 start_process+0x15(kernel_start=0x23fec8) [/home/julliard/wine/build/obj-elf64/dlls/ntdll/../../../wine/dlls/ntdll/loader.c:2612] in ntdll (0x7fff728e05c0) 10 0x2ae224de2223 wine_call_on_stack+0x12() in libwine.so.1 (0x7fff728e05c0) 11 0x2ae224de2279 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 (0x7fbef000) 12 0x2ae22593436e 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 (0x7fbef000) 13 0x7b878a32 __wine_kernel_init+0x921() [/home/julliard/wine/build/obj-elf64/dlls/kernel32/../../../wine/dlls/kernel32/process.c:1257] in kernel32 (0x7fff728e1850) 14 0x2ae225934da4 __wine_process_init+0x253() [/home/julliard/wine/build/obj-elf64/dlls/ntdll/../../../wine/dlls/ntdll/loader.c:2877] in ntdll (0x7fff728e1a9c) 15 0x2ae224de01ff 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 (0x7fff728e1b30) 16
Wine Gecko 1.3-beta1
Hi all,
I've just uploaded a new Wine Gecko beta package. It's a bit earlier
than we usually updated the package, but it's part of the plan. The last
release was the most successful ever - we've successfully avoided
regressions and fixed existing bugs. The fact that we had long (over
month) beta period and that the release was made based on stable Firefox
release helped a lot IMO. We can improve stability of Gecko package by
releasing more often, meaning less changes are included in each single
release. We can do this thanks to Mozilla rapid release cycles, that
gives us a chance to release Wine Gecko based on the very recent code
base, stabilized by Mozilla every six weeks. Six weeks releases are,
however, more than we can handle and more than we need, so my current
plan is to release every two Firerox version (that is every 12 weeks),
with no pressure.
Back to current release, it's mostly an update of code base to keep on
track with Gecko changes. Builds are available, as usually, on
sourceforge [1]. To test it, you also need the attached patch to Wine.
Any help with testing is appreciated. Everything that uses MSHTML in any
way is worth testing.
Informations for packages interested in building the package themselves:
My builds are done with GCC 4.5.3, but any GCC newer than 4.5.1 should
be good. There was a fix to Mozilla code needed for GCC 4.6.* builds
that I've included in the source, so GCC 4.6 32-bit builds should be
fine. If you want to use it for 64-bit builds, please test it carefully
as I wasn't able to test them (linking GCC 4.6 builds consumes awfully
lot of memory, so it failed for me).
Cheers,
Jacek
[1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/1.3-beta1/
diff --git a/dlls/appwiz.cpl/addons.c b/dlls/appwiz.cpl/addons.c
index dbfd3b9..ab1f7b1 100644
--- a/dlls/appwiz.cpl/addons.c
+++ b/dlls/appwiz.cpl/addons.c
@@ -51,7 +51,7 @@
WINE_DEFAULT_DEBUG_CHANNEL(appwizcpl);
-#define GECKO_VERSION 1.2.0
+#define GECKO_VERSION 1.3-beta1
#ifdef __i386__
#define ARCH_STRING x86
diff --git a/dlls/mshtml/htmlbody.c b/dlls/mshtml/htmlbody.c
index 8789200..cbc9abf 100644
--- a/dlls/mshtml/htmlbody.c
+++ b/dlls/mshtml/htmlbody.c
@@ -660,7 +660,6 @@ static HRESULT WINAPI
HTMLBodyElement_get_onbeforeunload(IHTMLBodyElement *iface
static HRESULT WINAPI HTMLBodyElement_createTextRange(IHTMLBodyElement *iface,
IHTMLTxtRange **range)
{
HTMLBodyElement *This = impl_from_IHTMLBodyElement(iface);
-nsIDOMDocumentRange *nsdocrange;
nsIDOMRange *nsrange = NULL;
nsresult nsres;
HRESULT hres;
@@ -672,14 +671,7 @@ static HRESULT WINAPI
HTMLBodyElement_createTextRange(IHTMLBodyElement *iface, I
return E_UNEXPECTED;
}
-nsres =
nsIDOMDocument_QueryInterface(This-textcont.element.node.doc-nsdoc,
IID_nsIDOMDocumentRange,
-(void**)nsdocrange);
-if(NS_FAILED(nsres)) {
-ERR(Could not get nsIDOMDocumentRabge iface: %08x\n, nsres);
-return E_FAIL;
-}
-
-nsres = nsIDOMDocumentRange_CreateRange(nsdocrange, nsrange);
+nsres =
nsIDOMHTMLDocument_CreateRange(This-textcont.element.node.doc-nsdoc,
nsrange);
if(NS_SUCCEEDED(nsres)) {
nsres = nsIDOMRange_SelectNodeContents(nsrange,
This-textcont.element.node.nsnode);
if(NS_FAILED(nsres))
@@ -688,8 +680,6 @@ static HRESULT WINAPI
HTMLBodyElement_createTextRange(IHTMLBodyElement *iface, I
ERR(CreateRange failed: %08x\n, nsres);
}
-nsIDOMDocumentRange_Release(nsdocrange);
-
hres =
HTMLTxtRange_Create(This-textcont.element.node.doc-basedoc.doc_node, nsrange,
range);
nsIDOMRange_Release(nsrange);
diff --git a/dlls/mshtml/htmlcurstyle.c b/dlls/mshtml/htmlcurstyle.c
index a4a7163..8bd1f16 100644
--- a/dlls/mshtml/htmlcurstyle.c
+++ b/dlls/mshtml/htmlcurstyle.c
@@ -892,9 +892,7 @@ static dispex_static_data_t HTMLCurrentStyle_dispex = {
HRESULT HTMLCurrentStyle_Create(HTMLElement *elem, IHTMLCurrentStyle **p)
{
nsIDOMCSSStyleDeclaration *nsstyle;
-nsIDOMDocumentView *nsdocview;
-nsIDOMAbstractView *nsview;
-nsIDOMViewCSS *nsviewcss;
+nsIDOMWindow *nsview;
nsAString nsempty_str;
HTMLCurrentStyle *ret;
nsresult nsres;
@@ -904,29 +902,14 @@ HRESULT HTMLCurrentStyle_Create(HTMLElement *elem,
IHTMLCurrentStyle **p)
return E_UNEXPECTED;
}
-nsres = nsIDOMHTMLDocument_QueryInterface(elem-node.doc-nsdoc,
IID_nsIDOMDocumentView, (void**)nsdocview);
-if(NS_FAILED(nsres)) {
-ERR(Could not get nsIDOMDocumentView: %08x\n, nsres);
-return E_FAIL;
-}
-
-nsres = nsIDOMDocumentView_GetDefaultView(nsdocview, nsview);
-nsIDOMDocumentView_Release(nsdocview);
+nsres = nsIDOMHTMLDocument_GetDefaultView(elem-node.doc-nsdoc, nsview);
if(NS_FAILED(nsres)) {
ERR(GetDefaultView failed: %08x\n, nsres);
return E_FAIL;
}
-nsres = nsIDOMAbstractView_QueryInterface(nsview, IID_nsIDOMViewCSS,
(void**)nsviewcss);
-
Re: [PATCH 1/3] wineoss.drv: Attempt to verify that the system is actually running OSS
Andrew Eikum aei...@codeweavers.com writes: On 07/25/2011 09:09 AM, Alexandre Julliard wrote: 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. I see your point. The idea was to give the user an override, in case the OSS detection isn't smart enough and refuses to load a legitimate implementation. If the user explicitly tells us to use OSS, then I think the heuristics in DllMain should be ignored; nothing in there is critical to our OSS driver. MMDevAPI could pass some explicit flag to the driver, but DllMain doesn't take arguments (right?). It looks like we'd have to put the explicit flag into GetEndpointIDs and change MMDevAPI to check that function during driver load time, or create a new Initialize() entry point. Do you prefer either of those options? Should I just go back to the drawing board on the whole idea? I guess we could have some sort of priority mechanism, where the driver can returns its priority, and the loader tries them all and keeps the highest one. We also probably need a way to have only mmdevapi handle loading so that winmm doesn't need to duplicate the search strategy. Though the mmdevapi side will need to be fixed to support the correct registry syntax. -- Alexandre Julliard julli...@winehq.org
Questions on WINE releases and stability
Hi, I am a developer for a product which makes heavy use of WINE. Right now, we're deciding which newer version of WINE to go to, and I thought the wine-devel community might have some insight. I did read the WineReleaseCriteria entry on the wiki, but still have some questions. If anyone could answer some things that I've been wondering about, it would go a long way towards helping us make an informed decision. So, here goes: - Does the development branch of WINE go through a battery of tests before it is posted? What kind of criteria has to be met before a development release is made available on the main page? - It's my understanding that the stable branch only has select features and patches ported over (from the wiki: ..with only minimal changes merged in). Would this mean that if I compared a stable release with a development release from around the same time that the two releases would have significant differences? Specifically, I'm wondering about 1.2.3 vs. 1.3.15. - Is 64-bit support in version 1.2.3 generally usable and stable, or is the current development release a lot more mature in that respect? Your expertise would be appreciated! Louis
Re: Questions on WINE releases and stability
On Mon, Jul 25, 2011 at 6:54 PM, lo...@museresearch.com wrote: - It's my understanding that the stable branch only has select features and patches ported over (from the wiki: ..with only minimal changes merged in). Would this mean that if I compared a stable release with a development release from around the same time that the two releases would have significant differences? Specifically, I'm wondering about 1.2.3 vs. 1.3.15. Development releases of wine tend to be a *lot* more mature in every aspect than their stable counterparts. Minor stable releases get a few hundred either important or easily-rebased patches each ported over from the development releases. It slightly helps keeping them up to date. The goal of stable releases is to have as few regressions as possible. Keep in mind, for a piece of software like Wine, it doesn't make as much sense. 99% of Wine's development goes into implementing missing APIs or API details. Almost all of the time, this causes relevant broken apps to work better. Stable releases are more of a bureaucracy issue. Wine was without stable releases for some 15-ish years and was doing just fine, but FWIU it annoyed many distributions. In general, if you don't want regressions, pick a recent development release that works for you and stick to it. 64-bit support is certainly better in 1.3.25 (current dev release), but that doesn't necessarily mean the bits of 64-bit support you need are not already in 1.2.3. If you have testcases for your program, run them under Wine and see which one fares best. Added bonus is you can upgrade every few development releases and run the testcases again to see if there are regressions (and if there are, please do report them on http://bugs.winehq.org). -- J. Leclanche
Re: [PATCH 1/3] wineoss.drv: Attempt to verify that the system is actually running OSS
On 07/25/2011 12:33 PM, Alexandre Julliard wrote: Andrew Eikumaei...@codeweavers.com writes: On 07/25/2011 09:09 AM, Alexandre Julliard wrote: 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. I see your point. The idea was to give the user an override, in case the OSS detection isn't smart enough and refuses to load a legitimate implementation. If the user explicitly tells us to use OSS, then I think the heuristics in DllMain should be ignored; nothing in there is critical to our OSS driver. MMDevAPI could pass some explicit flag to the driver, but DllMain doesn't take arguments (right?). It looks like we'd have to put the explicit flag into GetEndpointIDs and change MMDevAPI to check that function during driver load time, or create a new Initialize() entry point. Do you prefer either of those options? Should I just go back to the drawing board on the whole idea? I guess we could have some sort of priority mechanism, where the driver can returns its priority, and the loader tries them all and keeps the highest one. Mm, don't see much of a difference between this and an ordered list in the code like we are using now. This also doesn't solve the original problem of a broken OSS continuing to fail to load even if the user explicitly requests OSS in the registry. We also probably need a way to have only mmdevapi handle loading so that winmm doesn't need to duplicate the search strategy. Though the mmdevapi side will need to be fixed to support the correct registry syntax. Yes, that would be nice. What do you mean correct registry syntax? Do you mean listing multiple drivers? I don't see any reason to support that. Andrew
Re: [PATCH 1/3] wineoss.drv: Attempt to verify that the system is actually running OSS
Andrew Eikum aei...@codeweavers.com writes: Mm, don't see much of a difference between this and an ordered list in the code like we are using now. This also doesn't solve the original problem of a broken OSS continuing to fail to load even if the user explicitly requests OSS in the registry. The difference is that the priority would be determined dynamically, so the OSS driver would return a low priority if it detects ALSA emulation. We also probably need a way to have only mmdevapi handle loading so that winmm doesn't need to duplicate the search strategy. Though the mmdevapi side will need to be fixed to support the correct registry syntax. Yes, that would be nice. What do you mean correct registry syntax? Do you mean listing multiple drivers? I don't see any reason to support that. Yes, multiple drivers. That's necessary to make configurations portable. -- Alexandre Julliard julli...@winehq.org
Re: Questions on WINE releases and stability
On Monday 25 July 2011 19:54:00 lo...@museresearch.com wrote: - Does the development branch of WINE go through a battery of tests before it is posted? What kind of criteria has to be met before a development release is made available on the main page? Every git revision has to pass the wine test cases(make test) on Alexandre's machine. That's the main criterion for patches to go in. There are no additional criteria for the development releases I know of. The development releases are just snapshots released every two weeks. As far as I know the only thing that's special about them is a git tag and a short release note. signature.asc Description: This is a digitally signed message part.
Re: [PATCH] mmdevapi: Try loading multiple audio drivers from the registry
On Tue, Jul 26, 2011 at 12:46 AM, Andrew Eikum aei...@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
Re: cmd/tests: Add tests for stdout redirection and appending operators
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
I need someone to present at the Desktop summit in my steed (Berlin)
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
Re: Updated Clang static analysis results / Valgrind update
On Sat, Jul 2, 2011 at 19:15, Austin English austinengl...@gmail.com wrote: Web space usage was getting a bit high, so I've uploaded a tarball to a file download service: http://www.sendspace.com/file/5hot36 austin@aw21 ~ $ sha1sum scan-build-2011-07-02.tar.bz2 ac3cb3920ef97641fff1f5376f8136cef01f15bf scan-build-2011-07-02.tar.bz2 to use, just extract and open in your favorite browser: $ firefox index.html this was run against Clang from svn: clang version 3.0 (trunk 134320) Please send me any false positives that you'd like me to report upstream. Cheers, Austin P.S. For those of you wanting Valgrind results, I'm currently hitting a nasty Valgrind bug, waiting on upstream to fix: https://bugs.kde.org/show_bug.cgi?id=275673 (Thanks to Andrew N for finding the faulty commit) Updated clang results, with: clang version 3.0 (trunk 135936) and wine-1.3.25-52-g9d7d37f are at http://www.sendspace.com/file/x81pne 77f1b2d0fdd8cb79d4caf20279b36dc047fcc325 scan-build-2011-07-25.tar.xz This gives 1815 warnings (previously had 1857). Again, if you see any false positives, please let me know so that I can report them upstream. For valgrind, see http://austinenglish.com/logs/valgrind/2011-07-25-10.19 I've disabled a few tests, to workaround valgrind bug 275673. See http://code.google.com/p/winezeug/source/diff?spec=svn2431r=2431format=sidepath=/trunk/valgrind/valgrind-daily.sh I've got some more interesting stuff in the works, time permitting. Keep tuned ;-). Cheers, Austin
Re: comdlg32/tests: make sure to use a return value (LLVM/Clang)
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 c005 at 75B94C19
d3d8/tests: make sure to use return values (LLVM/Clang)
-- -Austin diff --git a/dlls/d3d8/tests/device.c b/dlls/d3d8/tests/device.c index 9a4369b..d159a52 100644 --- a/dlls/d3d8/tests/device.c +++ b/dlls/d3d8/tests/device.c @@ -1050,6 +1050,7 @@ static void test_reset(void) hr = IDirect3DDevice8_GetRenderTarget(device1, surface); ok(SUCCEEDED(hr), GetRenderTarget failed, hr %#x.\n, hr); hr = IDirect3DSurface8_GetDesc(surface, surface_desc); +ok(SUCCEEDED(hr), GetDesc failed, hr %#x.\n, hr); ok(surface_desc.Width == modes[i].w, Back buffer width is %u, expected %u.\n, surface_desc.Width, modes[i].w); ok(surface_desc.Height == modes[i].h, Back buffer height is %u, expected %u.\n, @@ -1088,6 +1089,7 @@ static void test_reset(void) hr = IDirect3DDevice8_GetRenderTarget(device1, surface); ok(SUCCEEDED(hr), GetRenderTarget failed, hr %#x.\n, hr); hr = IDirect3DSurface8_GetDesc(surface, surface_desc); +ok(SUCCEEDED(hr), GetDesc failed, hr %#x.\n, hr); ok(surface_desc.Width == 400, Back buffer width is %u, expected 400.\n, surface_desc.Width); ok(surface_desc.Height == 300, Back buffer height is %u, expected 300.\n, @@ -2600,15 +2602,18 @@ static void test_depth_stencil_size(void) ok(SUCCEEDED(hr), IDirect3DDevice8_SetRenderTarget failed, hr %#x.\n, hr); hr = IDirect3DDevice8_GetRenderTarget(device, surf); +ok(SUCCEEDED(hr), IDirect3DDevice8_GetRenderTarget failed, hr %#x.\n, hr); ok(surf == rt, The render target is %p, expected %p\n, surf, rt); IDirect3DSurface8_Release(surf); hr = IDirect3DDevice8_GetDepthStencilSurface(device, surf); +ok(SUCCEEDED(hr), IDirect3DDevice8_GetDepthStencilSurface failed, hr %#x.\n, hr); ok(surf == ds_bigger2, The depth stencil is %p, expected %p\n, surf, ds_bigger2); IDirect3DSurface8_Release(surf); hr = IDirect3DDevice8_SetRenderTarget(device, NULL, NULL); ok(SUCCEEDED(hr), IDirect3DDevice8_SetRenderTarget failed, hr %#x.\n, hr); hr = IDirect3DDevice8_GetDepthStencilSurface(device, surf); +ok(FAILED(hr), IDirect3DDevice8_GetDepthStencilSurface failed, hr %#x.\n, hr); ok(surf == NULL, The depth stencil is %p, expected NULL\n, surf); if (surf) IDirect3DSurface8_Release(surf);
Re: Questions on WINE releases and stability
On 07/25/2011 11:54 AM, lo...@museresearch.com wrote: - Does the development branch of WINE go through a battery of tests before it is posted? What kind of criteria has to be met before a development release is made available on the main page? Each applied patch have to compile and pass all conformance tests at least on Alexandre's PC. If even a single test fails, patch won't be applied. Alexandre usually picking most dramatic changes at the beginning of each release cycle for development version (2 weeks). Gradually lowering scale of changes towards the release date (every other Friday). - It's my understanding that the stable branch only has select features and patches ported over (from the wiki: ..with only minimal changes merged in). Would this mean that if I compared a stable release with a development release from around the same time that the two releases would have significant differences? Specifically, I'm wondering about 1.2.3 vs. 1.3.15. The Wine development version wine-1.1.44 eventually became Wine-1.2 release. The goal of the release was to stabilize Wine (no new features where accepted for a long time, only bug fixes). And to fix number of major bugs targeted for wine-1.2 (see bugzilla for details). Wine-1.2.x are minor releases with few major show-stopper bug fixes back-ported from the development tree. Wine-1.2.1 also has number of translation additions and fixes. As well as some minor usability improvements to winecfg. - Is 64-bit support in version 1.2.3 generally usable and stable, or is No, it's not suitable for general use. It was one of the main targets for wine-1.2 release but had lots of issues for more complex applications. the current development release a lot more mature in that respect? Yes. Current development version should be able to run majority of simple 64-bit applications. And some big 64-bit applications with some issues. Vitaliy.
Re: [PATCH 2/4] kernel32, ntdll, server: implement permission checks for named pipes
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=12804 Your paranoid android. === W7PROX64 (64 bit pipe) === No test summary line found
Re: [PATCH 1/4] server, ntdll: get rid of the blocking parameter for ioctls. blockingness depends on the overlapped flag for
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=12803 Your paranoid android. === W7PROX64 (64 bit pipe) === No test summary line found
Re: [PATCH 3/4] ntdll: implement the NamedPipeConfiguration value for the FilePipeLocalInformation class of NtQueryInformati
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=12805 Your paranoid android. === W7PROX64 (64 bit pipe) === No test summary line found
