November 2009 - Wine-Devel - list.winehq.org

Re: To error out or to skip tests?

by Paul Vriens

On 11/09/2009 07:25 PM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Reece, > > I think we reached agreement on: > a) Tests should "usually" succeed. I didn't read that in any of the emails. Tests should always succeed. the broken() and skip() will help in achieving that. >> The point is, if the machine has a broken soundcard (or in Wine does >> not have an available sound driver, or is broken due to PulseAudio on >> Ubuntu), the tests should still pass (or be skipped) as is >> appropriate. > > This seems wrong (in general) to me, even though Paul somehow > expresses an opinion similar to yours. I say you cannot write a > program meant to run in a completely unknown environment, doing > comprehensive tests and not stumbling upon strange behaviour. I'm now busy for example with the eventlog stuff. I create loads of tests and run them on my pretty clean boxes (W95 up to Win7). Only when they pass on all boxes I sent the patches. If test.winehq.org shows failures for these new tests they have to be dealt with. I agree that not everybody has this multitude of test boxes but there are always people around willing to test new tests on their Windows boxes (real and/or virtual). > Regards, > Jörg Höhle. > > -- Cheers, Paul.

Nov. 9, 2009

To error out or to skip tests?

by Joerg-Cyril.Hoehle＠t-systems.com

Reece, I think we reached agreement on: a) Tests should "usually" succeed. b) machines without sound are usual (e.g. in virtual server env.). c) I'll modify the MCI tests to succeed on machines without sound. But for some other points, I've trouble following you. >> The relevant question becomes: when is a configuration unusual? When >> can it be ignored for the purpose of Wine and when is it relevant? >Answer: no configuration is unusual. Huh? >The point is, if the machine has a broken soundcard (or in Wine does >not have an available sound driver, or is broken due to PulseAudio on >Ubuntu), the tests should still pass (or be skipped) as is >appropriate. This seems wrong (in general) to me, even though Paul somehow expresses an opinion similar to yours. I say you cannot write a program meant to run in a completely unknown environment, doing comprehensive tests and not stumbling upon strange behaviour. The program is specifically designed to detect and flag deviant behaviour. All that can be achieved in a program is to be prepared for a known set of scenarios (a broken soundcard is such a scenerio), aka. use-case. Outside these known use-cases, the tests throw an error. Otherwise there's no point in ok() at all. I agree that for the known use-cases (these explicitly include configurations without sound), the tests should succeed. What can be done is what you say: >If we find that other situations need correcting (due to >failing tests), they can be looked at then. ... then decide whether the cause of the failing test is "unusual" or not. I feel that I shall stop discussing that issue. If the consensus is good enough, we need not take this further to eventually discover that the sole disagreement is on the exact meaning of some English words. >It also seems to me that there should be some tests that test opening >an mci stream on a file that we know not to exist (e.g. >this-file-does-not-exist.wav) so that those failure cases can be >properly documented. Good idea, esp. that w95 returns different error codes for foo.wav and bar\foo.wav! >The point I am making is that: > 1. The error and skip statements are saying the same thing; > 2. But the skip message is misleading. Indeed, sorry for that. There's a dependency. The tests depend on record working to generate the file to be played, instead of including one in git. So they fail to test machines that can play but not record. Obviously I'll have to do something else in the yet to be written MIDI tests. BTW, this raises the question whether Wine should include a tiny wave file for completeness. Invoking the MCI Sound command always plays some sound. >If I have counted the offsets correctly 275 is >MCIERR_DEVICE_NOT_READY, *not* that tempfile.wav was not found. Wrong. 275 - 256 is 19, which you look up in mmsystem.h: #define MCIERR_FILE_NOT_FOUND (MCIERR_BASE + 19) > default: > ok(!err, "mciSendString('open') failed, expected NOERROR, got >%s", dbg_mcierr(err)); > } In the default case, if (err) you must return (with or without skip message). You cannot continue if open fails. So it summarizes to: if (err) { /* list of situations that were analysed as "usual": */ ok(err=FILE_NOT_FOUND || err==MCIERR_CANNOT_LOAD_DRIVER || err==xyz ...); skip("Cannot test playback, cause %s",dbg_mcierr(err)); return } > case MCIERR_CANNOT_LOAD_DRIVER: > 2. sound is not present on the system. Perhaps there's a misconception? That's not how MS-Windows systems without sound drivers present themselves. Ge's, Paul's and my father in law's machines all include the MCI (and waveaudio.dll etc.). It's only at WAVE_Open time that failure is detected, e.g. Cue, Record or Play, and the error is MCIERR_WAVE_INPUTSUNSUITABLE for instance. (That's not entirely true, it does not explain the setformat pcm failure). I.e. no mciwave present at all so far is an "unusual" situation, and generates an error. Regards, Jörg Höhle.

Nov. 9, 2009

Re: Question on using winedbg when program does not crash, just becomes unresponsive

by Peter Urbanec

Dan Kegel wrote: > start winedbg without any app > say 'bt all' in winedbg > Voila, you now have backtraces for every process, including the hung one. > It's your job to get that into a text file and remove the uninteresting ones... I've also been trying to debug a multithreaded app. There are at least two complications that winedbg throws up: 1. Is now documented in http://bugs.winehq.org/show_bug.cgi?id=20617 2. As far as I can tell, winedbg will not allow you to switch the current thread context. This means that even though you can get a backtrace of all threads in all processes, you actually can not examine the state of a specific thread. I don't know enough about the internals of wine to go ahead and implement a "thread tid" command. I could manage the code in dbg.y and debug.l to implement the command line interface. When it comes to the actual implementation, I can sort of guess at what may need to be done there. However, I suspect that my naive attempts at an implementation are unlikely to produce an acceptable patch. It can't be as simple as updating the value of dbg_curr_thread with the result of dbg_get_thread(dbg_curr_process, tid) and then calling GetThreadContext(dbg_curr_thread->handle, &dbg_context), can it?

Nov. 9, 2009

Re: Infinite loop with translation DLL

by Uwe Bonnes

>>>>> "Henri" == Henri Verbeet <hverbeet(a)gmail.com> writes: Henri> 2009/11/9 Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de>: >> Can anybody help with the flaw in my implementation? Or did anything >> change in wine? >> Henri> I'm not sure if anything changed there recently, or if that's Henri> even supposed to work, but I suppose that one way to solve the Henri> problem would be to load the linux library dynamically with Henri> wine_dlopen() and explicitly load the entry points with Henri> wine_dlsym(). I wonder how it works in dll/glu32 or what is different in my approach? Marcus: Do you have an example that uses dll/glu32? -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Nov. 9, 2009

Re: Infinite loop with translation DLL

by Henri Verbeet

2009/11/9 Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de>: > Can anybody help with the flaw in my implementation? Or did anything change > in wine? > I'm not sure if anything changed there recently, or if that's even supposed to work, but I suppose that one way to solve the problem would be to load the linux library dynamically with wine_dlopen() and explicitly load the entry points with wine_dlsym().

Nov. 9, 2009

Re: [PATCH 4] mciwave: Rework MCI notification system.

by Vitaliy Margolen

Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Hi, > > + * Notifications in MCI work like a 1-element queue. > + * Each new notification request supersedes the previous one. > + volatile HANDLE hCallback; /* Callback handle for pending notification */ You do not need volatile here as AJ already explained. > + HANDLE old = InterlockedExchangePointer(&wmw->hCallback, NULL); > + if (old) mciDriverNotify(old,wDevID,MCI_NOTIFY_SUPERSEDED); > + mciDriverNotify(HWND_32(LOWORD(hWndCallBack)),wDevID,wStatus); Here and everywhere else in your patches, please add space before commas. > + if (wmw->hFile == 0)<----->return MCIERR_INTERNAL; /* FIXME: Save must work even after Open new. */ > . > - if (dwFlags & MCI_WAIT) > - { > - <->FIXME("MCI_WAIT not implemented\n"); > - } > - WAVE_mciStop(wDevID, 0, NULL); > + WAVE_mciStop(wDevID, MCI_WAIT, NULL); This looks like an unrelated change. Vitaliy.

