Re: [SETUPAPI] fix bug 1140
Raphael [EMAIL PROTECTED] writes: On Wednesday 16 March 2005 19:57, Alexandre Julliard wrote: This is wrong, comments should have already been taken into account when PARSER_string_substW is called. The right fix is to make GenFormStrWithoutPlaceHolders16 properly split the line like the 32-bit functions do. Ok, and this one ? I think you should take into account quotes and the like. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Problems with VirtualAlloc/Lock
Michael Ost [EMAIL PROTECTED] writes: This should start allocating memory from below 0x4000, to windows processes after the area between 0x4000, to 0x8000, is full, right? That would be nice, but unfortunately it's not what it does. Also even if it worked it wouldn't help for libc allocations, so it would mean that once you have allocated 1Gb you can no longer load builtin dlls. -- Alexandre Julliard [EMAIL PROTECTED]
Re: STI, device drivers and stuff
--- Mike McCormack [EMAIL PROTECTED] wrote: I've noticed that STI.DLL uses the IStiDeviceControl interface, which is defined by the STIUSD.H file I haven't got (it might be part of the Windows DDK or something). Any idea where to find it? I can't see any definition of IStiDeviceControl in the Windows SDK. Where are you seeing stiusd.h? It's in the .NET 2003 MSDN Library documentation, section Windows Development, subsection Device Drivers, somewhere in the still image stuff (I can send you a PDF of it, it's around 30 MB). IStiUSD and IStiDeviceControl are probably part of the Windows DDK (Device Driver Kit), and that you get separately from Microsoft (for a ridiculous price). I'll see if I can get it from the ReactOS people. Does anyone else on this mailing list have the Windows DDK around and a spare stiusd.h they want to share? Mike Damjan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Clipboard regression [proposed patch]
The last patch I sent didn't have a full enough path to dlls/x11drv/clipboard.c On Wed, 2005-03-16 at 14:15 -0700, Ron Jensen wrote: Stefan, You are smarter than me! I completely missed this function. I believe the error is because *visual is 0. I replaced visual with CopyFromParent and it seems to work now. The patch works nice for me! Thanks, Stefan -- SMS bei wichtigen e-mails und Ihre Gedanken sind frei ... Alle Infos zur SMS-Benachrichtigung: http://www.gmx.net/de/go/sms
Re: Suggestion for a couple of additional janitorial projects
On Wed, Mar 16, 2005 at 10:59:09PM +0800, Dmitry Timoshkov wrote: I'd like to suggest to add the following janitorial projects for Wine: 1. Fix Wine to be compilable by a 64-bit compiler 2. Fix wrong assumptions in Wine about endianess. I'd say go for it. -- Dimi.
AW: WineConf: book your hotel now
Hi, there are enough rooms left in the hotel. Please use WineConf as keyword. See you in Stuttgart Hans-Ulrich Schmid Wirtschaftsförderung Region Stuttgart GmbH Stuttgart Region Economic Development Corporation FIR_st - Forum IT-Region Stuttgart Friedrichstr. 10 70174 Stuttgart www.first.region-stuttgart.de www.opensource.region-stuttgart.de www.competenzatlas.de www.region-stuttgart.de Tel ++49.711.22835 - 27 Tel mobil ++49.172.7310463 Fax ++49.711.22835 - 55 -Ursprüngliche Nachricht- Von: Brian Vincent [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 16. März 2005 22:41 An: Paul van Schayck Cc: wine-devel@winehq.org; Hans-Ulrich Schmid Betreff: Re: WineConf: book your hotel now On Wed, 16 Mar 2005 21:08:29 +0100, Paul van Schayck [EMAIL PROTECTED] wrote: They are already completely booked... they replied At this time we have not any rooms this afternoon. This happened a few weeks ago and they did have rooms available. Did you include the keyword WINECON with your reservation request? As far as I know we're still ok - the RSVP list is still slightly less than the number of rooms we've got, plus we know some people on the RSVP list aren't staying there. I'm CC'ing our local contact to see if he can find out what's going on. Hopefully we're still ok on rooms. Mr. Schmid - can you email Paul as well as cc the wine-devel@winehq.org list when you find out? -Brian
Wineconf Agenda
Brian Vincent wrote: I PS - still looking for ideas for the agenda, if you have any, let me know. Also let me know if you'd like to present something. Apart from all of Wine, I'm always interested in the conformance testing. I believe it's crucial in speeding up Wines' development. For each bug found, it is often a good idea to write an automatic regression test. Maybe we can extend on the winetest.exe infrastructure. I would like to see testing done in realtime - we now have a turnaround of maybe 3-4 days for a test developer like myself. I do a tiny, tiny patch, and then wait 3-4 days to see how it behaves on 6 platforms. What I would like to see: a cluster of Windows machines with different versions, all waiting eagerly for a small test.exe to appear. A dispatcher receives tests and then distributes it to waiting Windows machines. As soon as machine has run a test, it is rebooted. Preferrably from a clean vmware image. Mockup example: [EMAIL PROTECTED]:~/src/wine/dlls/kernel/tests$ make testgrid_file i586-mingw32msvc-gcc -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o file.cross.o file.c file.c:1: warning: -fPIC ignored for target (all code is position independent) i586-mingw32msvc-gcc alloc.cross.o atom.cross.o change.cross.o codepage.cross.o comm.cross.o console.cross.o directory.cross.o drive.cross.o environ.cross.o file.cross.o format_msg.cross.o generated.cross.o heap.cross.o locale.cross.o module.cross.o mailslot.cross.o path.cross.o pipe.cross.o process.cross.o profile.cross.o thread.cross.o time.cross.o timer.cross.o virtual.cross.o testlist.cross.o -o kernel32_crosstest.exe -lkernel32 i586-mingw32msvc-strip kernel32_crosstest.exe upx kernel32_crosstest.exe gpg --sign kernel32_crosstest.exe kernel32_crosstest.sig tar -cf kernel32_crosstest.tar kernel32_crosstest.exe kernel32_crosstest.sig wget http://testgrid.winehq.org/gridtest.cgi --post-file=kernel32_crosstest.tar --output-document=testgrid_file.txt [EMAIL PROTECTED]:~/src/wine/dlls/kernel/tests$ [EMAIL PROTECTED]:~/src/wine/dlls/kernel/tests$ [EMAIL PROTECTED]:~/src/wine/dlls/kernel/tests$ cat testgrid_file.txt Windows 2000 begin: file.c:1384: Test failed: DeleteFileA: error 3 file: 487732 tests executed, 0 marked as todo, 1 failure. End Windows 2000. Windows 98 begin: file.c:804: Test failed: MoveFileA: unexpected error 3 file.c:1384: Test failed: DeleteFileA: error 3 file: 487732 tests executed, 0 marked as todo, 2 failures. End Windows 98. Windows XP begin: file: 487732 tests executed, 0 marked as todo, 0 failures. End Windows XP. Windows NT4 begin: file: 487732 tests executed, 0 marked as todo, 0 failures. End Windows NT4. [EMAIL PROTECTED]:~/src/wine/dlls/kernel/tests$ [EMAIL PROTECTED]:~/src/wine/dlls/kernel/tests$ [EMAIL PROTECTED]:~/src/wine/dlls/kernel/tests$ regards, Jakob
Re: SHELL32: use structure defined in standard headers for advertised shortcut info
Mike Hearn wrote: On Wed, 16 Mar 2005 12:12:47 +0900, Mike McCormack wrote: We only implement the first 4. Some of those are only needed by Explorer/the shell though, I doubt it's necessary to implement them to run the apps (unless you want to run Explorer of course :) Yes, probably, but what about the Explorer replacements like Directory Opus and Total Commander, anybody ran those in Wine? regards, Jakob
Re: Enhancing winetest infrastructure [WAS: Wineconf agenda]
Paul Millar wrote: On Thursday 17 March 2005 10:33, Jakob Eriksson wrote: Apart from all of Wine, I'm always interested in the conformance testing. I believe it's crucial in speeding up Wines' development. For each bug found, it is often a good idea to write an automatic regression test. Yes, although that's a rather weary job, which no one enjoys doing :^/ I do! Maybe I have a condition, but I really love doing it! :-) There's three issues here: Yes. o fast(er) update of CVS (or whatever filestore we're using). This would need either: * a super-charged Alexandre ;) or * a separate CVS tree in which developers can edit the wine/dlls/*/tests/ directory, This makes sense. Winetest could actually be a separate project. I'm not saying it should be, mind you, just that conformance testing is interesting not only for Wine, but for Windows developers in general. So a separate CVS tree makes a great deal of sense, IMHO. Wine could import snapshots of the tests for its' conformance testing. This could speed up test development considerably, I imagine. or * give up on centralised/distributed testing architecture and switch to a personal testing environment. o fast(er) build of winetest.exe I originally argued for async. winetests and went as far as implementing this as part of WRT, so in principles this is already done. WRT worked based on the email notification of CVS updates. Builds, with minor changes, doesn't take long (using ccache), so you're probably looking 10-20 minutes turn around, with whatever delay the test-clients introduce. Though, without fixing the first issue, this doesn't help us much. o fast(er) running, through vmware platforms. Sure, this can be done, but its a distributed model, so everyone can chip in. Shouldn't be too difficult to achieve this. Sounds like fun, doesn't it? Test servers could register in the cluster worldwide. (Although I originally imagined a very centralized solution with a big server running vmware images.) Just my 2-c worth :) Are you coming to wineconf? regards, Jakob
wineconf agenda
Brian Vincent wrote: PS - still looking for ideas for the agenda, if you have any, let me know. Also let me know if you'd like to present something. Will anyone demo CXtest? I think it would be great. http://www.cxtest.org/ regards, Jakob
Enhancing winetest infrastructure [WAS: Wineconf agenda]
On Thursday 17 March 2005 10:33, Jakob Eriksson wrote: Apart from all of Wine, I'm always interested in the conformance testing. I believe it's crucial in speeding up Wines' development. For each bug found, it is often a good idea to write an automatic regression test. Yes, although that's a rather weary job, which no one enjoys doing :^/ Maybe we can extend on the winetest.exe infrastructure. I would like to see testing done in realtime [...] There's three issues here: o fast(er) update of CVS (or whatever filestore we're using). This would need either: * a super-charged Alexandre ;) or * a separate CVS tree in which developers can edit the wine/dlls/*/tests/ directory, or * give up on centralised/distributed testing architecture and switch to a personal testing environment. o fast(er) build of winetest.exe I originally argued for async. winetests and went as far as implementing this as part of WRT, so in principles this is already done. WRT worked based on the email notification of CVS updates. Builds, with minor changes, doesn't take long (using ccache), so you're probably looking 10-20 minutes turn around, with whatever delay the test-clients introduce. Though, without fixing the first issue, this doesn't help us much. o fast(er) running, through vmware platforms. Sure, this can be done, but its a distributed model, so everyone can chip in. Shouldn't be too difficult to achieve this. Just my 2-c worth :) Paul. pgpaeq8nAuEBd.pgp Description: PGP signature
Re: STI, device drivers and stuff
Damjan Jovanovic wrote: I'll see if I can get it from the ReactOS people. Does anyone else on this mailing list have the Windows DDK around and a spare stiusd.h they want to share? Are you planning to write an STI mini-driver or just trying to load one? I don't think you'll have much success trying to load one, and I'm not sure you need to write one. I would have imagined that you implement IStillImage as returned by sti.StiCreateInstance() : IStillImage::GetDeviceList will enumerate all the V4L devices available. IStillImage::CreateDevice will open one and return an IStiDevice interface associated with one V4L device. IStillDevice::RawReadData will read stuff from the V4L device. Why are mini-drivers needed? Mike
Re: Enhancing winetest infrastructure [WAS: Wineconf agenda]
Jakob Eriksson wrote: Maybe one could script something up so that a commit to tests CVS would not be *possible* without a confirmed test pass on Windows 95, NT, 2000 and XP. That would be very hard to do and mostly pointless for drivers. Ivan.
Re: ole32: begin implementing IPropertyStorage
Juan Lang [EMAIL PROTECTED] writes: This is getting big enough I might as well float a patch by. ChangeLog: start of implementation of IPropertyStorage This breaks the tests: storage32.c:481: Test failed: failed to create property set storage storage32.c:489: Test failed: failed to create property set storage storage32.c:496: Test failed: open failed storage32.c:534: Test failed: ref count wrong storage32.c:537: Test failed: ref count wrong make[1]: *** [storage32.ok] Error 5 -- Alexandre Julliard [EMAIL PROTECTED]
Re: wineconf agenda
Will anyone demo CXtest? I think it would be great. http://www.cxtest.org/ I think that's one of those topics that Brian is holding in reserve; we'll be more than happy to demo it. Jer
Re: wineconf agenda
Hi, On Thu, Mar 17, 2005 at 08:35:25AM -0600, Jeremy White wrote: Will anyone demo CXtest? I think it would be great. http://www.cxtest.org/ I think that's one of those topics that Brian is holding in reserve; we'll be more than happy to demo it. Nice stuff! Will you have decided by then whether to call it CXtest, Cxtest, CxTest or CXTEST? ;-) (YES, I've seen all of those!) Andreas
Re: Enhancing winetest infrastructure [WAS: Wineconf agenda]
On Thursday 17 March 2005 11:54, Jakob Eriksson wrote: Maybe one could script something up so that a commit to tests CVS would not be *possible* without a confirmed test pass on Windows 95, NT, 2000 and XP. That'd be the best thing since sliced bread. CVS supports doing some server-side validation tests before accepting a commit, so it could be done; but I don't think this would be nice. CVS is a mechanism for sharing code: its not really a testing framework. There would be potential issues with CVS locking, timeouts (e.g. what happens if the XP machine dies?), but the real issue is it would just gets in the way of developers by making the CVS server fragile. For the testing framework, I'd say what we have just now is fine. It lives outside (and on top of) CVS. Having broken tests is OK, provided they're fixed within a suitable time-scale [*]. (just my 2c-worth again) Cheers, Paul [*] -- Of course, what is the suitable time-scale? who's willing to make sure things get fixed? pgpaMsk6vte8H.pgp Description: PGP signature
Re: Enhancing winetest infrastructure [WAS: Wineconf agenda]
Ivan Leo Puoti wrote: Jakob Eriksson wrote: Maybe one could script something up so that a commit to tests CVS would not be *possible* without a confirmed test pass on Windows 95, NT, 2000 and XP. That would be very hard to do and mostly pointless for drivers. Sometimes hard is worthwile. At least to me. regards, Jakob
Re: Enhancing winetest infrastructure [WAS: Wineconf agenda]
On Thursday 17 March 2005 11:51, Jakob Eriksson wrote: Paul Millar wrote: [writing tests]'s a rather weary job, which no one enjoys doing :^/ I do! Maybe I have a condition, but I really love doing it! :-) Long may that continue! [...] [separate CVS tree] This makes sense. Winetest could actually be a separate project. I'm not saying it should be, mind you, just that conformance testing is interesting not only for Wine, but for Windows developers in general. So a separate CVS tree makes a great deal of sense, IMHO. Wine could import snapshots of the tests for its' conformance testing. This could speed up test development considerably, I imagine. I'd tread careful here: this isn't a panacea. Yes, its fairly easy to *say* OK, we just merge in the new tests, but would merging the snapshots really be a trivial job? If it is non-trivial, then Alexandre would front at least some of it and I suspect making more work for Alexandre is the last thing anyone (including Alexandre :^) would want. On top of that, there would be many other issues, e.g. How the diffs between the two trees were presented? How the changes in wine would be merged back into the winetest tree? What happens to patches that Alexandre rejects (coz they're just wrong)? Ultimately, its Alexandre's call (and I think I can guess his answer). [...] Are you coming to wineconf? All things being equal, yes. Cheers, Paul. pgpJPmyTe9YX6.pgp Description: PGP signature
Re: Enhancing winetest infrastructure [WAS: Wineconf agenda]
Paul Millar wrote: On Thursday 17 March 2005 11:51, Jakob Eriksson wrote: Paul Millar wrote: [writing tests]'s a rather weary job, which no one enjoys doing :^/ I do! Maybe I have a condition, but I really love doing it! :-) Long may that continue! Thanks, I hope so too! :-) Only my day job and things like planning a marriage stops me from digging deep into Wine testing. [..] I'd tread careful here: this isn't a panacea. Yes, its fairly easy to *say* OK, we just merge in the new tests, but would merging the snapshots really be a trivial job? If it is non-trivial, then Alexandre would front at least some of it and I suspect making more work for Alexandre is the last thing anyone (including Alexandre :^) would want. Ouch. Of course, should have thought of that. Maybe we need a patch penguin? regards, Jakob
Re: wineconf agenda
A bit OT, well kinda. I'm trying to stabilize offscreen rendering in DirectX 9, I know Jason was thinking of doing a demo. Is there going to be another wine release before wine conf so I can merge DirectX and do you still plan to do a demo Jason, if so what are you time-lines for something stable? for anyone who's interested Offscreen rendering is hitting state blocks quite a bit, since stateblocks is next on my list of patches to merge with wine I thought it would be a good idea to do some work upfront instead of sending in lots of patches that change things around a lot. ICQ 169222899 MSN [EMAIL PROTECTED] pgp0l8VqiuhSL.pgp Description: PGP signature
Re: Enhancing winetest infrastructure [WAS: Wineconf agenda]
On Thu, 17 Mar 2005, Jakob Eriksson wrote: Ouch. Of course, should have thought of that. Maybe we need a patch penguin? CVS actually handles 'vendor branches' fairly nicely. It should be possible for Jakob (or whoever else decides to be the 'test penguin') to maintain his own 'testing' CVS tree, with rapid development, etc, and periodically resync his own tree to canonical Wine CVS (using the vendor branch functionality) and then create large-ish 'tests-only' chunks from that to throw at Alexandre once in a while. There really shouldn't be much reason for Alexandre to reject patches that touch tests only; after all, if the tests pass on windows, they should pass on wine, no matter how evil they look. (Well, within reason.) That's MHO, at least. If I understand correctly, the primary reason for the 'testing' CVS is just to manage distribution of proposed tests to a server farm of test-runners; which is slightly different from the purpose of the mainline CVS tree. [Also -- a decoupled 'testing' CVS like I describe above can be implemented by the motivated folks w/o Alexandre's involvement at all, which permits judgements to be postponed until we've got some evidence of usefulness.] In this vein -- where *is* the current testing infrastructre located? I'm pretty new to Wine, and I couldn't find any links from winehq. [These should probably be added, or made more visible if they do exist, especially if the goal is to encourage test submission with patch submission.] --scott LIONIZER class struggle SCRANGER ESGAIN overthrow GRALLSPICE UKUSA tonight EZLN Sudan NSA KMFLUSH PBPRIME mail drop Leitrim IDEA AELADLE ( http://cscott.net/ )
Re: [WINEALSA] use real name for wave also
Robert Reif wrote: Use real names for wave device also. Please disregard this patch. I will present a better one shortly.
Re: STI, device drivers and stuff
IStiDeviceControl are probably part of the Windows DDK (Device Driver Kit), and that you get separately from Microsoft (for a ridiculous price). It's a free CD. You pay only for shipping. If you want, I've got two of those and can transfer one of them to be taken care of by the wine folks. As long as it's a US address, that is. Cheers, Kuba
animate control regression
The current CVS version has a regression in the animate control, causing
a deadlock, most probably in WM_DESTROY handler, in the app I'm testing
Wine with.
trace:message:SPY_ExitMessage (0x10038) L{SysAnimate32} message
[0047] WM_WINDOWPOSCHANGED returned
trace:message:SPY_EnterMessage (0x10038) L{SysAnimate32} message
[0002] WM_DESTROY sent from self wp= lp=
err:ntdll:RtlpWaitForCriticalSection section 0x403a3cb8 ? wait timed
out in thread 0009, blocked by 000a, retrying (60 sec)
Reversing these two patches seems to fix the problem:
http://cvs.winehq.org/patch.py?id=16654
http://cvs.winehq.org/patch.py?id=16619
I don't know if patch 16654 has any effect on this problem - I don't
know this code well enough to reverse patches in random order.
Hope it isn't difficult to fix...
Krzysztof
Re: Enhancing winetest infrastructure [WAS: Wineconf agenda]
Paul Millar wrote: On Thursday 17 March 2005 11:54, Jakob Eriksson wrote: Maybe one could script something up so that a commit to tests CVS would not be *possible* without a confirmed test pass on Windows 95, NT, 2000 and XP. That'd be the best thing since sliced bread. CVS supports doing some server-side validation tests before accepting a commit, so it could be done; but I don't think this would be nice. CVS is a mechanism for sharing code: its not really a testing framework. I didn't mean exactly on the CVS level. When Alexandre commits any patch, he first checks that the code still passes regression tests. I want something similar for the test patches. Maybe like this: the testing dispatcher signs a working patch* with GPG. (Or no GPG. Just set a flag somewhere. Details are not important.) Alexandre will see this flag when saving a patch from [EMAIL PROTECTED] and know that the patch is OK as far as the test grid is concerned. It could be as non-intrusive as this: the test dispatcher monitors the [EMAIL PROTECTED] for patches. As soon as it sees a patch it recognises and knows it has tested, it sends a mail to wine-patches akin to: The patch with CRC32 so-and-so posted by him or her, named so-and-so is hereby verified by me, the Wine Regression Grid Tester. ** or The patch with CRC32 so-and-so posted by him or her, named so-and-so failed under the following versions of Windows; bla bla blah, with the following error message: blah blah bla some more. Truthfully yours, the Wine Regression Grid Tester. ** Then it's up to Alexandre if he wants to commit a test which the grid tester has rejected, or for which there is no confirmation. If you don't like the idea of a program spamming wine-patches, it could be separate list, or a webpage with a copy of wine-patches, with different messages colour-codes updated as they get tested by the grid tester. * A working patch is a patch that has been tested and found working on Win 95, 98, ME, NT4, 2000 and XP. ** Could we call it WineGrind? :-) For the testing framework, I'd say what we have just now is fine. It lives outside (and on top of) CVS. Having broken tests is OK, provided they're fixed within a suitable time-scale [*]. Actually, I think having broken tests is not OK. It not only goes against my zealotry for Extreme Programming, it's also very annoying when I have _no_clue_ how to fix a broken test and the author is missing or don't want to touch the code with a ten foot stick. (just my 2c-worth again) Cheers, Paul [*] -- Of course, what is the suitable time-scale? who's willing to make sure things get fixed? Exactly, I feel rage everytime I see those red and yellow boxes at http://test.winehq.org/data/ ;-) regards, Jakob
Re: Enhancing winetest infrastructure [WAS: Wineconf agenda]
C. Scott Ananian wrote: On Thu, 17 Mar 2005, Jakob Eriksson wrote: Ouch. Of course, should have thought of that. Maybe we need a patch penguin? CVS actually handles 'vendor branches' fairly nicely. It should be possible for Jakob (or whoever else decides to be the 'test penguin') to maintain his own 'testing' CVS tree, with rapid development, etc, and periodically resync his own tree to canonical Wine CVS (using the vendor branch functionality) and then create large-ish 'tests-only' chunks from that to throw at Alexandre once in a while. There really shouldn't be much reason for Alexandre to reject patches that touch tests only; after all, if the tests pass on windows, they should pass on wine, no matter how evil they look. (Well, within reason.) That's MHO, at least. If I understand correctly, the primary reason for the 'testing' CVS is just to manage distribution of proposed tests to a server farm of test-runners; which is slightly different from the purpose of the mainline CVS tree. [Also -- a decoupled 'testing' CVS like I describe above can be implemented by the motivated folks w/o Alexandre's involvement at all, which permits judgements to be postponed until we've got some evidence of usefulness.] Yes. And I think I can implement most of even the more elaborate schemes without initially disturbing Alexandre or anyone else. As you say, until we get more evidence of usefulness. In this vein -- where *is* the current testing infrastructre located? I'm pretty new to Wine, and I couldn't find any links from winehq. [These should probably be added, or made more visible if they do exist, especially if the goal is to encourage test submission with patch submission.] http://test.winehq.org/data/ regards, Jakob
ddraw correctness fixes patch
anyone know why this patch hasn't been accepted? http://www.winehq.org/hypermail/wine-patches/2005/03/0328.html Tom
Re: animate control regression
On Thu, Mar 17, 2005 at 10:31:24PM +0100, Krzysztof Foltman wrote:
The current CVS version has a regression in the animate control, causing
a deadlock, most probably in WM_DESTROY handler, in the app I'm testing
Wine with.
We should just get rid of the thread and the critical section altogether,
comctl32 6.0 is documented not to support it anymore. But before we do
that, let's try to fix this, so we have good code in CVS :)
Here is a patch completely untested (just got home at 1am, and my tree
doesn't currently build due to other problems). Can you try it out?
Index: dlls/comctl32/animate.c
===
RCS file: /var/cvs/wine/dlls/comctl32/animate.c,v
retrieving revision 1.63
diff -u -r1.63 animate.c
--- dlls/comctl32/animate.c 16 Mar 2005 19:47:52 - 1.63
+++ dlls/comctl32/animate.c 18 Mar 2005 06:00:39 -
@@ -353,15 +353,12 @@
TRACE(Drawing frame %d (loop %d)\n, infoPtr-currFrame, infoPtr-nLoop);
-EnterCriticalSection(infoPtr-cs);
-
mmioSeek(infoPtr-hMMio, infoPtr-lpIndex[infoPtr-currFrame], SEEK_SET);
mmioRead(infoPtr-hMMio, infoPtr-indata,
infoPtr-ash.dwSuggestedBufferSize);
if (infoPtr-hic
fnIC.fnICDecompress(infoPtr-hic, 0, infoPtr-inbih, infoPtr-indata,
infoPtr-outbih, infoPtr-outdata) != ICERR_OK) {
- LeaveCriticalSection(infoPtr-cs);
WARN(Decompression error\n);
return FALSE;
}
@@ -373,13 +370,9 @@
if (infoPtr-currFrame++ = infoPtr-nToFrame) {
infoPtr-currFrame = infoPtr-nFromFrame;
- if (infoPtr-nLoop != -1) {
- if (--infoPtr-nLoop == 0) {
- ANIMATE_DoStop(infoPtr);
- }
- }
+ if (infoPtr-nLoop != -1)
+ infoPtr-nLoop--;
}
-LeaveCriticalSection(infoPtr-cs);
return TRUE;
}
@@ -400,6 +393,16 @@
return 0;
}
+static LRESULT ANIMATE_Timer(ANIMATE_INFO *infoPtr)
+{
+ANIMATE_DrawFrame(infoPtr);
+
+if (infoPtr-nLoop == 0)
+ANIMATE_DoStop(infoPtr);
+
+return 0;
+}
+
static DWORD CALLBACK ANIMATE_AnimationThread(LPVOID ptr_)
{
ANIMATE_INFO *infoPtr = (ANIMATE_INFO *)ptr_;
@@ -414,6 +417,9 @@
event = infoPtr-hStopEvent;
LeaveCriticalSection(infoPtr-cs);
+if (infoPtr-nLoop == 0)
+ANIMATE_DoStop(infoPtr);
+
/* time is in microseconds, we should convert it to milliseconds */
if ((event == 0) || WaitForSingleObject( event, (timeout+500)/1000) ==
WAIT_OBJECT_0)
break;
@@ -863,7 +869,6 @@
return 0;
}
-
static LRESULT WINAPI ANIMATE_WindowProc(HWND hWnd, UINT uMsg, WPARAM wParam,
LPARAM lParam)
{
ANIMATE_INFO *infoPtr = (ANIMATE_INFO *)GetWindowLongPtrW(hWnd, 0);
@@ -905,7 +910,7 @@
return ANIMATE_StyleChanged(infoPtr, wParam, (LPSTYLESTRUCT)lParam);
case WM_TIMER:
-return ANIMATE_DrawFrame(infoPtr);
+return ANIMATE_Timer(infoPtr);
case WM_PAINT:
/* the animation isn't playing, or has not decompressed
--
Dimi.
Re: OLE32: Allow STGM_SHARE_EXCLUSIVE for nameless storage files
Actually, I think the test is just the wrong way round. It should read if (STGM_SHARE_MODE(grfMode) != STGM_SHARE_EXCLUSIVE) I screwed it up in the following commit: http://cvs.winehq.org/cvsweb/wine/dlls/ole32/storage32.c.diff?r1=1.71r2=1.72f=h Mike Troy Rollo wrote: StgOpenStorage was failing if pwcsName was NULL and the share flags were STGM_SHARE_EXCLUSIVE. It shouldn't (Windows allows this). ChangeLog: Allow STGM_SHARE_EXCLUSIVE for StgOpenStorage with pwcsName == NULL -if (STGM_SHARE_MODE(grfMode) == STGM_SHARE_EXCLUSIVE) - goto end; -
