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. 8, 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. 7, 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. 7, 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. 7, 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. 7, 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

Re: Link to Test Runs

by Nate Gallaher

Tests can be found at test.winehq.org Mike wrote: > Ok, I found this once before but I can't find it again. Where is the link to the test runs for different platforms, etc. I wanted to see if my tests passed Win 95. > > Sorry for asking questions that should probably be obvious, but we all start ignorant and some of us more ignorant and naive than others. > > Thanks, > Mikey > > > > > >

Nov. 6, 2009

Link to Test Runs

by Mike

Ok, I found this once before but I can't find it again. Where is the link to the test runs for different platforms, etc. I wanted to see if my tests passed Win 95. Sorry for asking questions that should probably be obvious, but we all start ignorant and some of us more ignorant and naive than others. Thanks, Mikey

Nov. 6, 2009

Re: shell32/tests: Add Program Manager DDE Conformance Tests (try 2)

by Mike

Didn't copy first response to the devel list. Took an initial look and I think I know what is going on. I will try and get a patch finished by the end of the weekend to correct these. --- On Fri, 11/6/09, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > From: Paul Vriens <paul.vriens.wine(a)gmail.com> > Subject: Re: shell32/tests: Add Program Manager DDE Conformance Tests (try 2) > To: "Mikey Alexander" <firesword14(a)yahoo.com> > Cc: wine-devel(a)winehq.org > Date: Friday, November 6, 2009, 12:43 AM > On 11/03/2009 04:32 AM, Mike wrote: > > These conformance tests are for the program manager > dde. Basic operations are tested. The current > wine implementation (shell32/dde.c) of the Program Manager > DDE is stubbed. This conformance tests were run and > passed on Win 98 SE and Win XP SP2. Related Bug #9159 > > > > > > --- > > dlls/shell32/tests/Makefile.in | > 1 + > > dlls/shell32/tests/progman_dde.c > | 551 ++++++++++++++++++++++++++++++++++++++ > > 2 files changed, 552 insertions(+), 0 > deletions(-) > > create mode 100644 > dlls/shell32/tests/progman_dde.c > > > > > > Hi Mikey, > > These new tests introduce test failures on different > platforms: > > http://test.winehq.org/data/tests/shell32:progman_dde.html > > Could you have a look? > > -- > Cheers, > > Paul. >

Nov. 6, 2009

To error out or to skip tests?

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

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: winmm/tests: Add MCI waveaudio tests.

by Paul Vriens

On 11/05/2009 02:35 PM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Hi, > > this is the same as yesterday's patch except that I replaced the > ad-hoc skip auto-open test with one that specifically detects Wine's > missing auto-open functionality instead of another thing missing in Wine. > You will prefer that version; sorry for the quick-shot. > > Regards, > Jörg Höhle. > Hi Jörg, This one introduces several test failures: http://test.winehq.org/data/tests/winmm:mci.html I guess you already noticed, but could you have a look? -- Cheers, Paul.

Nov. 6, 2009

Re: shell32/tests: Add Program Manager DDE Conformance Tests (try 2)

by Paul Vriens

On 11/03/2009 04:32 AM, Mike wrote: > These conformance tests are for the program manager dde. Basic operations are tested. The current wine implementation (shell32/dde.c) of the Program Manager DDE is stubbed. This conformance tests were run and passed on Win 98 SE and Win XP SP2. Related Bug #9159 > > > --- > dlls/shell32/tests/Makefile.in | 1 + > dlls/shell32/tests/progman_dde.c | 551 ++++++++++++++++++++++++++++++++++++++ > 2 files changed, 552 insertions(+), 0 deletions(-) > create mode 100644 dlls/shell32/tests/progman_dde.c > > Hi Mikey, These new tests introduce test failures on different platforms: http://test.winehq.org/data/tests/shell32:progman_dde.html Could you have a look? -- Cheers, Paul.

Nov. 6, 2009

Re: had trouble compiling today

by Susan Cragin

>Looks like a gcc compiler bug, so you will need to report it there >and/or to the Ubuntu bug tracker. > >Out of interest: > a/ did this work when you were running karmic? Yes. Worked always with Karmic. Worked yesterday with Lucid. But downloaded new gcc today, and new git. So it's one or the other. > b/ what does "gcc --version" produce? gcc (Ubuntu 4.4.2-1ubuntu3) 4.4.2 > c/ is this an incremental build from a previous build on karmic? Yes. (In fact, it's pre-alpha lucid.) It may well be that there is a new gcc that depends on a new something else that hasn't been released yet. > d/ what happens if you clean out all build files (running "git >clean -fxd" in ~/wine will do this if ~/wine is a clone of the wine >git repository) and do a build -- does that resolve the issue? Oh, that's a nice command. I'll have to remember that one. Nothing happens. >NOTE: You should still report this to gcc/Ubuntu. Noted. Reported. Bug filed. >- Reece As I was getting ready to send this I noted another gcc floating by aptitude, so I gave that one a spin. No luck. The problem persists, but I bet the developers know about it.

Nov. 5, 2009

Re: Wine on OpenBSD, Theo de Raadt

by David Laight

On Thu, Nov 05, 2009 at 02:21:47PM +0100, Yann Droneaud wrote: > And OpenBSD won't allow page 0 mapping for security reasons (and > performance reasons). > > Since Wine seems to be working on other *BSD and derivative systems, > is this a problem ? NetBSD is likely to disable user space mapping of address 0 some time in the near future - it does have problems with the compatibility code for other unix system binariess though (I can't remember which ones, compat-ultrix might be the one). David -- David Laight: david(a)l8s.co.uk

Nov. 5, 2009

Re: had trouble compiling today

by Reece Dunn