Nov. 9, 2009

re: Question on using winedbg when program does not crash, just becomes unresponsive

by Dan Kegel

Susan asked: > [What can you do to get a backtrace of a hung app that won't hang when you run it in winedbg?] I ran into this last week and added a note to http://wiki.winehq.org/Backtraces "Alternately, instad of info process / attach, you can do 'bt all' to get backtraces of all threads in all running processes. This is handy when debugging hangs." That's not a very clear explanation, but what it means is: start winedbg without any app say 'bt all' in winedbg Voila, you now have backtraces for every process, including the hung one. It's your job to get that into a text file and remove the uninteresting ones...

Nov. 9, 2009

Re: To error out or to skip tests?

by Reece Dunn

2009/11/9 <Joerg-Cyril.Hoehle(a)t-systems.com>: > Reece Dunn wrote: > >>> The question remains: >>> a) turn sound tests red on machines without sound (with 1 >>error only); >>> b) turn them blue (clearly marking skipped tests) >>> c) turn them green -- status quo (for dsound.ok and wave.ok). > >> 310 ok(!err,"mci open waveaudio!tempfile.wav returned error: %d\n", err); >> 311 if(err) { >> 312 skip("tempfile.wav was not found (not saved), skipping\n"); >>Here, you are doing both (generating an error and skipping)! > > On purpose. I wanted an error flagged to point people's attention to the > issue of machines without sound, so that it can be discussed. What has this to do with the issue of machines without sound. The ok statement is saying that "mci open" has failed (for *any* reason). The skip (activated on *all* error codes) is saying that tempfile.wav is not found, even for cases such as err == MCIERR_CANNOT_LOAD_DRIVER! >>I think that it is safe to say that if there is no audio driver >>present, all subsequent mci tests will fail and should also be skipped >>(ideally with just the single warning, e.g. by returning FALSE from >>that function and wrapping the other tests in an if). > > My current line of thought is that broken and skip are somewhat *bad* > things, because by not performing tests, we don't learn anything about > the behaviour in "unusual" circumstances. The point I am making is that: 1. The error and skip statements are saying the same thing; 2. But the skip message is misleading. That is, it is valid to test MCI in the case when there is no sound device, but the tests are being confused by a lack of tempfile.wav. For example: mci.c:310: Test failed: mci open waveaudio!tempfile.wav returned error: 275 mci.c:312: Tests skipped: tempfile.wav was not found (not saved), skipping If I have counted the offsets correctly 275 is MCIERR_DEVICE_NOT_READY, *not* that tempfile.wav was not found. > The relevant question becomes: when is a configuration unusual? When > can it be ignored for the purpose of Wine and when is it relevant? Answer: no configuration is unusual. > - I don't care that tests fail on my father in law's machine with a > broken sound card (or rather, the card maybe ok, but somehow the > sndblast.dll doen't manager to install it). The point is, if the machine has a broken soundcard (or in Wine does not have an available sound driver, or is broken due to PulseAudio on Ubuntu), the tests should still pass (or be skipped) as is appropriate. > Yet testing on that machine was very revealing (black box testing > with broken configurations tells you a lot about what's inside, like > scientists learn a lot from patients with a local brain disease). Sure. But (a) the tests should still succeed (and doing so, document the behaviour for both these cases) and (b) should succeed or fail *for the right reason*. > - Ge Geldorp pointing out that some vmware engines do not support > sound at all renders Windows without sound not unusual -- unlike > what I initially thought. Sure. > My conclusion is that we need tests to specifically find out how > MS-Windows behaves on such machines, so that Wine can mimick it. > That might be written entirely without skip() or broken(), because > it becomes expected behaviour. But please make sure that they are failing in a way that is expected, It also seems to me that there should be some tests that test opening an mci stream on a file that we know not to exist (e.g. this-file-does-not-exist.wav) so that those failure cases can be properly documented. > if (wave_GetNumDevs()== 0) { > skip("no sound, no tests\n"); return; > is *not* the answer IMHO. Turning all lights green is not a primary > goal, it's a secondary/subordinated one. You have the basic API and parameter tests that can be done. You have the playback tests. And you have the playback tests for non-existent files. In the above example, you have the case of what happens when there are no devices available. Here, I would argue with you that skipping at that point does not make sense. However, skipping at the mciSendString("open ...") when you revieve an MCIERR_CANNOT_LOAD_DRIVER (or whatever the error code is that is returned), *then* you skip (saying "unable to load the mci driver"). > What's the purpose of skip()? Nothing but generate blue colour in > test.winehq (use trace(); return; if all you need is print something > and avoid other tests). What's the purpose of the blue colour? > - A call for action? > + "please run again in the english locale so I can perform locale-dependent tests"; > + "please install sound so that you'll know whether it works on BSD" > + "please install Gecko so I can perform more tests" > - ...? No, skip is saying that the tests cannot be run as the environment does not support the functionality we require. Do you fail the Win9x tests just because they don't support *W API variants? Or Windows environments that don't have DirectX 7, 8, 9 or 10 installed? >>Shouldn't this be something like: >> if(err == MCIERR_INVALID_FILE) { >> skip("tempfile.wav was not found (not saved?), skipping\n"); > No. If any error happens in open, we can't continue. Perhaps you mean > if (err) { > ok(err==MCIERR_FILE_NOT_FOUND, "...\n"); /* the expected situation */ > skip("tempfile.wav was not found (not saved?), skipping\n"); I meant MCIERR_FILE_NOT_FOUND, but the point was not to error in this case. Therefore, something like this: err=mciSendString("open ...."); switch (err) { case MCIERR_FILE_NOT_FOUND: skip("tempfile.wav was not found (not saved?)"); return; case MCIERR_CANNOT_LOAD_DRIVER: case MCIERR_...: skip("unable to open the mci sound driver (%s) - is sound enabled?", dbg_mcierr(err)); return; default: ok(!err, "mciSendString('open') failed, expected NOERROR, got %s", dbg_mcierr(err)); } But then, as you said, any failure here means that you cannot proceed. However, the main cases are: 1. tempfile.wav is not present; 2. sound is not present on the system. The other errors (MCIERR_UNRECOGNISED_COMMAND, MCIERR_HARDWARE, MCIERR_OUT_OF_MEMORY) are either: 1. situations that cannot occur in the given test; 2. are unexpected error cases (i.e. situations that we do not expect on a normal run). Therefore, the above code (with the correct error values) should be sufficient. If we find that other situations need correcting (due to failing tests), they can be looked at then. - Reece

Nov. 9, 2009

Question on using winedbg when program does not crash, just becomes unresponsive

by Susan Cragin

There is some sort of memory leak in Dragon NaturallySpeaking that makes the program become unresponsive (but not crash) after some minutes of using the Dictation Box. I have tried winedbg, SetOnFirstBreak but the program never actually crashes. Without SOFB, of course, winedbg goes for the first unhandled exception, which is harmless. I can't start winedbg right before the program crashes, because I don't know when it will do so. It just sort of wears down. There is nothing I do to make it become unresponsive. Any ideas?

Nov. 9, 2009

Re: To error out or to skip tests?

by Reece Dunn

2009/11/9 <Joerg-Cyril.Hoehle(a)t-systems.com>: > Hi, > > Paul Vriens wrote: >>In my opinion the main purpose for skip() is to not run tests for >>legitimate reasons. > Alas, this sentence and the examples you give do not explain to me why > to use skip instead of e.g. trace + return. What is the added value? > What to do about that blue color or mention in the log file? > > My principle is: do not produce output if there's no consumer. > Refuse to write a memo if nobody is going to read it! > > Why, on w95, should I use skip to mark the impossibility > to call UTF-16 xyzW functions? Why not simply use > if (W_isAvailable) { do_more_tests } > We already have files that end up performing a varying number > of tests, depending on simple if-then-else statements, without use of skip. > > That's different from the localisation example: I could switch the locale, > then re-run the tests. This is again this skip=="call for action" idea > I mentioned previously. > > > BTW, I've sent two patches today to stop errors on machines with sound. The > third one (the localisation issue -- milliseconden, you already know it) > is written but currently at the end of my patch queue. That should bring > the number of errors down to 0 on every machine with sound. > > The final one, about how to deal with machines with no sound, yet trying > to test something instead of skipping everything, I still have to think about. Skipping is a standard way of saying that "we are trying to test functionality A, but the host machine/configuration does not support it." This is not an error (as it is a valid confgiuration/setup on Windows machines), so producing errors only adds to the noise. - Reece

Nov. 9, 2009

To error out or to skip tests?

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Paul Vriens wrote: >In my opinion the main purpose for skip() is to not run tests for >legitimate reasons. Alas, this sentence and the examples you give do not explain to me why to use skip instead of e.g. trace + return. What is the added value? What to do about that blue color or mention in the log file? My principle is: do not produce output if there's no consumer. Refuse to write a memo if nobody is going to read it! Why, on w95, should I use skip to mark the impossibility to call UTF-16 xyzW functions? Why not simply use if (W_isAvailable) { do_more_tests } We already have files that end up performing a varying number of tests, depending on simple if-then-else statements, without use of skip. That's different from the localisation example: I could switch the locale, then re-run the tests. This is again this skip=="call for action" idea I mentioned previously. BTW, I've sent two patches today to stop errors on machines with sound. The third one (the localisation issue -- milliseconden, you already know it) is written but currently at the end of my patch queue. That should bring the number of errors down to 0 on every machine with sound. The final one, about how to deal with machines with no sound, yet trying to test something instead of skipping everything, I still have to think about. Regards, Jörg Höhle

Nov. 9, 2009

Re: To error out or to skip tests?

by Kai Blin

On Friday 06 November 2009 13:21:45 Joerg-Cyril.Hoehle(a)t-systems.com wrote: > The picture on test.winehq.org is a disaster: None of the w95, w98, nt4, > 2k, 2k3, Vista, 2k8, w7 machines have performed winmm:wave tests! > They all have no sound configured. Mostly useless. By extension of your logic, all results from Windows machines < Vista and from most Wine boxes are useless for ws2_32 tests, as they all don't have IPv6 configured so the IPv6 tests skip. To pick up on Nate's idea, I'd request that everybody adds a -ipv4 or -ipv6 suffix to the names of the test reports. Additionally, no single test machine runs as part of a windows AD or even NT4 domain. Thus, a couple of advapi32 tests are skipped, making them worthless. Perhaps people should add a -nodomain suffix to their test report names. If I make all of those tests error out, I'll be drowning real test failures in the noise of configuration issues. I think the same thing applies to your sound tests. Btw, just ask the d3d folks about their woes with (almost) everybody running their windows-based tests on virtual machines, making a lot of the d3d tests useless. Not to mention that there's many people who run hardware with really lousy graphics drivers. Having to skip tests because the system's configuration does not support running them is just something we need to deal with. Kai PS: I was joking about the suffixes. Just to make that clear. I don't want to go having to call my test boxes win2k3-kb-vb-nosound-domain-noadmin-ipv6-ie7- bluebg-classictheme-en_IE-nodotnet -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

Nov. 9, 2009

Re: To error out or to skip tests?

by Paul Vriens

On 11/09/2009 11:27 AM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Reece Dunn wrote: > >>> The question remains: >>> a) turn sound tests red on machines without sound (with 1 >> error only); >>> b) turn them blue (clearly marking skipped tests) >>> c) turn them green -- status quo (for dsound.ok and wave.ok). > >> 310 ok(!err,"mci open waveaudio!tempfile.wav returned error: %d\n", err); >> 311 if(err) { >> 312 skip("tempfile.wav was not found (not saved), skipping\n"); >> Here, you are doing both (generating an error and skipping)! > > On purpose. I wanted an error flagged to point people's attention to the > issue of machines without sound, so that it can be discussed. > >> I think that it is safe to say that if there is no audio driver >> present, all subsequent mci tests will fail and should also be skipped >> (ideally with just the single warning, e.g. by returning FALSE from >> that function and wrapping the other tests in an if). > > My current line of thought is that broken and skip are somewhat *bad* > things, because by not performing tests, we don't learn anything about > the behaviour in "unusual" circumstances. > There are so many variables on systems that these were introduced some time ago. The general feeling is that we try to have succeeding tests on a many boxes as possible. Currently we are already having a hard time achieving that on clean/correct (so we think) boxes. Once the majority of these clean boxes are showing up green we can start thinking of adding tests for broken configurations. You are of course free to have your tests succeed for every possible combination out there, but the key word is 'succeed' here. So if you find that we have test failures for a non-admin user with a Transylvanian locale with no soundcard it still should show up green (with or without the blue borders). > What's the purpose of skip()? Nothing but generate blue colour in > test.winehq (use trace(); return; if all you need is print something > and avoid other tests). What's the purpose of the blue colour? > - A call for action? > + "please run again in the english locale so I can perform locale-dependent tests"; > + "please install sound so that you'll know whether it works on BSD" > + "please install Gecko so I can perform more tests" > - ...? In my opinion the main purpose for skip() is to not run tests for legitimate reasons. If the tests are written so that they can only be run (aka succeed) when a sound card is present you skip() these tests on systems without a soundcard. skip() should not be used to get everything green (the same is in theory true for broken()). A good example of using skip() is when functions are just not available on a platform (like most W-calls on 9x boxes). We also have some tests that will only succeed when the user is an administrator. It's perfectly valid to use skip() if we find the user isn't. Broken() is a little bit different with that respect that we usually mark platforms/boxes as broken() when 99% (or at least the majority) of other configurations succeed these tests. > > Regards, > Jörg Höhle. -- Cheers, Paul.

Nov. 9, 2009

To error out or to skip tests?

by Joerg-Cyril.Hoehle＠t-systems.com

Reece Dunn wrote: >> The question remains: >> a) turn sound tests red on machines without sound (with 1 >error only); >> b) turn them blue (clearly marking skipped tests) >> c) turn them green -- status quo (for dsound.ok and wave.ok). > 310 ok(!err,"mci open waveaudio!tempfile.wav returned error: %d\n", err); > 311 if(err) { > 312 skip("tempfile.wav was not found (not saved), skipping\n"); >Here, you are doing both (generating an error and skipping)! On purpose. I wanted an error flagged to point people's attention to the issue of machines without sound, so that it can be discussed. >I think that it is safe to say that if there is no audio driver >present, all subsequent mci tests will fail and should also be skipped >(ideally with just the single warning, e.g. by returning FALSE from >that function and wrapping the other tests in an if). My current line of thought is that broken and skip are somewhat *bad* things, because by not performing tests, we don't learn anything about the behaviour in "unusual" circumstances. The relevant question becomes: when is a configuration unusual? When can it be ignored for the purpose of Wine and when is it relevant? - I don't care that tests fail on my father in law's machine with a broken sound card (or rather, the card maybe ok, but somehow the sndblast.dll doen't manager to install it). Yet testing on that machine was very revealing (black box testing with broken configurations tells you a lot about what's inside, like scientists learn a lot from patients with a local brain disease). - Ge Geldorp pointing out that some vmware engines do not support sound at all renders Windows without sound not unusual -- unlike what I initially thought. My conclusion is that we need tests to specifically find out how MS-Windows behaves on such machines, so that Wine can mimick it. That might be written entirely without skip() or broken(), because it becomes expected behaviour. if (wave_GetNumDevs()== 0) { skip("no sound, no tests\n"); return; is *not* the answer IMHO. Turning all lights green is not a primary goal, it's a secondary/subordinated one. What's the purpose of skip()? Nothing but generate blue colour in test.winehq (use trace(); return; if all you need is print something and avoid other tests). What's the purpose of the blue colour? - A call for action? + "please run again in the english locale so I can perform locale-dependent tests"; + "please install sound so that you'll know whether it works on BSD" + "please install Gecko so I can perform more tests" - ...? >Shouldn't this be something like: > if(err == MCIERR_INVALID_FILE) { > skip("tempfile.wav was not found (not saved?), skipping\n"); No. If any error happens in open, we can't continue. Perhaps you mean if (err) { ok(err==MCIERR_FILE_NOT_FOUND, "...\n"); /* the expected situation */ skip("tempfile.wav was not found (not saved?), skipping\n"); >a dbg_mcierr function that was created; shouldn't that be used here I didn't retrofit it into all messages after I wrote it. Will do so later. Regards, Jörg Höhle.

Nov. 9, 2009

Infinite loop with translation DLL

by Uwe Bonnes

Hello, around July 2009, I implemented a translation dll, allowing to run Win32 programms using ftd2xx.dll with Wine translating the calls to linux-libftd2xx. It was done while looking at dll/glu32. I was able to run mprog.exe (www.ftdichip.org) some time ago. Reapplying now, I hit an infinite loop with the first translated call. I short, ftd2xx.spec contains: @ stdcall FT_ListDevices(ptr ptr long) FTD2XX_FT_ListDevices and ftd2xx_main.c: extern FT_STATUS FT_ListDevices(PVOID, PVOID, DWORD); FT_STATUS WINAPI FTD2XX_FT_ListDevices( PVOID pArg1, PVOID pArg2, DWORD Flags ) { FT_STATUS res = FT_ListDevices(pArg1, pArg2, Flags); TRACE("res %s\n", res2string(res)); return res; } and dlls/ftd2xx/Makefile.in contains: EXTRALIBS = @FTD2XXLIBS@ with EXTRALIBS detected in configure.ac. MProig.exe calls FT_ListDevices(), which is resolves as FTD2XX_FT_ListDevices(). Then FTD2XX_FT_ListDevices() is entered and FT_ListDevices() resolves again to FTD2XX_FT_ListDevices(), resulting in an infinite loop. Can anybody help with the flaw in my implementation? Or did anything change in wine? The patches still linger on the mailing-list as "Stub implementation for ftd2xx.dll" Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Nov. 9, 2009

re: Remove NoAppDBEntry keyword?

by Dan Kegel

Jerome Leclanche wrote: > Austin English <austinenglish at gmail.com> wrote: >> Anyone opposed to removing that keyword? > > +1 on removing it. > It would be nice to have a bugzilla filter to replace it, too. > > Are we keeping "tasklist" and "tasklet" keywords as well? theres > barely a dozen very old bugs for both of them. I think it'd be fine to remove noappdbentry, tasklist, and tasklet. If there are no objections by next weekend, let's go ahead and do it. - Dan

Nov. 9, 2009

Re: What to do when un-nominating bugs for 1.2

by Vitaliy Margolen

Dan Kegel wrote: > Can we do the same this time, and retarget 1.2 bugs for 1.4 > if they're not going to be fixed for 1.2? At least simple explanation for why bugs were un-nominated from 1.2 would have been great. Half of bugs had no explanation whatsoever. Vitaliy.

Nov. 8, 2009

Re: Another article that makes me want Wine to run in a sandbox

by Gert van den Berg

On Sun, Nov 8, 2009 at 03:55, Dan Kegel <dank(a)kegel.com> wrote: > On Sat, Nov 7, 2009 at 3:40 PM, James McKenzie > <jjmckenzie51(a)earthlink.net> wrote: >> You really underestimate the stupidity of people. > > I expect that people will do utterly stupid things, > there's no two ways around that, it's human nature. > That being the case, I think there are still opportunities > for providing a safe computing experience without > compromising the user's convenience. Convincing packagers to recommend (not sure if anything but clam supports this...) / have clamav as a dependency might help.... (Although it would probably help if Wine uses libclamav to scan all files before running/load even if the clamav daemon is not running and libclam is present...) (No idea what infrastructure that would require, but it sould need a way to turn it of, etc... Also not sure if that is something Wine is supposed to do...) Gert

Nov. 8, 2009

Re: What to do when un-nominating bugs for 1.2

by Dan Kegel

On Sun, Nov 8, 2009 at 8:46 AM, Jeremy White <jwhite(a)codeweavers.com> wrote: > Alexandre expressed a preference that the bugs not be auto rolled to 1.4; > he'd rather we deliberately chose bugs to go into 1.4. So when we > un-nominated, we were intentionally returning bugs to the larger pool. OK. > We were trying an experiment - a bug council to review the bugs. I'm not > sure if it was successful; the bugs have a great richness of information > that is hard to digest and then discuss thoughtfully in a relatively small > (2 hours) period of time. Judging from the bugzilla activity, it looked pretty successful. - Dan

Nov. 8, 2009

Re: What to do when un-nominating bugs for 1.2

by Jeremy White

Hey Dan, Dan Kegel wrote: > In the gcc world, when a bug is targeted for release X > and doesn't make it in time, it is retargeted for release X+1. > > So when 1.0 rolled around, I retargeted the leftover 1.0-targeted > bugs at 1.2. > > Can we do the same this time, and retarget 1.2 bugs for 1.4 > if they're not going to be fixed for 1.2? > Alexandre expressed a preference that the bugs not be auto rolled to 1.4; he'd rather we deliberately chose bugs to go into 1.4. So when we un-nominated, we were intentionally returning bugs to the larger pool. If that proves to have been a mistake (which it may yet), please blame me; I made Austin make each change. We were trying an experiment - a bug council to review the bugs. I'm not sure if it was successful; the bugs have a great richness of information that is hard to digest and then discuss thoughtfully in a relatively small (2 hours) period of time. Cheers, Jeremy

Nov. 8, 2009

Re: Another article that makes me want Wine to run in a sandbox

by David Gerard

2009/11/8 Dan Kegel <dank(a)kegel.com>: > On Sun, Nov 8, 2009 at 3:25 AM, Ben Klein <shacklein(a)gmail.com> wrote: >> I believe the type of sandboxing being discussed includes things like >> preventing Win32 apps from breaking out into native calls using the >> infamous interrupt trick. Correct me if I'm wrong though :) > No, I was thinking of native sandboxing, so even if they did > manage to make native calls, they couldn't do any harm. > Running as another uid is a fine example of a native sandboxing > technique. (So, on a single user system, you could have a > uid dedicated to running sandboxed apps, and it would be > unable to affect the regular user's data.) This would > only be useful for apps that don't need to load or save user data > (probably), for example, for casual games. Yes, Unix comes with pretty good sandboxing built-in in the form of separate user names. Then one could explicity open communication channels between the Unix environment and the Wine user, rather than trying to close off open-everything. Fairly obviously, it'll take some pretty substantial real-world need for this to get anywhere near the winehq tree! But it's an interesting idea. Imagine, successfully securiing Win32 ... - d.

Nov. 8, 2009

What to do when un-nominating bugs for 1.2

by Dan Kegel

In the gcc world, when a bug is targeted for release X and doesn't make it in time, it is retargeted for release X+1. So when 1.0 rolled around, I retargeted the leftover 1.0-targeted bugs at 1.2. Can we do the same this time, and retarget 1.2 bugs for 1.4 if they're not going to be fixed for 1.2? The only time one should simply remove the 1.2 target is if we decide the bug really isn't even a candidate for 1.4 (or was nominated for 1.2 in error).

Nov. 8, 2009

Re: Another article that makes me want Wine to run in a sandbox

by Dan Kegel

On Sun, Nov 8, 2009 at 3:25 AM, Ben Klein <shacklein(a)gmail.com> wrote: > I believe the type of sandboxing being discussed includes things like > preventing Win32 apps from breaking out into native calls using the > infamous interrupt trick. Correct me if I'm wrong though :) No, I was thinking of native sandboxing, so even if they did manage to make native calls, they couldn't do any harm. Running as another uid is a fine example of a native sandboxing technique. (So, on a single user system, you could have a uid dedicated to running sandboxed apps, and it would be unable to affect the regular user's data.) This would only be useful for apps that don't need to load or save user data (probably), for example, for casual games.

Nov. 8, 2009

Re: The user32/win test crashes X on Intel cards

by Francois Gouget

On Sun, 8 Nov 2009, Francois Gouget wrote: [...] > Here's my configuration: > * Intel Corporation Mobile 945GME Express Integrated Graphics Controller rev 3 > * VideoRAM: 256MB (according to /var/log/Xorg.0.log) > * xserver-xorg-video-intel 2:2.9.0-1 > Latest from Debian Testing. > Debian Unstable does not seem to have a more recent driver. More data: * Marcus is running version 2.9.1 of the Intel driver (and gets the crash). * Michael Stefaniuc does not have the problem. He is using FC11's 2.8.0 version of the driver. * I tried Michael's FC11 intel_drv.so file on my system and I still get a crash. I also tried the 2.8.1 Ubuntu driver and got the same result. So the problem comes from some other part of Xorg or the kernel. * Michael is running the 2.6.32 kernel and I'm running the 2.6.30 one. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U

Nov. 8, 2009

Re: The user32/win test crashes X on Intel cards

by Charles Davis

Francois Gouget wrote: > I hit this issue while trying to run winetest for WineConf. I looked > into it and the crash is caused by this line in dlls/user32/tests/win.c: > > SetWindowPos(hwnd, 0, 32768, 40000, 32768, 40000, SWP_NOMOVE); > > More precisely it's the setting of the window width and height to > 32768 x 40000 that causes the crash. Looking at the .xsession-errors > file I see the window manager reporting the following X server error: > > Anomalie dans le gestionnaire de fenêtres : Unexpected X error: BadAlloc > (insufficient resources for operation) serial 11940 error_code 11 > request_code 53 minor_code 0) > > Is it possible that this is just an out of memory issue caused by the > huge window size? According to my tests 32000x32000 (a tad < 3GB) works > but 32767x32767 (a tad >3GB) cause the crash. > > Here's my configuration: > * Intel Corporation Mobile 945GME Express Integrated Graphics Controller rev 3 > * VideoRAM: 256MB (according to /var/log/Xorg.0.log) > * xserver-xorg-video-intel 2:2.9.0-1 > Latest from Debian Testing. > Debian Unstable does not seem to have a more recent driver. > > Marcus got the same issue and he had an Intel card too and we were the > only two with this issue. So apparently this is Intel-specific. > > Does any one have an Intel card where this does not happen? What's your > driver version? > > > > ------------------------------------------------------------------------ > > This happens on Mac OS X, too. Check out http://xquartz.macosforge.org/trac/ticket/293 Chip

Nov. 8, 2009

Re: d3d9: quiet a few very noisy fixme's

by Stefan Dösinger

Am 08.11.2009 um 13:28 schrieb Austin English: > On Sun, Nov 8, 2009 at 6:14 AM, Louis Lenders > <xerox_xerox2000(a)yahoo.co.uk> wrote: >> These are spawned at huge rate in World in Conflict demo >> (http://bugs.winehq.org/show_bug.cgi?id=11114) > > It'd be quicker/cleaner to just change them to warn's instead, IMHO. I think BeginEvent / EndEvent can be changed to TRACE's. They're tools for Microsoft's debugger and profile apps - so the main purpose of them is to help debugging. The shader validator one should probably be a one-time FIXME

Nov. 8, 2009

Re: d3d9: quiet a few very noisy fixme's

by Austin English

On Sun, Nov 8, 2009 at 6:14 AM, Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > These are spawned at huge rate in World in Conflict demo > (http://bugs.winehq.org/show_bug.cgi?id=11114) It'd be quicker/cleaner to just change them to warn's instead, IMHO. -- -Austin

Nov. 8, 2009

Re: Another article that makes me want Wine to run in a sandbox

by Ben Klein

2009/11/8 David Gerard <dgerard(a)gmail.com>: > You'd get good sandboxing running Wine apps as another user. Main > problem then is integration with the user's desktop. Doable, but a > nuisance. Not really. A separate Wine user wouldn't prevent people from running Wine as root incorrectly, and if you integrate it with the normal user's home directory, it's no longer sandboxed (or at least, no more than separated wineprefixes). I believe the type of sandboxing being discussed includes things like preventing Win32 apps from breaking out into native calls using the infamous interrupt trick. Correct me if I'm wrong though :)

Nov. 8, 2009

The user32/win test crashes X on Intel cards

by Francois Gouget

I hit this issue while trying to run winetest for WineConf. I looked into it and the crash is caused by this line in dlls/user32/tests/win.c: SetWindowPos(hwnd, 0, 32768, 40000, 32768, 40000, SWP_NOMOVE); More precisely it's the setting of the window width and height to 32768 x 40000 that causes the crash. Looking at the .xsession-errors file I see the window manager reporting the following X server error: Anomalie dans le gestionnaire de fenêtres : Unexpected X error: BadAlloc (insufficient resources for operation) serial 11940 error_code 11 request_code 53 minor_code 0) Is it possible that this is just an out of memory issue caused by the huge window size? According to my tests 32000x32000 (a tad < 3GB) works but 32767x32767 (a tad >3GB) cause the crash. Here's my configuration: * Intel Corporation Mobile 945GME Express Integrated Graphics Controller rev 3 * VideoRAM: 256MB (according to /var/log/Xorg.0.log) * xserver-xorg-video-intel 2:2.9.0-1 Latest from Debian Testing. Debian Unstable does not seem to have a more recent driver. Marcus got the same issue and he had an Intel card too and we were the only two with this issue. So apparently this is Intel-specific. Does any one have an Intel card where this does not happen? What's your driver version? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U

Nov. 8, 2009

Re: Another article that makes me want Wine to run in a sandbox

by David Gerard

2009/11/8 Dan Kegel <dank(a)kegel.com>: > I expect that people will do utterly stupid things, > there's no two ways around that, it's human nature. > That being the case, I think there are still opportunities > for providing a safe computing experience without > compromising the user's convenience. > Case in point: the sandbox used by the Chromium web > browser. It provides a modicum of security without > getting in the way. I can easily imagine classes > of windows apps, say, games, fitting nicely into a > sandboxed wine environment. Sure, getting the > networking right would be a challenge, but for at > least casual games, it ought to be quite doable. > The key is to require no user choices -- just do the > right thing by default. Then the user's level of education > or computer skills don't matter. You'd get good sandboxing running Wine apps as another user. Main problem then is integration with the user's desktop. Doable, but a nuisance. - d.

Nov. 8, 2009

Re: [PATCH] rpcrt4: compare networkoptions correctly (Coverity) (adjusted)

by Rob Shearman

2009/11/8 Marcus Meissner <meissner(a)suse.de>: > @@ -84,6 +84,17 @@ static RPC_STATUS RpcAssoc_Alloc(LPCSTR Protseq, LPCSTR NetworkAddr, > return RPC_S_OK; > } > > +static BOOL compare_networkoptions(LPCWSTR opts1, LPCWSTR opts2) > +{ > + if ((opts1 == NULL) && (opts2 == NULL)) > + return TRUE; > + if ((opts1 == NULL) && (opts2 != NULL)) > + return FALSE; > + if ((opts1 != NULL) && (opts2 == NULL)) > + return FALSE; > + return !strcmpW(opts1, opts2); > +} > + > RPC_STATUS RPCRT4_GetAssociation(LPCSTR Protseq, LPCSTR NetworkAddr, > LPCSTR Endpoint, LPCWSTR NetworkOptions, > RpcAssoc **assoc_out) > @@ -97,8 +108,8 @@ RPC_STATUS RPCRT4_GetAssociation(LPCSTR Protseq, LPCSTR NetworkAddr, > if (!strcmp(Protseq, assoc->Protseq) && > !strcmp(NetworkAddr, assoc->NetworkAddr) && > !strcmp(Endpoint, assoc->Endpoint) && > - ((!assoc->NetworkOptions && !NetworkOptions) || !strcmpW(NetworkOptions, assoc->NetworkOptions))) > - { > + compare_networkoptions(NetworkOptions, assoc->NetworkOptions) > + ) { Looks good functionally, but please don't change the style. > assoc->refs++; > *assoc_out = assoc; > LeaveCriticalSection(&assoc_list_cs); Thanks, -- Rob Shearman

Nov. 8, 2009

Re: winex11.drv: Implement FIXME in AlphaBlend

by Peter Urbanec

I've taken the following feedback on board and resubmitted the patch. Andrew Eikum wrote: > This is less important, but you're not following the code conventions > of the surrounding code. The surrounding code does not have spaces > around function parameters, so yours shouldn't either. The existing code uses a mixture of styles in the AlphaBlend function alone. My original patch did not have spaces around function parameters, however it did have spaces after C language keywords. The resubmitted patch follows the style of the code immediately before and after the patch, which does not have spaces after keywords. Roderick Colenbrander wrote: > I didn't see this patch before because I was away at that time. The > SourceConstantAlpha part looks correct to me. It might make sense to > calculate blendfn.SourceConstantAlpha / 255 before the loop, so that > it isn't recalculated each time. I considered this, but because the alpha is calculated using integer arithmetic on BYTE values, a pre-calculated blend factor would always degenerate to the value 0. The alternative is to use floating point arithmetic for the blend factor calculation, but that would most likely end up being a performance killer. Hopefully the compiler will do a reasonable optimising job if it is possible to improve the code. I guess the code could be hand optimised to use of a vectorised instruction set where available. However, I think that at this point providing a concise and readable implementation is probably a more valuable contribution. > The other half of your patch is a separate change and it would require > a separate patch. The part looks suspicious though. I don't understand > why you need special locking there. Yes, the locking code is not related to the missing AlphaBlend functionality. It got rolled into the patch because I was fixing some other issues at the same time. I have a heavily multithreaded application and without that locking code I end up with areas of the screen that are not updated correctly. To be honest, I don't have a very clear picture of how the various locking mechanisms interact, so it is feasible that the locking code I added does not address the underlying problem, but only fixes the symptom as a side effect. I'd be happy to learn more about the interaction between X11, OpenGL and wine synchronisation mechanisms - any pointers where to look for explanations? Best regards, Peter Urbanec

Nov. 8, 2009

Re: Owen Rudge : comctl32: Add support for scrolling during marquee selection.

by Nikolay Sivov

On Wed, Nov 4, 2009 at 10:26 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Module: wine > Branch: master > Commit: e1f3edef3e491095dd73548b711bddf14ee73ef0 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=e1f3edef3e491095dd73548b7… > > Author: Owen Rudge <orudge(a)codeweavers.com> > Date: Mon Nov 2 10:58:26 2009 -0600 > > comctl32: Add support for scrolling during marquee selection. > > --- Hi, Owen. I've tested this a bit and it flickers like hell in some cases. Looks like list requests redraw even if selection doesn't change (pointer is still over already selected item). Other things: - selection logic is wrong when some items are already selected before marquee. On native it deselects those items, your code leave them as is. This is visible in regedit (report mode listview) - select first entry and start selection -> first item remains selected. - sometimes I get corrupted focus rectangle - moving pointer down causes bottom side to clear, rectangle contains three side after that (it could be a problem for my virtual box of course, or some embedded video drivers, but I don't see a problem moving up for example).

Nov. 8, 2009

Re: Another article that makes me want Wine to run in a sandbox

by Ben Klein

2009/11/8 Dan Kegel <dank(a)kegel.com>: > The key is to require no user choices -- just do the > right thing by default. Then the user's level of education > or computer skills don't matter. E.g., convince distros to give Wine SOCKET_RAW access using file capabilities by default?

Nov. 8, 2009

Re: Another article that makes me want Wine to run in a sandbox

by Dan Kegel

On Sat, Nov 7, 2009 at 3:40 PM, James McKenzie <jjmckenzie51(a)earthlink.net> wrote: > You really underestimate the stupidity of people. I expect that people will do utterly stupid things, there's no two ways around that, it's human nature. That being the case, I think there are still opportunities for providing a safe computing experience without compromising the user's convenience. Case in point: the sandbox used by the Chromium web browser. It provides a modicum of security without getting in the way. I can easily imagine classes of windows apps, say, games, fitting nicely into a sandboxed wine environment. Sure, getting the networking right would be a challenge, but for at least casual games, it ought to be quite doable. The key is to require no user choices -- just do the right thing by default. Then the user's level of education or computer skills don't matter. - Dan

Nov. 8, 2009

Re: Another article that makes me want Wine to run in a sandbox

by James McKenzie

Dan Kegel wrote: > http://www.linuxinsider.com/rsstory/68566.html > > The article is about users who are willing to > follow bogus instructions to solve a problem > (or install something). > > It makes me want the average desktop to be > really, really locked down... and for user-installed > apps to run in a sandbox so they can't break the > rest of the system. > > I am looking forward to hear what the discussion at > http://sandboxing.org comes up with. > Dan: You really underestimate the stupidity of people. This was pointed out in the article with detail. Folks will always try to get warez to run and they will think that Linux is 'safe' until the first time they wipe out their system by running Wine as root and then installing the warez and it does its thing. This is something that WE cannot and should not control (this is a reversal of my previous statements on running Wine as root, but folks continue to do so and we cannot really stop them from doing so.) However, adding the sandbox idea is what Java was based upon. It continues to fail to fully meet this requirement as Java still continues to need to have physical access to devices on the hosting machine. This is not a shortcoming of Java, but a shortcoming of device emulation for real-time or near-real-time processing. James McKenzie

Nov. 7, 2009

Cpp Check Nov. 7th

by chris ahrendt

Well its been a few since I ran CPP Check and so I ran it today and got the following: New CPP Check Errors for the Wine Code: [/home/cahrendt/wine-git/dlls/comctl32/imagelist.c:1908]: (error) Uninitialized variable: bmi_buf [/home/cahrendt/wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd [/home/cahrendt/wine-git/dlls/ntdll/server.c:882]: (error) Resource leak: fd_cwd [/home/cahrendt/wine-git/dlls/shell32/shellord.c:416]: (error) Uninitialized variable: szText [/home/cahrendt/wine-git/dlls/shell32/shellord.c:416]: (error) Uninitialized variable: szTitle [/home/cahrendt/wine-git/dlls/shell32/shellpath.c:1360]: (error) Uninitialized variable: InfoBuffer [/home/cahrendt/wine-git/dlls/winex11.drv/xfont.c:2963]: (possible error) Resource leak: fd [/home/cahrendt/wine-git/server/mapping.c:118]: (error) Uninitialized variable: page_size Chris

Nov. 7, 2009

Re: (retry) msctf/tests: handle an occassional unexpected SetFocus from wine

by Nicolas Le Cam

2009/11/7 Aric Stewart <aric(a)codeweavers.com>: > --- > dlls/msctf/tests/inputprocessor.c | 7 +++++-- > 1 files changed, 5 insertions(+), 2 deletions(-) > Here are the results for 100 consecutive runs : $ for i in {1..100}; do wine msctf_test.exe.so >> msctf_tests.log 2>&1; done $ grep "tests executed" msctf_tests.log | sort | uniq -c | sort -nr 77 inputprocessor: 230 tests executed (0 marked as todo, 0 failures), 0 skipped. 18 inputprocessor: 231 tests executed (0 marked as todo, 3 failures), 0 skipped. 3 inputprocessor: 234 tests executed (0 marked as todo, 4 failures), 0 skipped. 1 inputprocessor: 238 tests executed (0 marked as todo, 8 failures), 0 skipped. 1 inputprocessor: 236 tests executed (0 marked as todo, 6 failures), 0 skipped. I also did try to sleep between tests in case it could help but it doesn't seem so : $ for i in {1..100}; do wine msctf_test.exe.so >> msctf_tests.log 2>&1; sleep 1; done $ grep "tests executed" msctf_tests.log | sort | uniq -c | sort -nr 78 inputprocessor: 230 tests executed (0 marked as todo, 0 failures), 0 skipped. 17 inputprocessor: 231 tests executed (0 marked as todo, 3 failures), 0 skipped. 3 inputprocessor: 238 tests executed (0 marked as todo, 8 failures), 0 skipped. 2 inputprocessor: 236 tests executed (0 marked as todo, 6 failures), 0 skipped. For info, here is a run without your patch. $ for i in {1..100}; do wine msctf_test.exe.so >> msctf_tests.log 2>&1; sleep 1; done $ grep "tests executed" msctf_tests.log | sort | uniq -c | sort -nr 64 inputprocessor: 230 tests executed (0 marked as todo, 0 failures), 0 skipped. 18 inputprocessor: 236 tests executed (0 marked as todo, 4 failures), 0 skipped. 12 inputprocessor: 237 tests executed (0 marked as todo, 7 failures), 0 skipped. 3 inputprocessor: 234 tests executed (0 marked as todo, 4 failures), 0 skipped. 2 inputprocessor: 236 tests executed (0 marked as todo, 6 failures), 0 skipped. 1 inputprocessor: 238 tests executed (0 marked as todo, 8 failures), 0 skipped. If you need me to do more tests, just ask, I'm willing to go green ;) -- Nicolas Le Cam

Nov. 7, 2009

Re: [PATCH] rpcrt4: Fixed incorrect NULL check condition (Coverity)

by Rob Shearman

2009/10/17 Marcus Meissner <marcus(a)jet.franken.de>: > Hi, > > Coverity spotted that this could lead to NULL dereference, > and yes, the && should be ||. This is not what was intended. The code inside the if block shouldn't execute if assoc->NetworkOptions is NULL and NetworkOptions isn't and vice-versa. The comparison should probably be split into a separate function. > @@ -97,7 +97,7 @@ RPC_STATUS RPCRT4_GetAssociation(LPCSTR Protseq, LPCSTR NetworkAddr, > if (!strcmp(Protseq, assoc->Protseq) && > !strcmp(NetworkAddr, assoc->NetworkAddr) && > !strcmp(Endpoint, assoc->Endpoint) && > - ((!assoc->NetworkOptions && !NetworkOptions) || !strcmpW(NetworkOptions, assoc->NetworkOptions))) > + (!assoc->NetworkOptions || !NetworkOptions || !strcmpW(NetworkOptions, assoc->NetworkOptions))) Thanks, -- Rob Shearman

Nov. 7, 2009

Re: libsmbclient and wine?

by Rob Shearman

2009/10/23 Dan Kegel <dank(a)kegel.com>: > Hi folks, > it's often been said that wine can't use libsmbclient because > of license problems. I'd like to look at that assumption a bit. > > - What would wine like to use libsmbclient for, if it could? > > - Would it suffice to just link it in to wineserver, or would > it need to be invoked directly by all sorts of dlls? > > - Would we just use the system's libsmbclient (I hope so) > rather than trying to import its source? > > Also, fwiw, I think the Samba guys are willing to multiplex > their listening daemon so Wine could handle incoming > named pipe requests if we want to. libsmbclient would need to be linked into wineserver to properly implement handles to named pipes that can be inherited by child processes (and to be allow the handle to be accepted by all of the functions that take a handle without large modifications). However, having 3rd party code linked into the wineserver probably gives many people the heebie-jeebies, given how critical the wineserver is to allowing wine processes to continue to run and the special rules of coding in the wineserver - not blocking, for one. -- Rob Shearman

Nov. 7, 2009

Re: msctf/tests: handle an occassional unexpected SetFocus from wine

by Aric Stewart

Please disregard this. I was testing the wrong version on my winvista machine and this causes a failure. revised version coming. -aric Aric Stewart wrote: > --- > dlls/msctf/tests/inputprocessor.c | 5 ++++- > 1 files changed, 4 insertions(+), 1 deletions(-) > > > > ------------------------------------------------------------------------ > >

Nov. 7, 2009

Re: msctf/tests: handle an occassional unexpected SetFocus from wine

by Nicolas Le Cam

2009/11/7 Aric Stewart <aric(a)codeweavers.com>: > --- > dlls/msctf/tests/inputprocessor.c | 5 ++++- > 1 files changed, 4 insertions(+), 1 deletions(-) > > > > > > Aric, is this for my versatile machine ? -- Nicolas Le Cam

Nov. 7, 2009

Re: [CHANGE] Patch: regional settings update & translation

by Stefan Leichter

Am Friday 06 November 2009 21:49:26 schrieb lejcik: > Signed-off-by: lejcik <lejcik(a)host.sk> > --- > dlls/kernel32/nls/csy.nls | 38 +++++++++++++++++++------------------- > dlls/kernel32/nls/sky.nls | 42 > +++++++++++++++++++++--------------------- > 2 files changed, 40 insertions(+), 40 deletions(-) To get a patch accepted, you need the send it with your real name. Bye Stefan

Nov. 7, 2009

Another article that makes me want Wine to run in a sandbox

by Dan Kegel

http://www.linuxinsider.com/rsstory/68566.html The article is about users who are willing to follow bogus instructions to solve a problem (or install something). It makes me want the average desktop to be really, really locked down... and for user-installed apps to run in a sandbox so they can't break the rest of the system. I am looking forward to hear what the discussion at http://sandboxing.org comes up with.

Nov. 6, 2009

Re: To error out or to skip tests?

by Reece Dunn

2009/11/6 <Joerg-Cyril.Hoehle(a)t-systems.com>: > Ge, > >> to be honest I'm a bit put off by your aggressive tone. > Please accept my apologies. It was not meant to be agressive. > I was certainly disappointed by having submitted tests that > I knew worked on 3 real machines: w95, w2k, xp, then turn to > test.winehq and see everything red. > > BTW, dsound is also affected: both dsound and winmm have had little > testing coverage despite the appealing green color. > >>I'm simply not interested in sound > Please weight providing as much test data as possible to the Wine > project against your lack of interest in sound issues. > BTW, the default sound tests make no noise. > >>Anyway, the end result is that there will always be ESX VMs >>that can't run sound tests. > Note taken. > > The question remains: > a) turn sound tests red on machines without sound (with 1 error only); > b) turn them blue (clearly marking skipped tests) > c) turn them green -- status quo (for dsound.ok and wave.ok). 309 err = mciSendString("open waveaudio!tempfile.wav alias mysound", buf, sizeof(buf), NULL); 310 ok(!err,"mci open waveaudio!tempfile.wav returned error: %d\n", err); 311 if(err) { 312 skip("tempfile.wav was not found (not saved), skipping\n"); 313 return; 314 } Here, you are doing both (generating an error and skipping)! Also, how do you know that this is due to tempfile.wav being missing (the skip is invoked for any error case)? Especially given the line: mci.c:261: Tests skipped: Please install audio driver. Tests will fail in the test results. Shouldn't this be something like: err = mciSendString("open waveaudio!tempfile.wav alias mysound", buf, sizeof(buf), NULL); if(err == MCIERR_INVALID_FILE) { skip("tempfile.wav was not found (not saved?), skipping\n"); return; } ok(!err,"mci open waveaudio!tempfile.wav returned error: %d\n", dbg_mcierr(err)); I think that it is safe to say that if there is no audio driver present, all subsequent mci tests will fail and should also be skipped (ideally with just the single warning, e.g. by returning FALSE from that function and wrapping the other tests in an if). 27 static const char* dbg_mcierr(MCIERROR err) ... 108 default: return "unknown error"; This is not really helpful, it should contain the error number. mci.c:239: Test failed: mci set format tag pcm returned error: 282 This (and the other error numbers) does not mean much to me. There is a dbg_mcierr function that was created; shouldn't that be used here (as the error is returned from mciSendString)? - Reece

Nov. 6, 2009

Re: To error out or to skip tests?

by Juan Lang

Hi Joerg, > BTW, dsound is also affected: both dsound and winmm have had little > testing coverage despite the appealing green color. Your concern about coverage is valid one. > Please weight providing as much test data as possible to the Wine > project against your lack of interest in sound issues. I'm with Ge on this one: I don't much care whether Wine is able to play sound. I care in an abstract sense, but not more than I'd like to see green tests ;-) Is that silly or misguided of me? Perhaps. On the other hand, I think there's real value in stating that "the tests should pass on all Windows boxes," even if their configuration is invalid or strange. We're not there yet, but any failing test impedes that goal. To put it another way: when the test failures seem intractable, it's hard to get motivated to fix them. For example, if there are some tests no one understands, or that fail on systems few people run, or if the number of test failures is simply too large, it's hard to get motivated to chip away at the issues. Fortunately we have a few cheerleaders like Paul who get us motivated to work on them every now and again. On the other hand, when there are few test failures, there can be a little incentive to see whether a few days' effort will produce passing tests on at least one file, in order to see it magically become green. There has been for me, at least. So, to answer your question: > a) turn sound tests red on machines without sound (with 1 error only); > b) turn them blue (clearly marking skipped tests) > c) turn them green -- status quo (for dsound.ok and wave.ok). I'm in favor of either b or c, though I lean toward c. The reason is, not all tests can run on all systems. For example, you mentioned you saw a failure on a Win95 box with a broken sound card. If the sound card is broken, and other test results are invalid, surely a skip is appropriate here? That is, this doesn't indicate an error in the tests, and skip is appropriate. Green vs. red tells you at a glance what the pass rate is, though it doesn't say anything about the skip rate. I think what you're asking for is a separate metric for coverage and pass rate. I'm in favor of that. --Juan

Nov. 6, 2009

Re: To error out or to skip tests?

by Joerg-Cyril.Hoehle＠t-systems.com

Ge, > to be honest I'm a bit put off by your aggressive tone. Please accept my apologies. It was not meant to be agressive. I was certainly disappointed by having submitted tests that I knew worked on 3 real machines: w95, w2k, xp, then turn to test.winehq and see everything red. BTW, dsound is also affected: both dsound and winmm have had little testing coverage despite the appealing green color. >I'm simply not interested in sound Please weight providing as much test data as possible to the Wine project against your lack of interest in sound issues. BTW, the default sound tests make no noise. >Anyway, the end result is that there will always be ESX VMs >that can't run sound tests. Note taken. The question remains: a) turn sound tests red on machines without sound (with 1 error only); b) turn them blue (clearly marking skipped tests) c) turn them green -- status quo (for dsound.ok and wave.ok). Regards, Jörg Höhle.

Nov. 6, 2009

Re: To error out or to skip tests?

by Nate Gallaher

It sounds to me like the root problem is not that tests were being skipped, but that developers didn't know that the test machines had no sound configured. Perhaps simply adding -nosound to the testbed names would clear up the issue? Then developers interested in sound can look for testbed machines that don't have that tag and that don't skip their tests? Taking it to the next level I think would involve some sort of "expected configuration" file, setup for each test machine, which you feed to the test framework. The framework then flags particular skipped tests as errors for that expected configuration. Then someone would have to maintain this and make sure there's adequate coverage. This seems like a lot of work, and potentially a lot of spaghetti, which makes me think #1 is the better option for now. Regards, ~Nate Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Hi, > > I apologize for the numerous occurrances of red color on test.winehq > due to my new winmm MCI tests. That was not expected. > > However, turning something green is not a goal in itself. For some > time now I wanted to query wine-devel about this topic, independently > of my patches, so here it goes. > > An analysis reveals that my tests implement a detector of > vmware (virtualbox etc.) default installs, i.e. MS-Windows > systems that have not been configured with sound. > > No real user's machines would be like that > (except for a w95 box I tried with a broken soundcard). > > The revealing line is > >> Tests skipped: Please install audio driver. Tests will fail (18 errors) >> > This goes hand in hand with "5 tests, 0 errors, 1 skip" in winmm:wave. > Exactly those systems skipping the wave tests produce 18-19 MCI errors. > > Failure to flag an error in such cases has known drawbacks: > - For several month, Austin did not notice that his BSD boxes had lost > sound. wave.ok simply reports "5 tests ok, 1 skipped" in joyfull > green, whereas it executed many tests half a year ago. > > - All those vmware boxes configured without sound and thus skipping > all but 5 wave.ok tests have for monthes *not* provided valuable > feedback to Wine. So they were actually *not* executing tests, when > they could have. > It's only when Paul tested one of my tests that he realized that > sound was not configured on one of his vmware boxes, promptly > configured the sound device, and the tests passed. > > The picture on test.winehq.org is a disaster: None of the w95, w98, nt4, > 2k, 2k3, Vista, 2k8, w7 machines have performed winmm:wave tests! > They all have no sound configured. Mostly useless. > > Therefore, I believe it's sometimes better to flag an error than to > calmly skip something. > > Last year already, submitting the ICCVID patches, I was thinking: > "iccvid.dll may not part of every installation, but we want feedback > so we should compare behaviour with MS-Windows systems equipped with > that library and ask people to install it if not present". > Likewise, Wine should compare with systems similarly equipped: d3d8, > d3d9, dplay, dmusic etc. > > Perhaps an easy change on test.winehq would be to augment the blue > color indicator of skipped tests to the full rectangle surface instead > of the current green? > > Of course, I'll change my tests to flag a single error on systems > without sound. -- Or no error at all, if that's wine-devel consensus. > > What do you think? > Jörg Höhle. > There's only few real MCI test errors I saw on test.winehq: the system > "fg_winxp-ie8" that yields 1 error instead of 18: > mci.c:391: Test failed: not enough time elapsed 80ms -- a flakey test. > And on the ME systems: > mci.c:603: Test failed: mci re-auto-open status mode returned error: 275 > mci.c:612: Test failed: mci auto-open pause returned error: 275 > Luckily, there are a few machines that pass all tests. > > >

Nov. 6, 2009

Re: To error out or to skip tests?

by Greg Geldorp

Hi Jörg > Failure to flag an error in such cases has known drawbacks: > - For several month, Austin did not notice that his BSD boxes had lost > sound. wave.ok simply reports "5 tests ok, 1 skipped" in joyfull > green, whereas it executed many tests half a year ago. > > - All those vmware boxes configured without sound and thus skipping > all but 5 wave.ok tests have for monthes *not* provided valuable > feedback to Wine. So they were actually *not* executing tests, when > they could have. > It's only when Paul tested one of my tests that he realized that > sound was not configured on one of his vmware boxes, promptly > configured the sound device, and the tests passed. > > The picture on test.winehq.org is a disaster: None of the w95, w98, nt4, > 2k, 2k3, Vista, 2k8, w7 machines have performed winmm:wave tests! > They all have no sound configured. Mostly useless. A lot of those VMware boxes are mine. They come in two flavors. Some of them (starting with esx-) are ESX VMs, ESX is VMware's data center product, which simply doesn't support sound. The others (starting with gvg-) are Server VMs, which do support sound. The reason I didn't configure sound on them is because I'm simply not interested in sound. I'll consider enabling sound, but to be honest I'm a bit put off by your aggressive tone. Anyway, the end result is that there will always be ESX VMs that can't run sound tests. Best regards, Ge.

Nov. 6, 2009

Re: To error out or to skip tests?

by Henri Verbeet

The D3D tests have similar issues with VMs, but if it's a valid configuration we can't let the test fail (in general).

Nov. 6, 2009