Re: msvcrt: do not overlap in strcpy (valgrind) (try 2)
André Hentschel wrote: > > diff --git a/dlls/msvcrt/math.c b/dlls/msvcrt/math.c > index 010e1a6..08eaf73 100644 > --- a/dlls/msvcrt/math.c > +++ b/dlls/msvcrt/math.c > @@ -856,7 +856,7 @@ char * CDECL _ecvt( double number, int ndigits, int > *decpt, int *sign ) > snprintf(data->efcvt_buffer, 80, "%.*le", prec - 1, number); > /* take the decimal "point away */ > if( prec != 1) > -strcpy( data->efcvt_buffer + 1, data->efcvt_buffer + 2); > +memmove( data->efcvt_buffer + 1, data->efcvt_buffer + 2, > strlen(data->efcvt_buffer) ); You don't need additional strlen. You already have a length from snprintf (that's returned but not assigned to anything). Vitaliy.
Re: comctl32/tests: make v6 functions inline
2009/10/31 André Hentschel : > So that there are no warnings if tests only use the constant variables in > that header. > --- > dlls/comctl32/tests/v6util.h | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/comctl32/tests/v6util.h b/dlls/comctl32/tests/v6util.h > index 21a8e4f..ae3dbbe 100644 > --- a/dlls/comctl32/tests/v6util.h > +++ b/dlls/comctl32/tests/v6util.h > @@ -56,7 +56,7 @@ static const CHAR manifest[] = > "\n" > "\n"; > > -static void unload_v6_module(ULONG_PTR cookie) > +static inline void unload_v6_module(ULONG_PTR cookie) > You're using old source tree. Current prototype is: --- static void unload_v6_module(ULONG_PTR cookie, HANDLE hCtx) --- Why do you need such changes? I don't think inline it's useful here.
Re: [PATCH 0/3] Handling DOS drives in mountmgr (try 2)
Charles Davis wrote: > Hi, > > This patch series moves drive handling over to mountmgr. Mountmgr will > now associate UNIX device files directly to its created devices instead > of having ntdll handle converting something like \??\D: to > $WINEPREFIX/dosdevices/d::. This way, we can implement storage I/O > controls in mountmgr instead of ntdll, while the storage I/O controls > already in ntdll continue to work. > > It also allows drivers to associate UNIX device files to their device > objects, paving the way for separating the driver code from ntdll. > > Since nobody's said anything about my patches, I'll have to assume > they're good. (They work for me.) > > Chip > > I thought I fixed all the issues. What's wrong with my patches now? Chip
Re: Implement source alpha plus SourceConstantAlpha combined transparency.
Jaime Rave wrote: Anything wrong with this patch?? It helps a lot in MSN Messenger and some other programs. http://www.winehq.org/pipermail/wine-patches/2009-October/080539.html Jaime Rave Torrres It looks like your patch does two separate things. You should always break your patches up to solve one specific problem each. Among other things, this makes regression testing easier. I'm not familiar with the code you're modifying, but if it's possible to test the behavior you're correcting via the Windows API, please write tests to do so. Since you're modifying winex11.drv, you'll want to look into other areas of Wine that are affected by this change. Perhaps some image loading function in another module can be used to verify the behavior. 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. Good luck, Andrew
Implement source alpha plus SourceConstantAlpha combined transparency.
Anything wrong with this patch?? It helps a lot in MSN Messenger and some other programs. http://www.winehq.org/pipermail/wine-patches/2009-October/080539.html Jaime Rave Torrres
Re: [PATCH] MSI: Shedule rename operation also for ERROR_USER_MAPPED_FILE.
On Friday 30 October 2009 14:10:27 Michael Martin wrote: > Add check for ERROR_USER_MAPPED_FILE in addition to ERROR_SHARING_VIOLATION > when scheduling a rename operation. ERROR_USER_MAPPED_FILE can be set when > trying to overwrite true type fonts in windows. > For more info see http://support.microsoft.com/kb/944507 Which installer is affected by this? -Hans
Re: Order of setting audio Play/Pause state and device opening
On Oct 29, 2009, at 9:18 AM, > wrote: In audio.c/wodPause: /* The order of the following operations is important since we can't hold * the mutex while we make an Audio Unit call. Stop the Audio Unit before * setting the PAUSED state. That's indeed what the code below does. * Although we can be in PAUSED * state with the Audio Unit still running, Quite to the contrary, PAUSED state is only set after the unit stopped. * that's harmless because the * render callback will just produce silence. I can't comment on that. The code is (error checking not shown): status = AudioOutputUnitStop(wwo->audioUnit); OSSpinLockLock(&wwo->lock); if (wwo->state == WINE_WS_PLAYING) wwo->state = WINE_WS_PAUSED; OSSpinLockUnlock(&wwo->lock); In audio.c/wodRestart: * In wodRestart, the order is reversed. Indeed. * This guarantees that we can't get into a situation where the state is * PLAYING but the Audio Unit isn't running. Quite to the contrary, PLAYING state is reached yet AudioOutputUnitStart is only called a few instructions afterwards. Likewise above, it's stopped and PLAYING state is only unset afterwards. OSSpinLockLock(&wwo->lock); if (wwo->state == WINE_WS_PAUSED) wwo->state = WINE_WS_PLAYING; OSSpinLockUnlock(&wwo->lock); status = AudioOutputUnitStart(wwo->audioUnit); Is my understanding wrong? Does the code need be changed to reflect the comments? Do the comments need correction? The comments could probably use clarification. The guarantee is meant to hold with respect to two separate threads racing -- one is doing wodPause, the other wodRestart. We want it to be impossible for that scenario to leave the audio unit stopped but the state as PLAYING. It's acceptable for the audio unit to be left running but the state as PAUSED. The difficulty is that we can't hold the lock on the wave-out instance while we call AudioOutputUnitStop/Start. The Audio Unit calls have their own mutex, so those two calls are guaranteed to be atomic with respect to each other. And we use wwo->lock to make sure that the state updates are atomic with respect to each other. But we can't make the entirety of wodPause atomic with respect to wodRestart, or vice versa, because it would deadlock. So, the solution is to use careful ordering of actions. The possible sequences are: 1) Thread A: au stop Thread A: state -> PAUSED Thread B: state -> PLAYING Thread B: au start Result: PLAYING and au running 2) Thread A: au stop Thread B: state -> PLAYING Thread A: state -> PAUSED Thread B: au start Result: PAUSED and au running (acceptable, though not ideal) 3) Thread A: au stop Thread B: state -> PLAYING Thread B: au start Thread A: state -> PAUSED Result: PAUSED and au running (ditto) 4) Thread B: state -> PLAYING Thread A: au stop Thread A: state -> PAUSED Thread B: au start Result: PAUSED and au running (ditto) 5) Thread B: state -> PLAYING Thread A: au stop Thread B: au start Thread A: state -> PAUSED Result: PAUSED and au running (ditto) 6) Thread B: state -> PLAYING Thread B: au start Thread A: au stop Thread A: state -> PAUSED Result: PAUSED and au not running Regards, Ken
Re: wined3d: recognize Nvidia 8500 GT
On Fri, Oct 30, 2009 at 3:35 AM, Roderick Colenbrander wrote: > We use this mechanism on purpose. We can't have hundreds of cards in > the database. The real name isn't that important it is mostly > cosmetic, so it is not a real bug. It's not that important to me. It seems to me that the reason for not having a ton of cards is the work in implementing the database, not maintaining it. If it's not going to go in, then the bug should be marked WONTFIX instead of silently ignored. -- -Austin
Re: mshtml/tests: Fix events test when pointer is on a corner.
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, Jacek
Re: mshtml/tests: Fix events test when pointer is on a corner.
2009/10/30 Jacek Caban : > Hi Nicolas, > > Nicolas Le Cam wrote: >> >> Hi, >> >> Since commit 8272ecd3f2235b923f2ec67bb51d051bdfbf466f I'm having >> errors on events tests. >> >> I just found that it only fails if pointer is on any corner. As I'm >> always putting it on upper right corner when running winetest it was >> always failing for me. >> >> Minimizing the test window fixed it for me. >> Tested on Win2k SP4 and WinXP SP2 (both with IE6). >> > > Minimizing window changes what we test and will break test interactive mode. > We should change tests to accept cursor in left corner. > > > Thanks, > Jacek > > > 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 ? -- Nicolas Le Cam
Re: mshtml/tests: Fix events test when pointer is on a corner.
Hi Nicolas, Nicolas Le Cam wrote: Hi, Since commit 8272ecd3f2235b923f2ec67bb51d051bdfbf466f I'm having errors on events tests. I just found that it only fails if pointer is on any corner. As I'm always putting it on upper right corner when running winetest it was always failing for me. Minimizing the test window fixed it for me. Tested on Win2k SP4 and WinXP SP2 (both with IE6). Minimizing window changes what we test and will break test interactive mode. We should change tests to accept cursor in left corner. Thanks, Jacek
Re: kernel32/tests: add more tests for Formatmessage{A,W} (try 2)
Hi Louis, These new tests introduce some test failures on several platforms: http://test.winehq.org/data/tests/kernel32:format_msg.html On Win9x/WinMe it seems like just another last error. There seems to be an issue with a particular test when run on a Windows box with no English locale (or something different about the locale): http://test.winehq.org/data/1be99033b1892aa59589e7997f4c5a0ce77e2b42/2000_w2k-sp4-fr/kernel32:format_msg.html On Vista/Win7/W2K8 there are also different last errors but some are not yet defined in our headers: 15100 : ERROR_MUI_FILE_NOT_FOUND 15105 : ERROR_MUI_FILE_NOT_LOADED Could you have a look? I'll have a look , but probably not today, but in weekend. Regards
Re: libsmbclient and wine?
On Friday 23 October 2009 22:26:49 Dan Kegel wrote: > 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? Reading files from remote systems via UNC paths would come to mind, as well as NBT lookups. > - Would it suffice to just link it in to wineserver, or would > it need to be invoked directly by all sorts of dlls? For the UNC path part, we need the logic in the redirector, which probably should be located in the wineserver. For the NBT part, this needs to be called from netapi32. We might be able to do nbt lookups via an LGPL library via winbind, though. The catch is of course that we'd have to have a running winbindd for that. > - Would we just use the system's libsmbclient (I hope so) > rather than trying to import its source? We'd use the system library. > 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. Technically, we (wearing my Samba hat) will have to implement something that'll allow multiplexing the named pipe handling in one of our daemons. But from our last conversation on the subject, we seem to be ready to do that if needed. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: kernel32/tests: add more tests for Formatmessage{A,W} (try 2)
2009/10/30 Paul Vriens : > On 10/29/2009 01:09 AM, Louis Lenders wrote: >> >> changes: >> >> -fixed typo in ok-call >> -removed FormatMessageW-tests (W behaves same as A) >> -removed useless test for GetLastError in case FormatMessageA succeeds >> >> > > Hi Louis, > > These new tests introduce some test failures on several platforms: > > http://test.winehq.org/data/tests/kernel32:format_msg.html > > On Win9x/WinMe it seems like just another last error. > > There seems to be an issue with a particular test when run on a Windows box > with no English locale (or something different about the locale): > > http://test.winehq.org/data/1be99033b1892aa59589e7997f4c5a0ce77e2b42/2000_w2k-sp4-fr/kernel32:format_msg.html > > On Vista/Win7/W2K8 there are also different last errors but some are not yet > defined in our headers: > > 15100 : ERROR_MUI_FILE_NOT_FOUND > 15105 : ERROR_MUI_FILE_NOT_LOADED > > Could you have a look? > > -- > Cheers, > > Paul. > > > w2k-sp4-fr has French locale. I didn't have time to investigate right now but if you need more tests just ask. -- Nicolas Le Cam
Re: wined3d: recognize Nvidia 8500 GT
We use this mechanism on purpose. We can't have hundreds of cards in the database. The real name isn't that important it is mostly cosmetic, so it is not a real bug. Roderick
Re: kernel32/tests: add more tests for Formatmessage{A,W} (try 2)
On 10/29/2009 01:09 AM, Louis Lenders wrote: changes: -fixed typo in ok-call -removed FormatMessageW-tests (W behaves same as A) -removed useless test for GetLastError in case FormatMessageA succeeds Hi Louis, These new tests introduce some test failures on several platforms: http://test.winehq.org/data/tests/kernel32:format_msg.html On Win9x/WinMe it seems like just another last error. There seems to be an issue with a particular test when run on a Windows box with no English locale (or something different about the locale): http://test.winehq.org/data/1be99033b1892aa59589e7997f4c5a0ce77e2b42/2000_w2k-sp4-fr/kernel32:format_msg.html On Vista/Win7/W2K8 there are also different last errors but some are not yet defined in our headers: 15100 : ERROR_MUI_FILE_NOT_FOUND 15105 : ERROR_MUI_FILE_NOT_LOADED Could you have a look? -- Cheers, Paul.
