Re: msvcp90: start rfind from given position
On 01/13/2012 11:42 PM, Daniel Lehman wrote: >> >> === WVISTAADM (32 bit string) === >> Failure running script in VM: The specified guest user must be logged >> in interactively to perform this operation > > Do I need to resend in this case? I already ran it on TestBot before > submitting the patch and they all passed No. This failure has nothing to do with your tests. bye michael
RE: msvcp90: start rfind from given position
> > === WVISTAADM (32 bit string) === > Failure running script in VM: The specified guest user must be logged > in interactively to perform this operation Do I need to resend in this case? I already ran it on TestBot before submitting the patch and they all passed Thanks daniel
Re: msvcp90: start rfind from given position
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=16431 Your paranoid android. === WVISTAADM (32 bit string) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation
Re: mscoree: Implement DllGetClassObject (try 3)
+HRESULT create_monodata(REFIID riid, LPVOID *ppObj ) ... +IID iid; You mean clsid here, not riid, right? Otherwise, looks good to me.
Re: services: Avoid a race when service_entry is freed and process is terminated
On 01/13/12 20:40, Piotr Caban wrote: --- programs/services/rpc.c | 7 --- 1 files changed, 4 insertions(+), 3 deletions(-) Please ignore this patch.
Re: Long translation patch
Am 13.01.2012 19:50, schrieb Frédéric Delanoy: > NB: BTW François, it would be nice it that po errors page included the > "run" date you can at least see the git sha1 in e.g. http://fgouget.free.fr/wine-po/fr-errors.html (by moving the mouse over the links) much better would be an integration into transl, i'd volunteer for it -- Best Regards, André Hentschel
Re: Long translation patch
2012/1/13 Gustavo Henrique Milaré : > Thank you for the heads up, Julliard :) > > I've sent the patch and it was applied, but there is one small problem. > After pulling the git repo, I realized that there are still two texts marked > as fuzzy (lines 589 and 595). It is funny, because the patch I sent > explicitly removed the two fuzzy annotations. Sometimes fuzzy keywords are added, e.g. when an English string is fixed. To see other errors (not necessarily fuzzy strings), you can check François Gouget's tool at http://fgouget.free.fr/wine-po/ Frédéric NB: BTW François, it would be nice it that po errors page included the "run" date
Mac OSX: Use existing Pictures/ Music/ Videos/ etc. directories
Hi, winecfg on Mac OSX (10.5.6 and .7) does not link "My Videos" etc. to the equivalent directories on the Mac. Everything is linked to $HOME (or was it Desktop/?) instead. What a pity! See enhancement request/bug 19028 Wouldn't that be an easy patch for Wine+MacOS starters and a nice thing to have in wine-1.4 too? Thank you, Jörg Höhle
Re: err:ntdll:RtlDeleteResource Deleting active MRSW lock, expect failure
Am 13.01.2012 12:10, schrieb joerg-cyril.hoe...@t-systems.com: > Hi, > > Does anyone know about this error? > It sometimes occurs on a Linux machine after the mmdevapi > capture tests exited, with a delay as if originating from > the server (or a service.exe). > Some capture logs sent to me contain this too. > > Looking up bugzilla, you'll find this error mentioned half > a dozen times with various apps. > > Regards, > Jörg Höhle > there's forum.winehq.org/viewtopic.php?t=14358 -- Best Regards, André Hentschel
Re: Long translation patch
Thank you for the heads up, Julliard :) I've sent the patch and it was applied, but there is one small problem. After pulling the git repo, I realized that there are still two texts marked as fuzzy (lines 589 and 595). It is funny, because the patch I sent explicitly removed the two fuzzy annotations. Gustavo Em 13 de janeiro de 2012 07:44, Alexandre Julliard escreveu: > Gustavo Henrique Milaré writes: > > > It turns out the patch is very large (around 6500 lines). Sorry if this > is > > a lame question, but I guess I'll need to break it in 15 patches or so, > > right? Should I send all patches in the same day? I don't want to give > the > > patch reviewers a headache :) > > If it only touches the po file, a single patch is fine. Just make sure > it's relative to the latest git on the day you send it, otherwise some > chunks would probably fail to apply. > > -- > Alexandre Julliard > julli...@winehq.org >
[PATCH 2/2] winealsa: Fix AudioCaptureClient Get/ReleaseBuffer protocol.
Hi, I forgot to mention that with "winmm: GetCurrentPadding is superfluous while recording" in git, the ALSA patch 82525 can be applied to enforce strict checking of method sequencing: "winealsa: Fix AudioCaptureClient Get/ReleaseBuffer protocol" Regards, Jörg Höhle
Re: [PATCH 1/4] server: Add mechanism to store and retrieve information about a socket (try 2).
On 01/13/2012 12:05 AM, Erich E. Hoover wrote: Real Name: Erich Hoover Changelog: server: Add mechanism to store and retrieve information about a socket. + +/* Get and set user-accessible socket variables */ +@REQ(get_socket_variable) +obj_handle_t handle;/* handle to the socket */ +unsigned int varcode; /* variable to return */ +unsigned int varsize; /* size of variable to return */ +@REPLY +char ok;/* operation status */ +int value; /* returned value of variable */ +@END + +@REQ(set_socket_variable) +obj_handle_t handle;/* handle to the socket */ +unsigned int varcode; /* variable to set */ +unsigned int varsize; /* size of variable to set */ +int value; /* value of variable to set */ +@REPLY +char ok;/* operation status */ +@END You are not using "ok" parameters in either of the calls. You should use status returned by wine_server_call_() for things like that. Also size seems to be redundant here. If it's an int - store it as int on both sides. This also implies you should use an array instead of struct for a storage. And drop size checks. One more thing, keep in mind that time_t is not unsigned int. But long. Vitaliy.
Re: kernel32: Specify the access rights when creating a file object.
Dmitry Timoshkov writes: > Alexandre Julliard wrote: > >> Requiring extra access rights can break things, especially in such >> low-level functions. It's not just a harmless cleanup, so you need to >> either show an app that requires it, or provide a test case that >> demonstrates that the extra accesses are required on Windows too. > > At least one such a test case exists for the file mappings, and actually > making it pass has motivated me for this kind of patches. It shows that > a mapping created with access 0 is not accessible. Since all the objects > on the server side share a single access check mechanism it's impossible > to make one test pass without either changing that single mechanism, or > creating separate access checks for every type of an object. You shouldn't need to change anything to the access check mechanism. An access of 0 of course won't satisfy places that require a specific right. If there are places that don't require a right but should, then you can fix that, with test cases. If fixing that requires the corresponding allocation to add some rights, you can do that at the same time. -- Alexandre Julliard julli...@winehq.org
Re: kernel32: Specify the access rights when creating a file object.
Alexandre Julliard wrote: > Requiring extra access rights can break things, especially in such > low-level functions. It's not just a harmless cleanup, so you need to > either show an app that requires it, or provide a test case that > demonstrates that the extra accesses are required on Windows too. At least one such a test case exists for the file mappings, and actually making it pass has motivated me for this kind of patches. It shows that a mapping created with access 0 is not accessible. Since all the objects on the server side share a single access check mechanism it's impossible to make one test pass without either changing that single mechanism, or creating separate access checks for every type of an object. -- Dmitry.
Re: kernel32: Specify the access rights when creating a file object.
Dmitry Timoshkov writes: >> Alexandre Julliard wrote: >> >> > > While investigating how to fix the file section access tests in kernel32 >> > > I've >> > > found that some places in Wine deliberately create objects with access >> > > rights >> > > set to 0, that leads to creation of potentially not accessible objects. >> > >> > Many of these are deliberate. You'll need test cases to show that you >> > can require more permissions. >> >> In the most cases these patches just add the access rights appropriate for >> particular calls instead of assuming some default ones, that should be a good >> thing to do from a security point of view. Test cases are needed, but only >> to figure out what actual default permissions are provided for 0 access, and >> for file sections the test already exists and shows that defaults access is 0 >> and a not accessible object as a result. Creating objects with access rights >> set to 0 should not be used, and considered a bad practice in general IMO. > > I still would like to see your opinion on the above. > > I see that all these patches are marked now as 'Needs tests'. What exactly > needs > tests for cases > 1. when a file is being opened for reading use access GENERIC_READ instead of > 0? > 2. symblic link object opened for deletion use access DELETE instead of 0? > 3. mapping opject created with GENERIC_READ|GENERIC_WRITE (just like in > another > code patch a couple of lines earlier)? > 4. registry key objects are opened with particular access right like > KEY_QUERY_VALUE > for reading or DELETE for deletion instead of 0? > > The cases listed above are at least a non-consistency if not the bugs IMO, > requring > the tests for them looks strange to me. Requiring extra access rights can break things, especially in such low-level functions. It's not just a harmless cleanup, so you need to either show an app that requires it, or provide a test case that demonstrates that the extra accesses are required on Windows too. -- Alexandre Julliard julli...@winehq.org
Re: kernel32: Specify the access rights when creating a file object.
> Alexandre Julliard wrote: > > > > While investigating how to fix the file section access tests in kernel32 > > > I've > > > found that some places in Wine deliberately create objects with access > > > rights > > > set to 0, that leads to creation of potentially not accessible objects. > > > > Many of these are deliberate. You'll need test cases to show that you > > can require more permissions. > > In the most cases these patches just add the access rights appropriate for > particular calls instead of assuming some default ones, that should be a good > thing to do from a security point of view. Test cases are needed, but only > to figure out what actual default permissions are provided for 0 access, and > for file sections the test already exists and shows that defaults access is 0 > and a not accessible object as a result. Creating objects with access rights > set to 0 should not be used, and considered a bad practice in general IMO. I still would like to see your opinion on the above. I see that all these patches are marked now as 'Needs tests'. What exactly needs tests for cases 1. when a file is being opened for reading use access GENERIC_READ instead of 0? 2. symblic link object opened for deletion use access DELETE instead of 0? 3. mapping opject created with GENERIC_READ|GENERIC_WRITE (just like in another code patch a couple of lines earlier)? 4. registry key objects are opened with particular access right like KEY_QUERY_VALUE for reading or DELETE for deletion instead of 0? The cases listed above are at least a non-consistency if not the bugs IMO, requring the tests for them looks strange to me. -- Dmitry.
Re: [PATCH 1/4] server: Add mechanism to store and retrieve information about a socket (try 2).
"Erich E. Hoover" writes: > Real Name: > Erich Hoover > > Description: > This patch implements storing of internal information about a > socket. The intent for this approach is to add a dynamic mechanism to > permit the storage of various variables that are accessible in user > space, such as storing of the connect() time (part 2). That's ugly, you don't need an arbitrary opaque variable storage mechanism. Just store the connect time and return it as such. Besides, you don't even need to set it from the client side, the server is notified on connect. -- Alexandre Julliard julli...@winehq.org
err:ntdll:RtlDeleteResource Deleting active MRSW lock, expect failure
Hi, Does anyone know about this error? It sometimes occurs on a Linux machine after the mmdevapi capture tests exited, with a delay as if originating from the server (or a service.exe). Some capture logs sent to me contain this too. Looking up bugzilla, you'll find this error mentioned half a dozen times with various apps. Regards, Jörg Höhle
Re: Long translation patch
Gustavo Henrique Milaré writes: > It turns out the patch is very large (around 6500 lines). Sorry if this is > a lame question, but I guess I'll need to break it in 15 patches or so, > right? Should I send all patches in the same day? I don't want to give the > patch reviewers a headache :) If it only touches the po file, a single patch is fine. Just make sure it's relative to the latest git on the day you send it, otherwise some chunks would probably fail to apply. -- Alexandre Julliard julli...@winehq.org
Re: comctl32: Return correct background color
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=16419 Your paranoid android. === WNT4WSSP6 (32 bit treeview) === treeview.c:638: Test failed: Default background color reported as 0x === W2KPROSP4 (32 bit treeview) === treeview.c:638: Test failed: Default background color reported as 0x === WXPPROSP3 (32 bit treeview) === treeview.c:638: Test failed: Default background color reported as 0x === W2K3R2SESP2 (32 bit treeview) === treeview.c:638: Test failed: Default background color reported as 0x === WVISTAADM (32 bit treeview) === treeview.c:638: Test failed: Default background color reported as 0x === W2K8SE (32 bit treeview) === treeview.c:638: Test failed: Default background color reported as 0x === W7PRO (32 bit treeview) === treeview.c:638: Test failed: Default background color reported as 0x === W7PROX64 (32 bit treeview) === treeview.c:638: Test failed: Default background color reported as 0x === TEST64_W7SP1 (32 bit treeview) === treeview.c:638: Test failed: Default background color reported as 0x === W7PROX64 (64 bit treeview) === treeview.c:638: Test failed: Default background color reported as 0x === TEST64_W7SP1 (64 bit treeview) === treeview.c:638: Test failed: Default background color reported as 0x
Re: Vista/w2k8/w7 + ALSA users, please test mmdevapi capture
On Thu, Jan 12, 2012 at 9:50 AM, wrote: > Hi, > > Thanks to all five users who sent me data. > > I've a new testbot job. > Please download mmdevapi_test32|64.exe > http://testbot.winehq.org/JobDetails.pl?Key=16386 > > you don't need a microphone, just a capture capable sound card, unlike > testbot. > > there should be next to 0 failures in lines 200-410. Failures in 411-600 > (function test_capture2) are not interesting. > > It would be good to repeat the test a few times to see whether there's a > random failure. > > Also, please compare > mmdevapi_test[64].exe capture > with > mmdevapi_test[64].exe capture > capture.log > > Redirecting to a file leads to vastly different results (in the render tests) > because > output to the MS-DOS shell is extremely slow and thus affects timing. > > On a 64bit machine, you may also compare the output of both > executables. The behaviour is apparently not the same! You'll find 4 text files with the different possibilities. Each contains data of 5 runs. Matijn capture.c:691: Returned periods: 10. ms 3. ms capture.c:703: pwfx: 006ED3A8 capture.c:704: Tag: fffe capture.c:705: bits: 32 capture.c:706: chan: 2 capture.c:707: rate: 48000 capture.c:708: align: 8 capture.c:709: extra: 22 capture.c:714: Res: 32 capture.c:715: Mask: 3 capture.c:716: Alg: FLOAT capture.c:773: Returned latency: 5. ms capture.c:180: Wait'ed position -1 pad 0 flags abadcafe, amount of frames locked : 0 capture.c:242: Sleep.1 position 0 pad 16800 flags 1, amount of frames locked: 48 0 capture.c:288: GetBufferSize 23941 period size 480 capture.c:298: Overrun position 960 pad 23941 flags 1, amount of frames locked: 480 capture.c:325: Cont'ed position 1440 pad 23461 flags 0, amount of frames locked: 480 capture.c:348: Restart position 1920 pad 22981 flags 0, amount of frames locked: 480 capture.c:377: Reset position -1 pad 0 flags abadcafe, amount of frames locked : 0 capture.c:401: Running position 37440 pad 9120 flags 0, amount of frames locked: 480 capture.c:512: Device position -1 pad 0 flags abadcafe, amount of frames locked: 0 capture.c:516: Test failed: GetNextPacketSize 480 vs. GetBuffer 0 capture.c:572: Device position 46560 pad 17280 flags 0, amount of frames locked: 480 capture.c:580: Test failed: Position 46560 expected 0 capture.c:618: GetBufferSize 23941 period size 480 capture.c:627: Device position 47520 pad 23941 flags 1, amount of frames locked: 480 capture.c:633: Test failed: Position 47520 expected 480 capture: 303 tests executed (0 marked as todo, 3 failures), 0 skipped. D:\Downloads>mmdevapi_test.exe capture capture.c:691: Returned periods: 10. ms 3. ms capture.c:703: pwfx: 0070D3A8 capture.c:704: Tag: fffe capture.c:705: bits: 32 capture.c:706: chan: 2 capture.c:707: rate: 48000 capture.c:708: align: 8 capture.c:709: extra: 22 capture.c:714: Res: 32 capture.c:715: Mask: 3 capture.c:716: Alg: FLOAT capture.c:773: Returned latency: 5. ms capture.c:180: Wait'ed position -1 pad 0 flags abadcafe, amount of frames locked : 0 capture.c:242: Sleep.1 position 0 pad 16800 flags 1, amount of frames locked: 48 0 capture.c:288: GetBufferSize 23941 period size 480 capture.c:298: Overrun position 960 pad 23941 flags 1, amount of frames locked: 480 capture.c:325: Cont'ed position 1440 pad 23461 flags 0, amount of frames locked: 480 capture.c:348: Restart position 1920 pad 23461 flags 0, amount of frames locked: 480 capture.c:377: Reset position -1 pad 0 flags abadcafe, amount of frames locked : 0 capture.c:401: Running position 37920 pad 9120 flags 0, amount of frames locked: 480 capture.c:512: Device position -1 pad 0 flags abadcafe, amount of frames locked: 0 capture.c:516: Test failed: GetNextPacketSize 480 vs. GetBuffer 0 capture.c:572: Device position 47040 pad 17760 flags 0, amount of frames locked: 480 capture.c:580: Test failed: Position 47040 expected 0 capture.c:618: GetBufferSize 23941 period size 480 capture.c:627: Device position 48000 pad 23941 flags 1, amount of frames locked: 480 capture.c:633: Test failed: Position 48000 expected 480 capture: 303 tests executed (0 marked as todo, 3 failures), 0 skipped. D:\Downloads>mmdevapi_test.exe capture capture.c:691: Returned periods: 10. ms 3. ms capture.c:703: pwfx: 00A5D3A8 capture.c:704: Tag: fffe capture.c:705: bits: 32 capture.c:706: chan: 2 capture.c:707: rate: 48000 capture.c:708: align: 8 capture.c:709: extra: 22 capture.c:714: Res: 32 capture.c:715: Mask: 3 capture.c:716: Alg: FLOAT capture.c:773: Returned latency: 5. ms capture.c:180: Wait'ed position -1 pad 0 flags abadcafe, amount of frames locked : 0 capture.c:242: Sleep.1 position 0 pad 16800 flags 1, amount of frames locked: 48 0 capture.c:288: GetBufferSize 23941 period size 480 capture.c:298: Overrun position 960 pad 23941 flags 1, amount of frames locked: 480 capture.c:325: Cont'ed position 1440 pad 23461 flags 0, amount of frames locked: 480 capture.c:348: Restart position 1920 pad 23461 flags 0, amount of frame