2009/11/5 Susan Cragin <susancragin(a)earthlink.net>: > It may be me. I've upgraded to Lucid Lynx. > My compile failed. > > gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wwrite-strings -Wtype-limits -Wpointer-arith -g -O2 -o int21.o int21.c > int21.c: In function ‘INT21_GetDriveAllocInfo’: > int21.c:3556: internal compiler error: in int_cst_value, at tree.c:8305 > Please submit a full bug report, > with preprocessed source if appropriate. > See <file:///usr/share/doc/gcc-4.4/README.Bugs> for instructions. Looks like a gcc compiler bug, so you will need to report it there and/or to the Ubuntu bug tracker. Out of interest: a/ did this work when you were running karmic? b/ what does "gcc --version" produce? c/ is this an incremental build from a previous build on karmic? d/ what happens if you clean out all build files (running "git clean -fxd" in ~/wine will do this if ~/wine is a clone of the wine git repository) and do a build -- does that resolve the issue? NOTE: You should still report this to gcc/Ubuntu. - Reece

Nov. 5, 2009

had trouble compiling today

by Susan Cragin

It may be me. I've upgraded to Lucid Lynx. My compile failed. gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wwrite-strings -Wtype-limits -Wpointer-arith -g -O2 -o int21.o int21.c int21.c: In function ‘INT21_GetDriveAllocInfo’: int21.c:3556: internal compiler error: in int_cst_value, at tree.c:8305 Please submit a full bug report, with preprocessed source if appropriate. See <file:///usr/share/doc/gcc-4.4/README.Bugs> for instructions. make[2]: *** [int21.o] Error 1 make[2]: Leaving directory `/home/susan/wine/dlls/winedos' make[1]: *** [winedos] Error 2 make[1]: Leaving directory `/home/susan/wine/dlls' make: *** [dlls] Error 2 susan(a)ubuntu:~/wine$

Nov. 5, 2009

Re: Wine on OpenBSD, Theo de Raadt

by Mihai Donțu

On Thursday 05 November 2009 19:44:47 David Gerard wrote: > 2009/11/5 Mihai Donțu <mihai.dontu(a)gmail.com>: > > I've never been able to run a dos program in Wine, but I've never asked > > myself why because I always had an alternative. > > DOSbox is a much better DOS than Wine is ever likely to be. > > Do Win32 console apps run okay in Wine without the page 0 mapping? I > I use wine to run the Microsoft Visual Studio Express compiler (cl.exe). So far I hadn't had any problems. > ask because in my last job, we actually used Wine to run a Win32 > console app on RHEL4 to save installing another Windows box. Never let > anyone tell you Wine isn't ready for the enterprise ;-) > -- Mihai Donțu

Nov. 5, 2009

Re: Wine on OpenBSD, Theo de Raadt

by David Gerard

2009/11/5 Mihai Donțu <mihai.dontu(a)gmail.com>: > I've never been able to run a dos program in Wine, but I've never asked myself > why because I always had an alternative. DOSbox is a much better DOS than Wine is ever likely to be. Do Win32 console apps run okay in Wine without the page 0 mapping? I ask because in my last job, we actually used Wine to run a Win32 console app on RHEL4 to save installing another Windows box. Never let anyone tell you Wine isn't ready for the enterprise ;-) - d.

Nov. 5, 2009

Re: Wine on OpenBSD, Theo de Raadt

by Mihai Donțu

On Thursday 05 November 2009 18:31:52 Yann Droneaud wrote: > Le jeudi 05 novembre 2009 à 17:01 +0100, Marcus Meissner a écrit : > > On Thu, Nov 05, 2009 at 02:21:47PM +0100, Yann Droneaud wrote: > > > Hi, > > > > > > In a recent post ( <http://lwn.net/Articles/360312/> ), Theo de Raadt > > > is criticising Linux page 0 handling. > > > He argue that Linux allows page 0 mapping only for Wine. > > > And OpenBSD won't allow page 0 mapping for security reasons (and > > > performance reasons). > > > > > > Since Wine seems to be working on other *BSD and derivative systems, > > > is this a problem ? > > > > > > Could someone comment on this issue. I don't find anything related on > > > <http://wiki.winehq.org/OpenBSD> > > > > Its actually not a real problem for Wine, last years code works without > > NULL pages. > > It seems many people thinks Wine needs to mmap the page 0 to run common > application. > > Does Wine 1.0 need it ? > > If not, it's really a myth. > # sysctl vm.mmap_min_addr vm.mmap_min_addr = 4096 and wine works like a charm. > > Our DOS emulator requires it, as vm86() mode uses 0 based mapping, > > so DOS programs won't work afterwards. But otherwise I see no dependency. > > (Perhaps Win16, but I dont think so.) > I've never been able to run a dos program in Wine, but I've never asked myself why because I always had an alternative. > According to this post from Alexandre Julliard, win16 don't need it. > > http://old.nabble.com/Re%3A-vm86-mode-is-not-supported-p23884662.html > > Perhaps it could be good point if there's a way to disable DOS emulator > at build time ? > -- Mihai Donțu

Nov. 5, 2009

Re: Wine on OpenBSD, Theo de Raadt

by Marcus Meissner

On Thu, Nov 05, 2009 at 05:31:52PM +0100, Yann Droneaud wrote: > Le jeudi 05 novembre 2009 à 17:01 +0100, Marcus Meissner a écrit : > > On Thu, Nov 05, 2009 at 02:21:47PM +0100, Yann Droneaud wrote: > > > Hi, > > > > > > In a recent post ( <http://lwn.net/Articles/360312/> ), Theo de Raadt is > > > criticising Linux page 0 handling. > > > He argue that Linux allows page 0 mapping only for Wine. > > > And OpenBSD won't allow page 0 mapping for security reasons (and > > > performance reasons). > > > > > > Since Wine seems to be working on other *BSD and derivative systems, > > > is this a problem ? > > > > > > Could someone comment on this issue. I don't find anything related on > > > <http://wiki.winehq.org/OpenBSD> > > > > Its actually not a real problem for Wine, last years code works without > > NULL pages. > > > > It seems many people thinks Wine needs to mmap the page 0 to run common > application. > > Does Wine 1.0 need it ? > > If not, it's really a myth. I installed 1.0.1 , enabled mmap_min_addr protectionm ... Testcase: Firefox 3.5.4 ... installs and runs nicely. (OK, I had some crashes after Flash Player installation for youtube, but youtube plays). > According to this post from Alexandre Julliard, win16 don't need it. > > http://old.nabble.com/Re%3A-vm86-mode-is-not-supported-p23884662.html > > Perhaps it could be good point if there's a way to disable DOS emulator o> at build time ? You do not know that at build time. My WINE rpms build for i586 can be run on i586 and x86_64 machines. Ciao, Marcus

Nov. 5, 2009

Re: Wine on OpenBSD, Theo de Raadt

by Yann Droneaud

Le jeudi 05 novembre 2009 à 17:01 +0100, Marcus Meissner a écrit : > On Thu, Nov 05, 2009 at 02:21:47PM +0100, Yann Droneaud wrote: > > Hi, > > > > In a recent post ( <http://lwn.net/Articles/360312/> ), Theo de Raadt is > > criticising Linux page 0 handling. > > He argue that Linux allows page 0 mapping only for Wine. > > And OpenBSD won't allow page 0 mapping for security reasons (and > > performance reasons). > > > > Since Wine seems to be working on other *BSD and derivative systems, > > is this a problem ? > > > > Could someone comment on this issue. I don't find anything related on > > <http://wiki.winehq.org/OpenBSD> > > Its actually not a real problem for Wine, last years code works without > NULL pages. > It seems many people thinks Wine needs to mmap the page 0 to run common application. Does Wine 1.0 need it ? If not, it's really a myth. > > Our DOS emulator requires it, as vm86() mode uses 0 based mapping, > so DOS programs won't work afterwards. But otherwise I see no dependency. > (Perhaps Win16, but I dont think so.) > According to this post from Alexandre Julliard, win16 don't need it. http://old.nabble.com/Re%3A-vm86-mode-is-not-supported-p23884662.html Perhaps it could be good point if there's a way to disable DOS emulator at build time ? Regards -- Yann Droneaud

Nov. 5, 2009

Re: crypt32.dll: Initialize provider pointer to null before calling CryptAcquireContextW()

by Juan Lang

> Checking the return value of CryptAcquireContextW() is also possible but I > took the path of minimal change in the source. The change I suggest would be small too. > Besides, I consider passing pointers to uninitialized variables a bad > programming practice. Not when they're out pointers. --Juan

Nov. 5, 2009

Re: Wine on OpenBSD, Theo de Raadt

by Marcus Meissner

On Thu, Nov 05, 2009 at 02:21:47PM +0100, Yann Droneaud wrote: > Hi, > > In a recent post ( <http://lwn.net/Articles/360312/> ), Theo de Raadt is > criticising Linux page 0 handling. > He argue that Linux allows page 0 mapping only for Wine. > And OpenBSD won't allow page 0 mapping for security reasons (and > performance reasons). > > Since Wine seems to be working on other *BSD and derivative systems, > is this a problem ? > > Could someone comment on this issue. I don't find anything related on > <http://wiki.winehq.org/OpenBSD> Its actually not a real problem for Wine, last years code works without NULL pages. Our DOS emulator requires it, as vm86() mode uses 0 based mapping, so DOS programs won't work afterwards. But otherwise I see no dependency. (Perhaps Win16, but I dont think so.) Ciao, Marcus

Nov. 5, 2009

Wine on OpenBSD, Theo de Raadt

by Yann Droneaud

Hi, In a recent post ( <http://lwn.net/Articles/360312/> ), Theo de Raadt is criticising Linux page 0 handling. He argue that Linux allows page 0 mapping only for Wine. And OpenBSD won't allow page 0 mapping for security reasons (and performance reasons). Since Wine seems to be working on other *BSD and derivative systems, is this a problem ? Could someone comment on this issue. I don't find anything related on <http://wiki.winehq.org/OpenBSD> Regards. -- Yann Droneaud

Nov. 5, 2009

Re: crypt32.dll: Initialize provider pointer to null before calling CryptAcquireContextW()

by Paul Chitescu

On Wednesday 04 November 2009 11:45:38 pm Juan Lang wrote: > Hi Paul, > > I imagine this is to avoid checking prov if CryptAcquireContextW > fails. In that case, wouldn't it be better to check the return value > of CryptAcquireContextW? > --Juan Checking the return value of CryptAcquireContextW() is also possible but I took the path of minimal change in the source. Besides, I consider passing pointers to uninitialized variables a bad programming practice. Paul

Nov. 5, 2009

Re: Weird error for the advapi32/eventlog tests on Vista+ when running winetest

by Paul Vriens

On 11/05/2009 10:11 AM, Paul Vriens wrote: > On 11/04/2009 09:45 PM, Reece Dunn wrote: >> 2009/11/4 Paul Vriens<paul.vriens.wine(a)gmail.com>: >>> Hi, >>> >>> Just noticed that we have 1 test failure on Vista+ for the >>> advapi32/eventlog >>> tests. I was sure I've tested these from Win95 up to Win7. >>> >>> When I run tests I want to do this as Administrator, so on Vista+ I >>> select >>> 'Run as Administrator' to start a command prompt, or to launch winetest. >>> >>> Running the mentioned crosscompiled tests is no problem unless you do >>> this >>> from the actual home directory (or any subdirectory) of the user that >>> logged >>> in. >>> >>> Winetest runs most of it's test in the %TEMP% directory and hence we see >>> this failure. But I have no clue why (yet). >>> >>> Anyone? >> > > Hi Reece, > >> Ah, I see. This is the failure on test.winehq.org, correct? > > Yes. I'm in the process of writing loads of eventlog tests while keeping > track of possible failures on test.winehq.org. > >> >> eventlog.c:586: Test failed: Expected ERROR_INVALID_HANDLE, got 5 >> >> 5 is ERROR_ACCESS_DENIED. >> >> The create_backup function does not have any error checking -- what >> happens when you put the return values for these calls, and the >> GetLastError in ok checks, e.g. >> >> ok(DeleteFileA(filename), "error deleting the backup event log file"); >> ok(GetLastError() == 0, "GetLastError -- expected ERROR_SUCCESS, >> got %d", GetLastError()); >> >> - Reece > > Deleting the file works just fine. both in create_backup() and > test_clear(). > > What makes it even more weird is that I have the same error when I run > these tests as the user (not admin). > > I also don't get any UAC prompts in either case. Turning UAC off doesn't > make a difference. > > I don't see any logical explanation why the function returns a different > error. The fact that the function fails anyway makes me consider using a > second possible last error for that particular test. > Found it. The eventlog service runs under an account that doesn't have the necessary rights for a users home directory. This account is the actual one performing some of the actions. -- Cheers, Paul.

Nov. 5, 2009

Re: Weird error for the advapi32/eventlog tests on Vista+ when running winetest

by Paul Vriens

On 11/04/2009 09:45 PM, Reece Dunn wrote: > 2009/11/4 Paul Vriens<paul.vriens.wine(a)gmail.com>: >> Hi, >> >> Just noticed that we have 1 test failure on Vista+ for the advapi32/eventlog >> tests. I was sure I've tested these from Win95 up to Win7. >> >> When I run tests I want to do this as Administrator, so on Vista+ I select >> 'Run as Administrator' to start a command prompt, or to launch winetest. >> >> Running the mentioned crosscompiled tests is no problem unless you do this >> from the actual home directory (or any subdirectory) of the user that logged >> in. >> >> Winetest runs most of it's test in the %TEMP% directory and hence we see >> this failure. But I have no clue why (yet). >> >> Anyone? > Hi Reece, > Ah, I see. This is the failure on test.winehq.org, correct? Yes. I'm in the process of writing loads of eventlog tests while keeping track of possible failures on test.winehq.org. > > eventlog.c:586: Test failed: Expected ERROR_INVALID_HANDLE, got 5 > > 5 is ERROR_ACCESS_DENIED. > > The create_backup function does not have any error checking -- what > happens when you put the return values for these calls, and the > GetLastError in ok checks, e.g. > > ok(DeleteFileA(filename), "error deleting the backup event log file"); > ok(GetLastError() == 0, "GetLastError -- expected ERROR_SUCCESS, > got %d", GetLastError()); > > - Reece Deleting the file works just fine. both in create_backup() and test_clear(). What makes it even more weird is that I have the same error when I run these tests as the user (not admin). I also don't get any UAC prompts in either case. Turning UAC off doesn't make a difference. I don't see any logical explanation why the function returns a different error. The fact that the function fails anyway makes me consider using a second possible last error for that particular test. -- Cheers, Paul.

Nov. 5, 2009

Re: crypt32.dll: Initialize provider pointer to null before calling CryptAcquireContextW()

by Juan Lang

Hi Paul, I imagine this is to avoid checking prov if CryptAcquireContextW fails. In that case, wouldn't it be better to check the return value of CryptAcquireContextW? --Juan

Nov. 4, 2009

Comment request: wineconsole: Fix Alt+F10 sent when F10 pressed.

by Erich Hoover

I thought this patch was pretty straightforward, comments? http://www.winehq.org/pipermail/wine-patches/2009-October/080779.html Erich Hoover ehoover(a)mines.edu

Nov. 4, 2009

Re: Weird error for the advapi32/eventlog tests on Vista+ when running winetest

by Reece Dunn

2009/11/4 Paul Vriens <paul.vriens.wine(a)gmail.com>: > Hi, > > Just noticed that we have 1 test failure on Vista+ for the advapi32/eventlog > tests. I was sure I've tested these from Win95 up to Win7. > > When I run tests I want to do this as Administrator, so on Vista+ I select > 'Run as Administrator' to start a command prompt, or to launch winetest. > > Running the mentioned crosscompiled tests is no problem unless you do this > from the actual home directory (or any subdirectory) of the user that logged > in. > > Winetest runs most of it's test in the %TEMP% directory and hence we see > this failure. But I have no clue why (yet). > > Anyone? Ah, I see. This is the failure on test.winehq.org, correct? eventlog.c:586: Test failed: Expected ERROR_INVALID_HANDLE, got 5 5 is ERROR_ACCESS_DENIED. The create_backup function does not have any error checking -- what happens when you put the return values for these calls, and the GetLastError in ok checks, e.g. ok(DeleteFileA(filename), "error deleting the backup event log file"); ok(GetLastError() == 0, "GetLastError -- expected ERROR_SUCCESS, got %d", GetLastError()); - Reece

Nov. 4, 2009

Re: [PATCH] winedbg: gdb proxy mode: support qAttached packet

by Eric Pouech

Paul Bolle a écrit : > Add support for the qAttached packet. Main benefit is that if gdb was > attached to a debuggee and it quits it will now ask if it should detach > from the debuggee instead of asking whether the debuggee should be > killed. (It still will ask whether the debuggee should be killed if it > launched the debuggee itself). > > Signed-off-by: Paul Bolle <pebolle(a)tiscali.nl> > --- > Would it be better to add a new member to gdbctx instead of using a > separate variable (qAttached_reply)? > yes, inclusion in gdbctx is preferred (and storage should rather be an integer rather than a string pointer) A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

Nov. 4, 2009

Re: Weird error for the advapi32/eventlog tests on Vista+ when running winetest

by Reece Dunn

2009/11/4 Paul Vriens <paul.vriens.wine(a)gmail.com>: > Hi, > > Just noticed that we have 1 test failure on Vista+ for the advapi32/eventlog > tests. I was sure I've tested these from Win95 up to Win7. > > When I run tests I want to do this as Administrator, so on Vista+ I select > 'Run as Administrator' to start a command prompt, or to launch winetest. > > Running the mentioned crosscompiled tests is no problem unless you do this > from the actual home directory (or any subdirectory) of the user that logged > in. > > Winetest runs most of it's test in the %TEMP% directory and hence we see > this failure. But I have no clue why (yet). > > Anyone? What are the errors you are experiencing? Are you getting access denied errors? If so, it may be due to the different file access permissions. What happens when you create/delete the files produced by winetest in the %TEMP% directory in the explorer GUI? Do you get/need a UAC prompt for it to work? Have you tried adding UAC information to the manifest if this is the case? Sorry I can't help out any further as I abandoned Vista a long time ago ^_^. - Reece

Nov. 4, 2009

Weird error for the advapi32/eventlog tests on Vista+ when running winetest

by Paul Vriens

Hi, Just noticed that we have 1 test failure on Vista+ for the advapi32/eventlog tests. I was sure I've tested these from Win95 up to Win7. When I run tests I want to do this as Administrator, so on Vista+ I select 'Run as Administrator' to start a command prompt, or to launch winetest. Running the mentioned crosscompiled tests is no problem unless you do this from the actual home directory (or any subdirectory) of the user that logged in. Winetest runs most of it's test in the %TEMP% directory and hence we see this failure. But I have no clue why (yet). Anyone? -- Cheers, Paul.

Nov. 4, 2009

Re: winex11.drv: Implement FIXME in AlphaBlend

by Roderick Colenbrander

Hi Peter, 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. 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. Roderick On Mon, Oct 26, 2009 at 4:39 PM, Peter Urbanec <winehq.org(a)urbanec.net> wrote: > > > commit df78de34a06e32be9f37a3b34fe68e5b088a8578 > Author: Peter Urbanec <winehq.org(a)urbanec.net> > Date: Mon Oct 26 21:29:00 2009 +1100 > > Implement source alpha plus SourceConstantAlpha combined transparency. > Add DIB locking to prevent node icon rendering errors in Fusion composition flow views. > > diff --git a/dlls/winex11.drv/xrender.c b/dlls/winex11.drv/xrender.c > index 90503bf..26dc262 100644 > --- a/dlls/winex11.drv/xrender.c > +++ b/dlls/winex11.drv/xrender.c > @@ -1956,9 +1956,6 @@ BOOL CDECL X11DRV_AlphaBlend(X11DRV_PDEVICE *devDst, INT xDst, INT yDst, INT wid > return FALSE; > } > > - if ((blendfn.AlphaFormat & AC_SRC_ALPHA) && blendfn.SourceConstantAlpha != 0xff) > - FIXME("Ignoring SourceConstantAlpha %d for AC_SRC_ALPHA\n", blendfn.SourceConstantAlpha); > - > if(dib.dsBm.bmBitsPixel != 32) { > FIXME("not a 32 bpp dibsection\n"); > return FALSE; > @@ -1979,11 +1976,35 @@ BOOL CDECL X11DRV_AlphaBlend(X11DRV_PDEVICE *devDst, INT xDst, INT yDst, INT wid > > if (blendfn.AlphaFormat & AC_SRC_ALPHA) > { > - for(; y >= y2; y--) > + if (blendfn.SourceConstantAlpha == 0xff) > { > - memcpy(dstbits, (char *)dib.dsBm.bmBits + y * dib.dsBm.bmWidthBytes + xSrc * 4, > + for(; y >= y2; y--) > + { > + memcpy(dstbits, (char *)dib.dsBm.bmBits + y * dib.dsBm.bmWidthBytes + xSrc * 4, > widthSrc * 4); > - dstbits += (top_down ? -1 : 1) * widthSrc; > + dstbits += (top_down ? -1 : 1) * widthSrc; > + } > + } > + else > + { > + /* Source alpha plus SourceConstantAlpha */ > + for(; y >= y2; y--) > + { > + int x; > + DWORD *srcbits = (DWORD *)((char *)dib.dsBm.bmBits + y * dib.dsBm.bmWidthBytes) + xSrc; > + for (x = 0; x < widthSrc; x++) > + { > + DWORD argb = *srcbits++; > + BYTE *s = (BYTE *) &argb; > + s[0] = (s[0] * blendfn.SourceConstantAlpha) / 255; > + s[1] = (s[1] * blendfn.SourceConstantAlpha) / 255; > + s[2] = (s[2] * blendfn.SourceConstantAlpha) / 255; > + s[3] = (s[3] * blendfn.SourceConstantAlpha) / 255; > + *dstbits++ = argb; > + } > + if (top_down) /* we traversed the row forward so we should go back by two rows */ > + dstbits -= 2 * widthSrc; > + } > } > } > else > @@ -2006,6 +2027,7 @@ BOOL CDECL X11DRV_AlphaBlend(X11DRV_PDEVICE *devDst, INT xDst, INT yDst, INT wid > > } > > + X11DRV_LockDIBSection( devDst, DIB_Status_GdiMod ); > dst_pict = get_xrender_picture(devDst); > > wine_tsx11_lock(); > @@ -2017,6 +2039,8 @@ BOOL CDECL X11DRV_AlphaBlend(X11DRV_PDEVICE *devDst, INT xDst, INT yDst, INT wid > if(!src_format) > { > WARN("Unable to find a picture format supporting alpha, make sure X is running at 24-bit\n"); > + wine_tsx11_unlock(); > + X11DRV_UnlockDIBSection( devDst, TRUE ); > return FALSE; > } > > @@ -2055,6 +2079,7 @@ BOOL CDECL X11DRV_AlphaBlend(X11DRV_PDEVICE *devDst, INT xDst, INT yDst, INT wid > XDestroyImage(image); > > wine_tsx11_unlock(); > + X11DRV_UnlockDIBSection( devDst, TRUE ); > HeapFree(GetProcessHeap(), 0, data); > return TRUE; > } > > > >

Nov. 4, 2009

Re: mshtml/tests: Fix events test when pointer is on a corner.

by Jacek Caban

Hi Nicolas, Nicolas Le Cam wrote: > 2009/10/30 Jacek Caban <jacek(a)codeweavers.com>: > >> Hi Nicolas, >> >> Nicolas Le Cam wrote: >> >>> Hi Jacek, >>> >>> Thanks for feedback. >>> It should handle pointer in every corners IMHO, the left corner can >>> cause failures in winetest. >>> >>> I'll try to find a better solution. Do you have any hints ? >>> >>> >> The test in line 472 is invalid. It looks like all we can do is check if >> get_x returned something. I'd suggest to set l to 0xdeadbeef before get_x >> call and test that the value has changed (ok(x != 0xdeadbeef, ...)). That's >> all we can do. The same applies to get_client[XY] and get_offset[XY] tests. >> >> >> Thanks,git br >> Jacek >> >> >> > Hi Jacek, > > I did what you've suggested (patch's attached for reference) but I > don't think it's the right solution. > Test passes on Wine and Windows with such a patch, but we're now > ignoring the fact that values are completely different on Wine (only > -1 and 0) and Windows (cursor's position relative to something). > > I'm trying to find a way to compare values against results from > GetCursorPos and friends. What do you think about that, could that be > a solution ? > I think your patch might go to Wine. If you can find a solution with more strict tests, that would be even better, but I'm afraid that GetCursorPos might be problematic. We won't know until we try. Thanks, Jacek

Nov. 4, 2009

Re: Please write audio tests (was: Playing ULAW sample correctly?)

by Gert van den Berg

On Wed, Nov 4, 2009 at 12:48, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > Hi, > >>1. generate a PCM sine wave tone (like winmm/tests/wave.c); > Actually any repetitive signal may not be good enough for general purpose, > sine or square. Perhaps add some change in volume? > > For instance, there currently is a bug somewhere that causes Wine to > repeat the first second of an intro animation's sound (bug #18182, comment #3) > instead of continuing. This would probably not be detected. > > Also, the µ-law speech sample I fed to the MCI produces > stuttering. Perhaps that would not be heard with a sine wave, > if the periods match. > A chirp (frequency sweep) might help for most of these issues? (Another sound with volume sweeps might be needed for other issues?) Chirps are quite easy to generate. (I'm not familiar with Wine's code yet though...) http://en.wikipedia.org/wiki/Chirp Gert

Nov. 4, 2009

Re: winmm/tests: Add MCI waveaudio tests.

by Alexandre Julliard

<Joerg-Cyril.Hoehle(a)t-systems.com> writes: > +START_TEST(mci) > +{ > + HWND hwnd; > + hwnd = CreateWindowExA(0, "static", "winmm test", WS_POPUP, 0,0,100,100, > + 0, 0, 0, NULL); > + test_openCloseWAVE(hwnd); > + test_recordWAVE(hwnd); > + test_playWAVE(hwnd); > + test_asyncWAVE(hwnd); > + test_AutoOpenWAVE(hwnd); > + if(1) DeleteFile("tempfile.wav"); This fails to delete the file, probably because it's still open somewhere. -- Alexandre Julliard julliard(a)winehq.org

Nov. 4, 2009

RE: how to install a windows service in wine?

by Zhaohui Wang

Sorry, I didn't find the user list at the beginning, now I moved to there. -----Original Message----- From: Juan Lang [mailto:juan.lang(a)gmail.com] Sent: Tuesday, November 03, 2009 10:25 PM To: Zhaohui Wang Cc: wine-devel(a)winehq.org Subject: Re: how to install a windows service in wine? > I am using wine 1.1.32, can anyone tell me how to install a windows > service(say NETBIOS) in wine? Wrong list, you want wine-users instead. --Juan

Nov. 4, 2009

Re: mciwave: Eliminate superfluous logs.

by Alexandre Julliard

<Joerg-Cyril.Hoehle(a)t-systems.com> writes: > - WARN after ExitThread is superfluous (and not present in most other code) Most likely the ExitThread should be removed. -- Alexandre Julliard julliard(a)winehq.org

Nov. 4, 2009

Re: mciwave: Use volatile on slot modified from recorder thread.

by Alexandre Julliard

<Joerg-Cyril.Hoehle(a)t-systems.com> writes: > From b45e51940a42016e25a5c3a144968d81248927ed Mon Sep 17 00:00:00 2001 > From: =?utf-8?q?J=C3=B6rg=20H=C3=B6hle?= <hoehle(a)users.sourceforge.net> > Date: Mon, 2 Nov 2009 23:49:42 +0100 > Subject: [PATCH] mciwave: Use volatile on slot modified from recorder thread. That's wrong. If there is proper synchronization you don't need volatile, and if there isn't volatile won't magically fix it. -- Alexandre Julliard julliard(a)winehq.org

Nov. 4, 2009

Please write audio tests (was: Playing ULAW sample correctly?)

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

Hi, >1. generate a PCM sine wave tone (like winmm/tests/wave.c); Actually any repetitive signal may not be good enough for general purpose, sine or square. Perhaps add some change in volume? For instance, there currently is a bug somewhere that causes Wine to repeat the first second of an intro animation's sound (bug #18182, comment #3) instead of continuing. This would probably not be detected. Also, the µ-law speech sample I fed to the MCI produces stuttering. Perhaps that would not be heard with a sine wave, if the periods match. Still it's better to have a test than currently no test at all! >It is also quite simple to generate sine waves without any trig. Code for sine is already in winmm/tests/wave.c No need to reinvent. Regards, Jörg Höhle

Nov. 4, 2009

Re: msi: Initialize string pointer to NULL

by Nathan Gallaher

Kirill, I see what you're getting at. The valgrind error comes about when we call get_column_info in streams.c. No string is allocated for table_name there, so the pointer remains uninitialized. I am unfamiliar with the streams use case, but looking at tests/db.c:test_streamtable(), I think that the correct tablename to be returning is '_Streams'. Would you agree? Thanks, ~Nathan On Sun, 1 Nov 2009, Kirill K. Smirnov wrote: > Hi Nathan, >> + haystack_table_name = NULL; >> r = table->ops->get_column_info( table, i, &col_name, NULL, >> NULL, &haystack_table_name ); >> if( r != ERROR_SUCCESS ) > > I'm afraid, but this patch silences valgrind only, but does not solves the > problem. It seems to me, that if table->ops->get_column_info() succeeds, it > initializes haystack_table_name, and if it fails, we do not use > haystack_table_name at all (we immediately return from this function). Thus, > the problem lies somewhere in get_column_info(). > > So it is useless (and harmful, because it confuses valgrind) to initialize it > like this. > > -- > Kirill >

Nov. 3, 2009

Re: how to install a windows service in wine?

by Juan Lang

> I am using wine 1.1.32, can anyone tell me how to install a windows > service(say NETBIOS) in wine? Wrong list, you want wine-users instead. --Juan

Nov. 3, 2009

how to install a windows service in wine?

by Zhaohui Wang

Hi all I am using wine 1.1.32, can anyone tell me how to install a windows service(say NETBIOS) in wine? I saw there is a services.exe running, but I didn't find any document on winehq saying how to add new wine services. I appreciate your help Best Regards Zhao Wang

Nov. 3, 2009

Re: crypt32: Implement CertAddEncodedCertificateToSystemStoreA/W

by Juan Lang

> + store = CertOpenSystemStoreA(0, pszCertStoreName); > > This looks wrong to me ... To me too :) Thanks! --Juan

Nov. 3, 2009

Re: crypt32: Implement CertAddEncodedCertificateToSystemStoreA/W

by Stefan Leichter

Am Tuesday 03 November 2009 23:32:42 schrieb Juan Lang: > These were too easy to pass up. > --Juan +BOOL WINAPI CertAddEncodedCertificateToSystemStoreW(LPCWSTR pszCertStoreName, + const BYTE *pbCertEncoded, DWORD cbCertEncoded) +{ [snip] + store = CertOpenSystemStoreA(0, pszCertStoreName); This looks wrong to me ... Bye Stefan

Nov. 3, 2009

RE: Please write audio tests (was: Playing ULAW sample correctly?)

by Nicklas Börjesson

>Or use a goertzel detector for the transmitted tone(s). >It is also quite simple to generate sine waves without any trig. Just another, less advanced, idea, Even easier would making a really slow square wave(~0.5 Hz) that follows a simple pattern, like 80, 80, 80, -80, -80, -80, 80, 80, 80...for 5 seconds. Then one would easily be able to find the signal in the data without any advanced tricks. Just (signal<0) or not for a specified period would suffice as detection. Maybe stutter and sound quality would not be tested, however it would be a simple first step. BTW, wouldn't stutter affect a straight line as much as it would a sound wave? If you know that the wave isn't a wave but is supposed to follow a straight line, wouldn't then all deviations be stutter? The soundsystem doesn't treat a stream of similar bytes any different from a sine wave, does it? Of course, this will obviously not work through a microphone, but I can't see how that loop would be relevant to test. Being hardware and all. //Nicklas

Nov. 3, 2009

Re: Please write audio tests (was: Playing ULAW sample correctly?)

by David Laight

On Tue, Nov 03, 2009 at 07:48:29PM +0200, Damjan Jovanovic wrote: > On Tue, Nov 3, 2009 at 3:33 PM, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > > > > Wine would benefit from a test in msacm32/tests/ sketched as follows: > > 0. choose some base frequency like 11025Hz; > > 1. generate a PCM sine wave tone (like winmm/tests/wave.c); > > 2. convert it to ?-law via the ACM functions; > > 3. play it via winmm if wine_interactive is set (like in wave.c) > > 4. convert it back and apply some delta function to tell if it's > > ? close enough to the original sine, > > ? i.e. mechanically verify that the round-trip worked. > > You'd need to verify the energy in the discrete Fourier transform of > the signal at the frequency you're testing for, is say 90% of the > total signal energy. Or use a goertzel detector for the transmitted tone(s). It is also quite simple to generate sine waves without any trig. David -- David Laight: david(a)l8s.co.uk

Nov. 3, 2009

Re: Please write audio tests (was: Playing ULAW sample correctly?)

by Damjan Jovanovic

On Tue, Nov 3, 2009 at 3:33 PM, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > Hi, > > Eric Pouech wrote: >>> It is not acceptable that µ-law code bit-rots because of >>lack of continuous >>> testing (assuming it worked the day it was checked in). > >>actually, you can add a (small) wave file in the test program (and >>create on the fly the needed file) >>we already test some .exe this way in winetest > One could do without real .wav files: > > Wine would benefit from a test in msacm32/tests/ sketched as follows: > 0. choose some base frequency like 11025Hz; > 1. generate a PCM sine wave tone (like winmm/tests/wave.c); > 2. convert it to µ-law via the ACM functions; > 3. play it via winmm if wine_interactive is set (like in wave.c) > 4. convert it back and apply some delta function to tell if it's > close enough to the original sine, > i.e. mechanically verify that the round-trip worked. You'd need to verify the energy in the discrete Fourier transform of the signal at the frequency you're testing for, is say 90% of the total signal energy. wave.c however does this instead: if (winetest_interactive && (device != WAVE_MAPPER)) { trace("Playing a 5 seconds reference tone.\n"); trace("All subsequent tones should be identical to this one.\n"); trace("Listen for stutter, changes in pitch, volume, etc.\n"); ...which is a human verification not an automated one... And recording from the microphone while playing seems like bad news, surrounding noise levels are unpredictable, hardware might not be present, etc. Any other idea how to play and record without using the microphone? Maybe we should test against the implementation in a tool like sox instead? > 5. repeat 2-4 for > - ADPCM > - IMAADPCM > - GSM6.10 (is available) > - .... > - actually, better enumerate all ACM converters and call them in turn > rather than hard-code a fixed set of them. > > I'll not write that, as the MCI will probably keep me busy until the end of the year. > > Any volunteer who wants to provide this? > Regards, > Jörg Höhle. > > > Damjan Jovanovic

Nov. 3, 2009

windows chromium testsuite valgrind warnings

by Dan Kegel

For what it's worth, here are the valgrind warnings from a run of my current subset of the chromium test suite under valgrind+wine: http://kegel.com/wine/chromium/valgrind-logs/errors.html Mostly they're leaks. That's good news. For the few nonleak warnings, I already filed http://bugs.winehq.org/show_bug.cgi?id=20567 for the des one in http://kegel.com/wine/chromium/valgrind-logs/base_unittests/RSAPrivateKeyUn… http://kegel.com/wine/chromium/valgrind-logs/base_unittests/SignatureCreato… and http://kegel.com/wine/chromium/valgrind-logs/base_unittests/SignatureVerifi… and http://bugs.winehq.org/show_bug.cgi?id=20553 for the first one in http://kegel.com/wine/chromium/valgrind-logs/unit_tests/TableViewTest.log and am puzzling over the crash later in TableViewTest (though maybe once I clear up the first error, the crash will go away). The leaks aren't quite as important. I filed a few so far: http://bugs.winehq.org/show_bug.cgi?id=20544 shell32 imagelist memory leak on unload? http://bugs.winehq.org/show_bug.cgi?id=20545 memory leak in MMDRV_Init on exit? http://bugs.winehq.org/show_bug.cgi?id=20548 Memory leak in pending overlapped I/O? http://bugs.winehq.org/show_bug.cgi?id=20551 user32 clipboard memory leaks http://bugs.winehq.org/show_bug.cgi?id=20552 Memory leak in alloc_thread_tls? and http://bugs.winehq.org/show_bug.cgi?id=20549 secur32 memory leak on exit? which is already closed (it's an upstream issue and/or notabug). Of those, I'm only worried about 20548 and 20551. - Dan

Nov. 3, 2009

Please write audio tests (was: Playing ULAW sample correctly?)

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

Hi, Eric Pouech wrote: >> It is not acceptable that µ-law code bit-rots because of >lack of continuous >> testing (assuming it worked the day it was checked in). >actually, you can add a (small) wave file in the test program (and >create on the fly the needed file) >we already test some .exe this way in winetest One could do without real .wav files: Wine would benefit from a test in msacm32/tests/ sketched as follows: 0. choose some base frequency like 11025Hz; 1. generate a PCM sine wave tone (like winmm/tests/wave.c); 2. convert it to µ-law via the ACM functions; 3. play it via winmm if wine_interactive is set (like in wave.c) 4. convert it back and apply some delta function to tell if it's close enough to the original sine, i.e. mechanically verify that the round-trip worked. 5. repeat 2-4 for - ADPCM - IMAADPCM - GSM6.10 (is available) - .... - actually, better enumerate all ACM converters and call them in turn rather than hard-code a fixed set of them. I'll not write that, as the MCI will probably keep me busy until the end of the year. Any volunteer who wants to provide this? Regards, Jörg Höhle.

Nov. 3, 2009

Re: [PATCH 0/3] Handling DOS drives in mountmgr (try 2)

by Charles Davis

Charles Davis wrote: > Alexandre Julliard wrote: >> Charles Davis <cdavis(a)mymail.mines.edu> writes: >> >>> I thought I fixed all the issues. What's wrong with my patches now? >> Many things, it's a lot more complicated than that. For instance you >> can't just kill the fstab support, this needs to be preserved somehow, >> probably on the mountmgr side. Also you can't have a single file >> descriptor per device, you need one for each open. >> > OK, I can do that. > > I've decided to do the open in mountmgr, so I can have it handle changes > to the fstab while it's running. So, I'm working on implementing > IRP_MJ_CREATE support (which is the standard way for drivers to handle > open requests). I've attached a first stab at that. Can you take a look? > I'm pretty sure there's something I'm missing. > > BTW, I'm on #winehackers as I write this (my nick is cdavis5x). > > Chip > > Please disregard both my emails. (The second one was because my email client complained that it failed to send the email.) That patch I sent is riddled with problems. (I should know better by now, but apparently, I don't. Once again, I jumped the gun, so to speak.) I'll have a better version ready by tomorrow.

Nov. 2, 2009

Re: mshtml/tests: Fix events test when pointer is on a corner.

by Nicolas Le Cam

2009/10/30 Jacek Caban <jacek(a)codeweavers.com>: > Hi Nicolas, > > Nicolas Le Cam wrote: >> >> Hi Jacek, >> >> Thanks for feedback. >> It should handle pointer in every corners IMHO, the left corner can >> cause failures in winetest. >> >> I'll try to find a better solution. Do you have any hints ? >> > > The test in line 472 is invalid. It looks like all we can do is check if > get_x returned something. I'd suggest to set l to 0xdeadbeef before get_x > call and test that the value has changed (ok(x != 0xdeadbeef, ...)). That's > all we can do. The same applies to get_client[XY] and get_offset[XY] tests. > > > Thanks,git br > Jacek > > Hi Jacek, I did what you've suggested (patch's attached for reference) but I don't think it's the right solution. Test passes on Wine and Windows with such a patch, but we're now ignoring the fact that values are completely different on Wine (only -1 and 0) and Windows (cursor's position relative to something). I'm trying to find a way to compare values against results from GetCursorPos and friends. What do you think about that, could that be a solution ? Thanks, Nicolas Le Cam

Nov. 2, 2009

Re: eventlog tests and writing/clearing the logs

by Paul Vriens

On 11/02/2009 05:51 PM, mellery wrote: > Hi, > > Will this involve implementing advapi:RegisterTraceGuidsW, and can I > help at all? > > Thanks, > Mike Event tracing is totally different from event logging. Be my guest to pick that up ;) Maybe it's a good idea to split the advapi32/eventlog.c into eventlog.c and eventtrace.c once the tracing is fleshed out a bit more. Particularly if we move most of functionality to services.exe (as on Windows). -- Cheers, Paul.

Nov. 2, 2009

Re: eventlog tests and writing/clearing the logs

by Paul Vriens

On 11/02/2009 05:39 PM, Nikolay Sivov wrote: > On Mon, Nov 2, 2009 at 7:35 PM, Paul Vriens<paul.vriens.wine(a)gmail.com> wrote: >> >> Any thoughts on this? Correct approach? >> > > Do you plan to implement a real logging or what all of this is for? If you mean, get functional event logging into Wine, the answer is yes. -- Cheers, Paul.

Nov. 2, 2009

Re: gdi32: add testcases for copying an EMF from a NULL bitmap

by Austin English

On Mon, Nov 2, 2009 at 10:09 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > On Mon, Nov 2, 2009 at 8:27 AM, Austin English <austinenglish(a)gmail.com> wrote: >> Testcase for bug 4553 > > Are you sure? I don't see any related patches here. > >> >> -- >> -Austin >> > > Why there's no wine failure in this test? Apparently part of the problem has already been fixed, as the testcase passes but the program still crashes. I sent the testcase by itself to prevent it from regressing. Actually, there was a typo in the original e-mail, it's bug 4543, see http://bugs.winehq.org/show_bug.cgi?id=4543#c17. -- -Austin

Nov. 2, 2009