December 2006 - Wine-Devel - list.winehq.org

Re: OpenGL as child windows

by Chris Robinson

On Sunday 31 December 2006 11:44, Mark Hatsell wrote: > Just wondered what would happen in the case of a non-X11 child window > partially overlapping an X11 OpenGL window? I guess this wouldn't work > still even with this solution. This could happen quite easily in an MDI > situation. I suppose the OpenGL window would overlap the non-X11 child window. But such a thing does not work now, nor will it ever as long as OpenGL draws directly to the main window. But this would only be an issue when the actual OpenGL window area is overlapped by something from the same parent window (a seperate popup MessageBox, for example, would still work fine). And even in Windows, OpenGL windows have problems when overlapped with other child windows.

Dec. 31, 2006

Re: OpenGL as child windows

by Roderick Colenbrander

> > These wouldn't be Win32 subwindows as X11 child windows (as I heard Wine > > doesn't do), but rather, a child window of the main window used solely > for > > showing OpenGL on. I can't, in my admittedly limited knowledge, think of > > why > > it wouldn't work, and it should also help clear the problem Wine has > with > > Win32 child windows using OpenGL since they'd implicitly clip to the > child > > window extents, instead of trying to hack the scissors test. The X11 > child > > window for OpenGL would be completely transparent to the app (as in, > > opengl > > wouldn't announce its existance, and the rest of the code wouldn't care > > about > > it). > > Just wondered what would happen in the case of a non-X11 child window > partially overlapping an X11 OpenGL window? I guess this wouldn't work > still > even with this solution. This could happen quite easily in an MDI > situation. > > Mark > That would indeed be a problem. You could perhaps force that part to share the child window though that would cause other issues again. I'm not sure what pixel formats MDI apps in general use but perhaps they might need specific pixelformats for instance ones with the cap 'PFD_GDI_SUPPORT' to allow gdi rendering. If that's the case we just hide the GDI support cap and add a pixelformat with that cap set. When that pixelformat is used the current opengl behavior could be used. (Assuming our glScissors code would work correctly, this would get MDI running) Regards, Roderick -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Dec. 31, 2006

Re: OpenGL as child windows

by Mark Hatsell

> These wouldn't be Win32 subwindows as X11 child windows (as I heard Wine > doesn't do), but rather, a child window of the main window used solely for > showing OpenGL on. I can't, in my admittedly limited knowledge, think of > why > it wouldn't work, and it should also help clear the problem Wine has with > Win32 child windows using OpenGL since they'd implicitly clip to the child > window extents, instead of trying to hack the scissors test. The X11 child > window for OpenGL would be completely transparent to the app (as in, > opengl > wouldn't announce its existance, and the rest of the code wouldn't care > about > it). Just wondered what would happen in the case of a non-X11 child window partially overlapping an X11 OpenGL window? I guess this wouldn't work still even with this solution. This could happen quite easily in an MDI situation. Mark

Dec. 31, 2006

Re: appdb rating inflation

by Chris Morgan

On 12/31/06, Dan Kegel <dank(a)kegel.com> wrote: > The appdb says > "Only applications which install and run flawlessly on an out-of-the-box > Wine installation make it to the Platinum list" > But several platinum-rated apps seem to deserve > a silver or bronze rating. > > For instance, Call to Duty, > http://appdb.winehq.org/appview.php?iVersionId=3603 > has all sorts of caveats: > - Punkbuster enabled Multiplayer will not work > - Sound out of sync. > - Runs without crashes, but only if installed as root > - requires whacky third-party Loki installer; real installer > fails on cd change (http://bugs.winehq.org/show_bug.cgi?id=6594) > - "with alsa, the sound lags ~ 1 second behind the game.... if i > choose oss i got the 166 sound files missing error" > > And Diablo II, http://appdb.winehq.org/appview.php?iVersionId=49, > also has lots of complaints / caveats / complicated howto's. > > Should we impose some standards on appdb ratings? > - Dan > -- > Wine for Windows ISVs: http://kegel.com/wine/isv > Any app with sound issues shouldn't be rated platinum since it isn't playable without issues. Dan, are you an appdb admin? If you are interested in becoming one you can change the maintainer ratings for apps that are are misrated. Maybe we aren't clear enough on this page: http://appdb.winehq.org/help/?sTopic=maintainer_ratings since we don't say anything about how well an application runs under the "Platinum rating" but we do under the "Gold rating" description. Chris

Dec. 31, 2006

Re: appdb rating inflation

by Enverex

Dan Kegel wrote: > The appdb says > "Only applications which install and run flawlessly on an out-of-the-box > Wine installation make it to the Platinum list" > But several platinum-rated apps seem to deserve > a silver or bronze rating. > > For instance, Call to Duty, > http://appdb.winehq.org/appview.php?iVersionId=3603 > has all sorts of caveats: > - Punkbuster enabled Multiplayer will not work > - Sound out of sync. > - Runs without crashes, but only if installed as root > - requires whacky third-party Loki installer; real installer > fails on cd change (http://bugs.winehq.org/show_bug.cgi?id=6594) > - "with alsa, the sound lags ~ 1 second behind the game.... if i > choose oss i got the 166 sound files missing error" > > And Diablo II, http://appdb.winehq.org/appview.php?iVersionId=49, > also has lots of complaints / caveats / complicated howto's. > > Should we impose some standards on appdb ratings? > - Dan Call of Duty didn't work at all last time I tried it but that was a while ago. Diablo 2 installs fine and works perfectly but it seems far too many rather dim people try and use it or make it out to seem like you have to do a lot to make it work. It works "out of the box". Even the copy protection works. Works in Single player, works in Multiplayer, works on Battle.NET, even works with mods. So it is deserving of a platinum (I can't find a fault with it). The "howto" is just for laymen because lots of people that have no idea how to use Linux were likely trying to install it all the time a while back. Same issue we're seeing now with WoW in the IRC channel. Ex

Dec. 31, 2006

Re: OpenGL as child windows

by Vitaliy Margolen

Dmitry Timoshkov wrote: > "Damjan Jovanovic" <damjan.jov(a)gmail.com> wrote: > >> AFAIK there is no technical problems, only political ones. Wine no >> longer allows subwindows to be X11 windows. I've heard Alexandre >> Julliard won't accept such patches. > > That was a purely technical decision to get rid of X windows for child > Win32 windows, and has fixed numerous painting and z-order related > problems. If you or somebody else are really interested to go backwards, > show us the code which cleanly passes 'make test' in dlls/user32 and > simultaneously solves the problem for OpenGL child windows. > I'm not so sure that openGL windows behave the same way as GDI. Even native has lots of visual glitches with that. Some one said they act like an overlays - which might be true. In either case, what would stop us from at least considering this as a valid option limited to openGL only? Another BTW I have not seen a single test in user32 that involves openGL. Vitaliy

Dec. 31, 2006

appdb rating inflation

by Dan Kegel

The appdb says "Only applications which install and run flawlessly on an out-of-the-box Wine installation make it to the Platinum list" But several platinum-rated apps seem to deserve a silver or bronze rating. For instance, Call to Duty, http://appdb.winehq.org/appview.php?iVersionId=3603 has all sorts of caveats: - Punkbuster enabled Multiplayer will not work - Sound out of sync. - Runs without crashes, but only if installed as root - requires whacky third-party Loki installer; real installer fails on cd change (http://bugs.winehq.org/show_bug.cgi?id=6594) - "with alsa, the sound lags ~ 1 second behind the game.... if i choose oss i got the 166 sound files missing error" And Diablo II, http://appdb.winehq.org/appview.php?iVersionId=49, also has lots of complaints / caveats / complicated howto's. Should we impose some standards on appdb ratings? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

Dec. 31, 2006

Re: Resend: user32: fix return value in DialogBoxParamA if no resourcecan be found + simple test (try 2)

by Dmitry Timoshkov

"Louis. Lenders" <xerox_xerox2000(a)yahoo.co.uk> wrote: > As Dmitry Timoshkov (thanks for that) the SetLastError was not necessary. > Here's updated patch. Probably the problem is that you need also handle both FindResourceW and LoadResource failures the same way by returning -1, and change 'return -1;' later to 'return 0;' (for invalid parent) as MSDN suggests. All that needs to be tested as well. Also DialogBoxParamW needs to be fixed as well. Probably other dialaog APIs (like DialogBoxIndirectParamAorW) need a review regarding that. -- Dmitry.

Dec. 31, 2006

Re: OpenGL as child windows

by Roderick Colenbrander

> On Sunday 31 December 2006 00:12, you wrote: > > AFAIK there is no technical problems, only political ones. Wine no > > longer allows subwindows to be X11 windows. I've heard Alexandre > > Julliard won't accept such patches. > > These wouldn't be Win32 subwindows as X11 child windows (as I heard Wine > doesn't do), but rather, a child window of the main window used solely for > showing OpenGL on. I can't, in my admittedly limited knowledge, think of > why > it wouldn't work, and it should also help clear the problem Wine has with > Win32 child windows using OpenGL since they'd implicitly clip to the child > window extents, instead of trying to hack the scissors test. The X11 child > window for OpenGL would be completely transparent to the app (as in, > opengl > wouldn't announce its existance, and the rest of the code wouldn't care > about > it). > The subwindow would be created from within the opengl code (e.g. wglCreateContext / SetPixelFormat). That is where it happens on Windows too and on Windows OpenGL also uses some sort of overlay. Roderick -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Dec. 31, 2006

Re: ntdll: Map ESPIPE to STATUS_ILLEGAL_FUNCTION

by Dmitry Timoshkov

"Andreas Mohr" <andi(a)rhlx01.fht-esslingen.de> wrote: > The STATUS_ILLEGAL_FUNCTION name was rather misleading to me since it doesn't > indicate at all that it's supposed to be pipe-related > (however it's within the numeric range of many other pipe status codes!). > So, given that this is mainly a pipe status code after all I'd say that's > the best we can achieve right now. I haven't found anything more close is the PSDK. > Of course, what really matters is what the receiving Win32 side *usually* > expects after we encountered ESPIPE, and this might turn out to differ > from your conversion ;). > (is there any indication that RedAlert checks for a specific status code??) Looks like that my change didn't actually affected RedAlert at all, at least it was still functioning in my limited test session. -- Dmitry.

Dec. 31, 2006

Re: ntdll: Map ESPIPE to STATUS_ILLEGAL_FUNCTION

by Andreas Mohr

Hi, On Sun, Dec 31, 2006 at 05:28:23PM +0800, Dmitry Timoshkov wrote: > Hello, > > Running RedAlert demo spits a lot of FIXMEs about converting errno 29 > (ESPIPE) to STATUS_UNSUCCESSFUL. In Linux /usr/include/asm/errno.h has > a comment /* Illegal seek */ for ESPIPE, so STATUS_ILLEGAL_FUNCTION seems > to be the best choice. > > Changelog: > ntdll: Map ESPIPE to STATUS_ILLEGAL_FUNCTION. The STATUS_ILLEGAL_FUNCTION name was rather misleading to me since it doesn't indicate at all that it's supposed to be pipe-related (however it's within the numeric range of many other pipe status codes!). So, given that this is mainly a pipe status code after all I'd say that's the best we can achieve right now. Of course, what really matters is what the receiving Win32 side *usually* expects after we encountered ESPIPE, and this might turn out to differ from your conversion ;). (is there any indication that RedAlert checks for a specific status code??) Andreas Mohr

Dec. 31, 2006

Re: OpenGL as child windows

by L. Rahyen

On Sunday December 31 2006 08:12, Damjan Jovanovic wrote: > On 12/31/06, Chris Robinson <chris.kcat(a)gmail.com> wrote: > > The topic of getting OpenGL to show and use more visuals/pixel formats > > than just the one the main window uses came up on IRC, and I was told to > > make a post here. One of the ideas was to create a child window of the > > main X window (which can be given a different visual) and have OpenGL use > > that for drawing. > > > > A simple test program I wrote (using X) seems to behave well. The child > > window stays relative to the parent, it remains fully connected (even > > with the wobbly effects of compositors like Beryl), and it can use a > > different visual. Since wgl is now a part of x11drv, it should be > > possible to make an X11 child window. Are there any problems with using > > this approach in Wine? > > AFAIK there is no technical problems, only political ones. Wine no > longer allows subwindows to be X11 windows. I've heard Alexandre > Julliard won't accept such patches. Why not? There is no harm to create X11 subwindows for OpenGL windows. Also this is only real and correct solution (without performance penalties) for this problem and this is how all Linux programs with OpenGL child windows works (GoogleEarth for Linux for example which has same interface as in its Windows version). At least I do not know any good solution of this problem without creating X11 subwindow.

Dec. 31, 2006

Re: Looking for sound testers

by Neil Skrypuch

On Thursday, December 28, 2006 10:04, Maarten Lankhorst wrote: > Hi all, > > I've forward ported the old patches of Davin McCall (dsound.patch). > With them I have no more sound underruns etc, I'm therefore looking > for other people to test them as well. I'm welcoming comments on how > it works and possible issues with it. > > I also attached my patch to alsa, I'm aware of the things I need to > fix for that, but I thought it might be good to test dsound with > winealsa, to see if other things still need to be fixed. > > Cheers, > > Maarten I've given this a spin with Icewind Dale, and while it does seem to remove the underrun issues (at least I don't see them spit out anymore), the sound still stutters and crackles just as much as before. - Neil

Dec. 31, 2006

Re: OpenGL as child windows

by Chris Robinson

On Sunday 31 December 2006 00:12, you wrote: > AFAIK there is no technical problems, only political ones. Wine no > longer allows subwindows to be X11 windows. I've heard Alexandre > Julliard won't accept such patches. These wouldn't be Win32 subwindows as X11 child windows (as I heard Wine doesn't do), but rather, a child window of the main window used solely for showing OpenGL on. I can't, in my admittedly limited knowledge, think of why it wouldn't work, and it should also help clear the problem Wine has with Win32 child windows using OpenGL since they'd implicitly clip to the child window extents, instead of trying to hack the scissors test. The X11 child window for OpenGL would be completely transparent to the app (as in, opengl wouldn't announce its existance, and the rest of the code wouldn't care about it).

Dec. 31, 2006

Re: OpenGL as child windows

by Dmitry Timoshkov

"Damjan Jovanovic" <damjan.jov(a)gmail.com> wrote: > AFAIK there is no technical problems, only political ones. Wine no > longer allows subwindows to be X11 windows. I've heard Alexandre > Julliard won't accept such patches. That was a purely technical decision to get rid of X windows for child Win32 windows, and has fixed numerous painting and z-order related problems. If you or somebody else are really interested to go backwards, show us the code which cleanly passes 'make test' in dlls/user32 and simultaneously solves the problem for OpenGL child windows. -- Dmitry.

Dec. 31, 2006

Re: OpenGL as child windows

by Damjan Jovanovic

On 12/31/06, Chris Robinson <chris.kcat(a)gmail.com> wrote: > The topic of getting OpenGL to show and use more visuals/pixel formats than > just the one the main window uses came up on IRC, and I was told to make a > post here. One of the ideas was to create a child window of the main X window > (which can be given a different visual) and have OpenGL use that for drawing. > > A simple test program I wrote (using X) seems to behave well. The child window > stays relative to the parent, it remains fully connected (even with the > wobbly effects of compositors like Beryl), and it can use a different visual. > Since wgl is now a part of x11drv, it should be possible to make an X11 child > window. Are there any problems with using this approach in Wine? AFAIK there is no technical problems, only political ones. Wine no longer allows subwindows to be X11 windows. I've heard Alexandre Julliard won't accept such patches. Damjan

Dec. 31, 2006

Re: X11DRV: remove DesktopDoubleBuffered option

by Dmitry Timoshkov

"Roderick Colenbrander" <thunderbird2k(a)gmx.net> wrote: > This patch removes the DesktopDoubleBuffered option. Support for this option should be removed from winecfg simultaneously with this change. -- Dmitry.

Dec. 31, 2006

Re: problems with installed wine

by L. Rahyen

On Saturday December 30 2006 21:15, Corey McClymonds wrote: > But if I make install it, then try to use it, all I get is a black screen > that I have to alt-tab to get out of. On a note, it works fine if I > run as root. That means you have problems with permissions. It shouldn't be very hard to find out what exactly permissions you havn't and fix them. You also can use strace to see what files Wine tries to open and why it fails.

Dec. 31, 2006

OpenGL as child windows

by Chris Robinson

The topic of getting OpenGL to show and use more visuals/pixel formats than just the one the main window uses came up on IRC, and I was told to make a post here. One of the ideas was to create a child window of the main X window (which can be given a different visual) and have OpenGL use that for drawing. A simple test program I wrote (using X) seems to behave well. The child window stays relative to the parent, it remains fully connected (even with the wobbly effects of compositors like Beryl), and it can use a different visual. Since wgl is now a part of x11drv, it should be possible to make an X11 child window. Are there any problems with using this approach in Wine?

Dec. 31, 2006

Re: Resend: msxml.dll: nextNode and reset functions

by James Hawkins

On 12/28/06, Colin Pitrat <colin.pitrat(a)bull.net> wrote: > Hi, > > here is a patch I sent a few weeks ago implementing two functions in > msxml.dll, and the corresponding test. > I suggest sending the tests in one patch first, then send each function in a separate patch afterwards. -- James Hawkins

Dec. 30, 2006

Re: Vijay Kiran Kamuju : comctl32: MonthCalendar - Fix highlightingof current date.

by James Hawkins

On 12/27/06, Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: > Hi, > > It might be because of the MULTISELECT style not being set. > Can you please test with the MULTISELECT set? > In the older version of the control spy test its set by default, and > in the new version its not set. > Can you please test that and also test by applying the other patch as well? > Currently I am tidying it up and putting some comments. > As the order of messages sent is a bit messed up. > Dimitry: > What do we need to setup, if we want a test framework for messages in > comctl32 similar to user32? > Lei and Dan, > This can also be a good exercise. > But I will try to do it myself first. > > Cheers, > VJ I wouldn't worry about it. I have a patch that adds message testing for comctl32. I'll send it in when I get back from vacation (couple of days, stuck in a blizzard). -- James Hawkins

Dec. 30, 2006

Re: riched20: block recursive notification

by Matt Finnicum

On 12/30/06, Clinton Stimpson <cjstimpson(a)utwire.net> wrote: > > This patch blocks riched20 from recursivly sending an EN_CHANGE > notification. > Fixes bug 6985. > > Thanks, > Clinton Stimpson > > ChangeLog > Block recursive EN_CHANGE notifications. If you're adding a new variable to the ME_TextEditor structure then you should probably also initialize it in ME_MakeEditor. Naming the variable "notify" is somewhat ambiguous, and there seems to be an established convention of naming int's with the 'n' prefix, like nNotifiy. You should probably comment to explain what the variable is for or attempt to name it something more self evident. Maybe a BOOL would be more appropriate, unless you're intending to extend this to other notify calls as well. Lastly, I don't see why this patch is needed - it only prevents the ME_SendOldNotify (which just calls SendMessageA) from triggering another call of that same EN_CHANGE notification. I don't see why calling SendMessageA would cause ME_UpdateRepaint to be called. Maybe the application you're working with, in processing the EN_CHANGE message, is sending another message to which we wrongly are sending an EN_CHANGE notification - so thus we should fix our message handling of that. A quick look at MSDN shows that "The EN_CHANGE notification message is sent when the user has taken an action that may have altered text in an edit control." - it seems that we may be sending them whenever any action (user or not) has altered text in the control. We really could use some tests to see what should generate EN_CHANGE messages. Another possibility is that we don't handle the case where (again, from MSDN) "The EN_CHANGE notification is not sent when the ES_MULTILINE style is used and the text is sent through WM_SETTEXT." - perhaps your application has ES_MULTILINE set and uses a WM_SETTEXT in response to the EN_CHANGE notification? Thanks for your help with richedit, --Matt Finnicum

Dec. 30, 2006

problems with installed wine

by Corey McClymonds

for almost a week now, wine has been acting weird. I compile wine and using it from the wine source tree, everything works perfectly. But if I make install it, then try to use it, all I get is a black screen that I have to alt-tab to get out of. On a note, it works fine if I run as root. I have blown away my .wine directory, it doesn't help. I compile from git. Corey McClymonds

Dec. 30, 2006

Re: wine-patch OleIconToCursor function

by Frank Richter

On 30.12.2006 18:54, Marcus Meissner wrote: >> +/*********************************************************************** >> + * OleIconToCursor (OLEAUT32.415) >> + */ >> +HCURSOR WINAPI OleIconToCursor( HINSTANCE hinstExe, HICON hIcon) >> +{ >> + FIXME("(%p,%p), (olepro32.dll), partially implemented.\n",hinstExe,hIcon); >> + if (hIcon) >> + return CopyCursor(hIcon); >> + else >> + return NULL; >> + >> + /* FIXME >> + make a extended conversation from HICON to HCURSOR >> + */ >> +} According to http://msdn2.microsoft.com/en-us/library/ms694362.aspx, this function just does a simple CopyCursor() on Win32. And since there doesn't seem to be a need for further changes to that function, the FIXME trace as well as comment could both be removed. -f.r.

Dec. 30, 2006

Re: wine-patch OleIconToCursor function

by Marcus Meissner

On Sat, Dec 30, 2006 at 04:49:27AM +0100, Bernard Ladenthin wrote: > Hello, > in the attachment is a small patch for the OleIconToCursor function. > The function works with this. I hope i can help with this and get a > response mail that this mail have received. I haven't any experiences > with git so it's a simply patch. > > I have tested it with the "Lexware Buchhalter 2005". > You can download it from http://server.ladenthin.net/bh2005.zip to see > that it works. Start with wine the "LxStart.exe" and turn over the > Text and Icon with the mouse, the icon is now the cursor. > > Best regards from Germany, > Bernard Ramon Ladenthin In general you do no need to edit Changelog yourself. Just add a note above the patch. Otherwise it looks fine to my eyes (and perhaps Alexandres too), thanks! Ciao, Marcus > diff --git a/ChangeLog b/ChangeLog > index 3b536b5..9723401 100644 > --- a/ChangeLog > +++ b/ChangeLog > @@ -1,3 +1,8 @@ > +2006-12-30 Bernard Ramon Ladenthin <bernard(a)ladenthin.net> > + > + * dlls/oleaut32/oleaut.c, dlls/oleaut32/stubs.c: > + oleaut32: Implement the function OleIconToCursor and remove the stub. > + > 2006-12-22 Dmitry Timoshkov <dmitry(a)codeweavers.com> > > * dlls/user32/tests/msg.c, dlls/winex11.drv/winpos.c: > diff --git a/dlls/oleaut32/oleaut.c b/dlls/oleaut32/oleaut.c > index d6a08a9..65a4174 100644 > --- a/dlls/oleaut32/oleaut.c > +++ b/dlls/oleaut32/oleaut.c > @@ -837,3 +837,19 @@ BOOL WINAPI DllMain(HINSTANCE hInstDll, > > return TRUE; > } > + > +/*********************************************************************** > + * OleIconToCursor (OLEAUT32.415) > + */ > +HCURSOR WINAPI OleIconToCursor( HINSTANCE hinstExe, HICON hIcon) > +{ > + FIXME("(%p,%p), (olepro32.dll), partially implemented.\n",hinstExe,hIcon); > + if (hIcon) > + return CopyCursor(hIcon); > + else > + return NULL; > + > + /* FIXME > + make a extended conversation from HICON to HCURSOR > + */ > +} > diff --git a/dlls/oleaut32/stubs.c b/dlls/oleaut32/stubs.c > index ac2d494..d87e76e 100644 > --- a/dlls/oleaut32/stubs.c > +++ b/dlls/oleaut32/stubs.c > @@ -33,15 +33,6 @@ > WINE_DEFAULT_DEBUG_CHANNEL(ole); > > /*********************************************************************** > - * OleIconToCursor (OLEAUT32.415) > - */ > -HCURSOR WINAPI OleIconToCursor( HINSTANCE hinstExe, HICON hicon) > -{ > - FIXME("(%p,%p), not implemented (olepro32.dll)\n",hinstExe,hicon); > - return S_OK; > -} > - > -/*********************************************************************** > * OleCreatePropertyFrameIndirect (OLEAUT32.416) > */ > HRESULT WINAPI OleCreatePropertyFrameIndirect( LPOCPFIPARAMS lpParams) >

Dec. 30, 2006

Reason for some process failures in kernel32 tests

by Paul Vriens

Hi, I've been trying to tackle some of the issues we have when trying to run some process tests (through winetest.exe, see also http://test.winehq.org/data) process.c:775: Test failed: CreateProcess (./kernel32_test.exe tests/process.c C:\TEMP\wt44.tmp "a\"b\\" c\" d) failed : 2 process.c:777: Test failed: Child process termination process.c:781: Test failed: Arguments:argvA0 expected './kernel32_test.exe', got '(null)' process.c:790: Test failed: CreateProcess (.\kernel32_test.exe tests/process.c C:\TEMP\wt45.tmp "a\"b\\" c\" d) failed : 2 process.c:792: Test failed: Child process termination process.c:796: Test failed: Arguments:argvA0 expected '.\kernel32_test.exe', got '(null)' process.c:810: Test failed: CreateProcess (..\wct12/kernel32_test.exe tests/process.c C:\TEMP\wt46.tmp "a\"b\\" c\" d) failed : 2 process.c:812: Test failed: Child process termination process.c:816: Test failed: Arguments:argvA0 expected '..\wct12/kernel32_test.exe', got '(null)' The reason for this particular one is that I'm running winetest.exe started from a command-file on my desktop. This means that the current directory is the desktop directory. The winetest gui shows that the working directory is (in this case) c:\temp\wct12. This value is however not passed to the tests when CreateProcess is run: main.c: 291 if (!CreateProcessA (NULL, cmd, NULL, NULL, TRUE, 0, 292 NULL, NULL, &si, &pi)) { The above means that the kernel32_test.exe has a working directory that is not c:\temp\wct12 (in this case again) and thus cannot find the executable when referenced relatively. All the test-results that are shown on http://test.winehq.org show more-or-less the same behavior. How can I retrieve the correct working directory (as shown in the winetest gui) and pass that to the single tests? (I think that would solve these particular issues). Cheers and thanks for any pointers, Paul.

Dec. 30, 2006

Re: USB

by Damjan Jovanovic

On 12/30/06, Andrew Neil Ramage <nrsc16850(a)blueyonder.co.uk> wrote: > A franklin eBookMan using the provided Windows Software. (By the way, it's bad practice to top-post bottom-posted emails.) What interface does the device provide? Is it a mass-storage device? Or some vendor-specific protocol? Do "lsusb -v" and see the class and subclass -if they're 0xFF (vendor-specific), you're probably out of luck, because: If the Windows software includes .SYS files, wine can't load those yet (although wine's NTOSKRNL.EXE is coming soon, right?) Since wine is largely designed for running Windows applications on Linux, a lot of the hardware support infrastructure (SETUPAPI, CFGMGR, ...) is still missing. At present, a Windows app cannot directly access the hardware, only indirectly (for example, it can save a file to a mass-storage device supported by Linux, or communicate through a USB ethernet controller supported by Linux). Now in Windows, applications don't access USB directly either (Windows only allows USB control packets from user-space, not bulk, interrupt or isochronous, and no app I know uses that interface anyway). What apps usually do is open a .SYS device driver (eg. \\.\USBSCAN0\2) and use ReadFile to send bulk data, WriteFile to receive bulk data, and DeviceIoControl for everything else. So in theory if you figure out the interface between the application and the driver in Windows, you can write a kernel module for Linux that does the same, and your app can communicate with the hardware. Wine currently doesn't do this at all, although I've written a semi-complete implementation of STI and USBSCAN.SYS this way, and it works with native TWAIN drivers. Damjan > Andrew > > > On 12/30/06, Andrew Neil Ramage <nrsc16850(a)blueyonder.co.uk> wrote: > >> How do you get a Windows program access to the USB port ? > > > > What are you trying to do? What device are you accessing? > > > >> Andrew > > > > Damjan > > > > > > > -- > Andrew Ramage > > >

Dec. 30, 2006

Re: USB

by Damjan Jovanovic

On 12/30/06, Andrew Neil Ramage <nrsc16850(a)blueyonder.co.uk> wrote: > How do you get a Windows program access to the USB port ? What are you trying to do? What device are you accessing? > Andrew Damjan

Dec. 30, 2006

USB

by Andrew Neil Ramage

How do you get a Windows program access to the USB port ? -- Andrew "Oh, bother," said the Borg. "We've assimilated Pooh."

Dec. 30, 2006

Re: bump: windows web server app fails to send more than 11680 bytes !?

by Kai Blin

On Saturday 30 December 2006 09:20, [IDC]Dragon wrote: > I'd like to humbly bump my bug report: > http://bugs.winehq.org/show_bug.cgi?id=6415 I've had a look at it and couldn't recreate the problem. What setup do you have? (I'm not running the web server on port 80, because that's where my apache is sitting, and I don't feel like running wine as root. I'd be surprised if that changes anything, though.) Looking at my +winsock trace, it seems to be looping over the WSASendTo just fine. Cheers, Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

Dec. 30, 2006

Budgetdedicated mirror down

by Kai Blin

Hi folks, at the time of writing, I'm unable to get a page back from the budgetdedicated mirror. Could someone who has access to that box take a look at that? Cheers, Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

Dec. 30, 2006

bump: windows web server app fails to send more than 11680 bytes !?

by [IDC]Dragon

I'd like to humbly bump my bug report: http://bugs.winehq.org/show_bug.cgi?id=6415 Now somebody else seems to suffer a perhaps related problem, and we offer a donation for fixing it. This certainly doesn't really pay for anybodys time, but perhaps it's a sign. Bear in mind that I also spent many hours in pinpointing the problem, and did my best in providing a small to-the-point executable example, source code, and logs. (You'd like my web server demo content ;-) It's as much on a silver tablet with red velvet as I can present it. Would be a shame to have it rot in bugzilla. Thanks for attention Jörg -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Dec. 30, 2006

Re: [user32][msgbox] Disable IDCANCEL for some MessageBoxs

by Dmitry Timoshkov

"Anatoly Lyutin" <vostok(a)etersoft.ru> wrote: > @@ -129,9 +132,11 @@ static HFONT MSGBOX_OnInit(HWND hwnd, LP > ShowWindow(GetDlgItem(hwnd, IDCANCEL), SW_HIDE); > ShowWindow(GetDlgItem(hwnd, IDYES), SW_HIDE); > ShowWindow(GetDlgItem(hwnd, IDNO), SW_HIDE); > + bUseCancel = FALSE; > break; > case MB_YESNO: > ShowWindow(GetDlgItem(hwnd, IDCANCEL), SW_HIDE); > + bUseCancel = FALSE; It would be much simpler to use IsWindowVisible(GetDlgItem(hwnd, IDCANCEL)) where appropriate instead of introducing bUseCancel. > /* fall through */ > case MB_YESNOCANCEL: > ShowWindow(GetDlgItem(hwnd, IDOK), SW_HIDE); > @@ -147,6 +152,11 @@ static HFONT MSGBOX_OnInit(HWND hwnd, LP > ShowWindow(GetDlgItem(hwnd, IDNO), SW_HIDE); > break; > } > + if(!bUseCancel) > + { > + SetWindowLongW(hwnd,GWL_STYLE,GetWindowLongW(hwnd,GWL_STYLE)&~(WS_SYSMENU)); > + } > + SetPropA(hwnd, "WINE_MSGBOX_BUSECANCEL", (HANDLE)bUseCancel); What is the purpose of removing WS_SYSMENU? In any case this change requires a test case. -- Dmitry.

Dec. 30, 2006

Re: Building a full win32 winetest.exe

by Paul Millar

On Sunday 24 December 2006 09:37, Paul Vriens wrote: > Doing a simple 'make clean' and 'make' only gives me a winetest.exe.so > which is a 'ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), > not stripped'. > > Is there something I'm missing here? Sorry, what I said was a bit incomplete (and a bit misleading). WRT does cross-builds using out-of-tree builds. There's also a way of doing in-tree cross-building, but I don't use it myself. For the out-of-tree builds, the directories are something like: wine-source/ wine-native/ wine-pe/ Within the wine-native directory, I do something like: ../wine-source/configure && make depend \ && make tools Within the wine-pe directory, I do something like: ../wine-source/configure --host=i686-mingw32msvc --with-wine-tools=../wine-native make depends && make -C libs [and, the following line, with a big fat FIXME] find dlls -name tests -execdir make -C \{\} \; make -C programs/winetest winetest.exe I think just "make" in the wine-pe/programs/winetest directory (instead of "make winetest.exe") should work within wine-pe dir. For in-tree builds you probably need to use the explicit "winetest.exe" target. There is also the "winetest-dist.exe" target that embeds some metadata within the winetest executable. You shouldn't needed this target unless you're planning on uploading your results to the test.winehq.org pages. On Monday 25 December 2006 10:22, Paul Vriens wrote: > cert.cross.o:cert.c:(.text+0x3b05): undefined reference to > `_CryptSignAndEncodeCertificate(a)36' cert.cross.o:cert.c:(.text+0x3bb8): [...] > [..]/i386-mingw32/bin/ld: > cannot find -lhlink collect2: ld returned 1 exit status [...] Yes, you need a "newer" MinGW with CryptSignAndEncodeCertificate and hlink library support. Stefan (Leichter), Hans (Leidekker) and myself keep a mutual set of win32api patches up-to-date (this is mostly their work, not mine!). So, I have some patches that add support for these functions For historical reasons, I roll my own MinGW rather than use Hans' RPMs. Hmm, I need to release the MinGW-build script and the set of patches (I can send you them if you like :) but in the mean time perhaps you could ask Hans to check his RPMs :-) On Wednesday 27 December 2006 19:23, Paul Vriens wrote: > When I look at the output on > http://quisquiliae.ph.gla.ac.uk/crossbuild-logs/ I somehow have the > feeling that you've modified the makefiles? I used to apply some patches on-the-fly, but don't any more. I use straight winehq.org source-code now. > In you're (failing) logs I see 'i686-mingw32msvc-windres -i winetest.res > -o winetest.res.o' whereas mine show 'false -i winetest.res -o > winetest.res.o'. Ah! "false" (as an executable) usually indicates that the configure script failed to find some executable. Here, it looks like it failed to find the windres executable. You should track down why this is happening. > So for some strange (?) reason you have WINDRES=i686-mingw32msvc-windres > in you're Makefile whereas my Makefile shows 'WINDRES=false'. > > ./configure in the wine root shows that WINDRES is not found but > CROSSWINDRES='i386-mingw32-windres'. > > Any idea? Yes, it looks like the configure script can't find your MinGW windres executable. You'll also need a "newer" MinGW or rather, one with a more complete win32api. Once those two are fixed, you should be good to go! HTH, Paul.

Dec. 29, 2006

Removing unused functions and variables

by Andrew Talbot

Hi, I am intending to send in a few patches to remove some unused Wine variables and functions from the dlls. Please accept that my good faith is tempered by a degree of ignorance, and advise me of suitable markup if any seemingly redundant piece of code I seek to remove must remain for a legitimate reason. Thanks, -- Andy.

Dec. 29, 2006

Re: [4/4] wined3d: Create samplers for *all* 1.x instructions that sample

by H. Verbeet

On 28/12/06, Christoph Bumiller <e0425955(a)stud3.tuwien.ac.at> wrote: > Note that WINED3DSIO_TEXDP3TEX, WINED3DSIO_TEXM3x3VSPEC, > WINED3DSIO_TEXM3x3SPEC are already handled in the 2 else if branches > below, they should probably be > removed somewhere. Oops, you're right. Those two branches can be removed now that we can lookup the actual sampler type.

Dec. 29, 2006

Re: systray icon questions

by Kirill K. Smirnov

> Unfortunately, yes. The way the helper window is currently implemented, > if you remove the WS_CAPTION style, the icon won't be centered when it > gets docked (in GNOME at least.) I tried that when I put together the > systray tooltips patch. Ultimately it caused more problems than it > solved, so I gave up on it. But, it would be really great if you could > figure it out. :) I've tried kde, fluxbox and xfce4 (and fvwm, but it lacks systray). Now I can see that xfce4 suffers from it. I did not noticed that before. So, I suppose a new patch (attached). Does it work correct with GNOME? In xfce is OK. Thanks for pointing the path! -- Kirill K. Smirnov

Dec. 29, 2006

Solution to Bug 3023

by Michael Gardiner

http://bugs.winehq.org/show_bug.cgi?id=3023 I have been fiddling with Orcad 9.2 Capture and have found the cause of the problem behind its inability to place parts, text etc. It is caused by the window that the object is to be placed in temporarily losing focus (or maybe activation) after the dialog box for entering the object's properties is closed. This temporary loss of focus causes the window to "lose its grip" on the object being placed. Removing the line that calls WINPOS_ActivateOtherWindow in dlls/user32/dialog.c in the EndDialog function fixes this problem - the focus seems to immediately return to the correct window and the object can be placed. The removal of this WINPOS_ActivateOtherWindow call does not seem to have any visible side-effects in this particular instance - does it have a purpose? (In this instance I traced its call to see what it activated - it does not find a valid window to activate, so reaches the end and calls SetActiveWindow(0)).

Dec. 29, 2006

[4/4] wined3d: Create samplers for *all* 1.x instructions that sample

by Christoph Bumiller

Note that WINED3DSIO_TEXDP3TEX, WINED3DSIO_TEXM3x3VSPEC, WINED3DSIO_TEXM3x3SPEC are already handled in the 2 else if branches below, they should probably be removed somewhere. > @@ -295,8 +295,15 @@ HRESULT shader_get_registers_used( > if > (WINED3DSHADER_VERSION_MAJOR(This->baseShader.hex_version) == 1 && > (WINED3DSIO_TEX == curOpcode->opcode || > WINED3DSIO_TEXBEM == curOpcode->opcode || > + WINED3DSIO_TEXBEML == curOpcode->opcode || > + WINED3DSIO_TEXDP3TEX == curOpcode->opcode || > WINED3DSIO_TEXM3x2TEX == curOpcode->opcode || > - WINED3DSIO_TEXM3x3TEX == curOpcode->opcode)) { > + WINED3DSIO_TEXM3x3SPEC == curOpcode->opcode || > + WINED3DSIO_TEXM3x3TEX == curOpcode->opcode || > + WINED3DSIO_TEXM3x3VSPEC == curOpcode->opcode || ... } else if (WINED3DSHADER_VERSION_MAJOR(This->baseShader.hex_version) == 1 && (WINED3DSIO_TEXM3x3SPEC == curOpcode->opcode || WINED3DSIO_TEXM3x3VSPEC == curOpcode->opcode)) {

Dec. 28, 2006

Re: sane.ds: Remove unused WINE_DEFAULT_DEBUG_CHANNEL

by Marcus Meissner

On Thu, Dec 28, 2006 at 09:08:51PM +0000, Andrew Talbot wrote: > Changelog: > sane.ds: Remove unused WINE_DEFAULT_DEBUG_CHANNEL. > > diff -urN a/dlls/sane.ds/ui.c b/dlls/sane.ds/ui.c > --- a/dlls/sane.ds/ui.c 2006-05-23 13:48:34.000000000 +0100 > +++ b/dlls/sane.ds/ui.c 2006-12-28 20:49:16.000000000 +0000 > @@ -37,8 +37,6 @@ > #include "wine/debug.h" > #include "resource.h" > > -WINE_DEFAULT_DEBUG_CHANNEL(twain); > - > #ifdef HAVE_SANE NAK, this code has 1 TRACE() some way below. Just move it below #ifdef HAVE_SANE. Ciao, Marcus

Dec. 28, 2006

Re: systray icon questions

by James Liggett

Hi Krill, On Thu, 2006-12-28 at 13:14 +0300, Kirill K. Smirnov wrote: > > So the questions: > 1) Does systray icon helper window really need to be created with WS_CAPTION > style? Unfortunately, yes. The way the helper window is currently implemented, if you remove the WS_CAPTION style, the icon won't be centered when it gets docked (in GNOME at least.) I tried that when I put together the systray tooltips patch. Ultimately it caused more problems than it solved, so I gave up on it. But, it would be really great if you could figure it out. :) James

Dec. 28, 2006

Re: Building a full win32 winetest.exe

by Hans Leidekker

I created a new RPM package for mingw-w32api that allows you to build all current Wine tests. Find it here: http://mirzam.it.vu.nl/mingw/ -Hans

Dec. 28, 2006

Looking for sound testers

by Maarten Lankhorst

Hi all, I've forward ported the old patches of Davin McCall (dsound.patch). With them I have no more sound underruns etc, I'm therefore looking for other people to test them as well. I'm welcoming comments on how it works and possible issues with it. I also attached my patch to alsa, I'm aware of the things I need to fix for that, but I thought it might be good to test dsound with winealsa, to see if other things still need to be fixed. Cheers, Maarten

Dec. 28, 2006

Re: [1/4] wined3d: Where possible, avoid using D3DCOLORTOGLFLOAT4

by Stefan Dösinger

Am 28.12.2006 um 03:12 schrieb H. Verbeet: > Most of the places that use D3DCOLORTOGLFLOAT4 can handle GLint's > just as well. > > Changelog: > - Where possible, avoid using D3DCOLORTOGLFLOAT4 > <wined3d_d3dcolor.diff.txt> > This patch causes a regression in Battlefield 1942, a lot of geometry is missing(ships, planes, parts of trees).

Dec. 28, 2006

re: comctl32: MonthCalendar - Fixhighlightingof current date.

by Dan Kegel

Dmitry wrote: > "Vijay Kiran Kamuju" <infyquest at gmail.com> wrote: >> What do we need to setup, if we want a test framework for messages in >> comctl32 similar to user32? > >Some kind of a message queue is needed and a mechanism to check what >has been gathered with an expected sequence. I'd suggest to not invent >a wheel and copy existing parts from dlls/user32/tests/msg.c. Yeah. Also I think James Hawkins is doing this now for comctl, might check with him first. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

Dec. 28, 2006

systray icon questions

by Kirill K. Smirnov

Hi, all! I was playing around systray icons in various modes 1) "allow the window manager to control the windows"="on" "emulate a virtual desktop"="off" As result, systray icon is OK. 2) In other combination of these parameters, the icon is drawn with window title. I've tried to investigate the problem and created the patch (attached). But it solves the problem only in non-desktop modes. In desktop modes only window title is drawn. So the questions: 1) Does systray icon helper window really need to be created with WS_CAPTION style? 2) What does "managed" mode mean? 3) When I select "desktop" mode, should we disable the "managed" checkbox? Thanks in advance, -- Kirill K. Smirnov

Dec. 28, 2006

Re: Vijay Kiran Kamuju : comctl32: MonthCalendar - Fixhighlightingof current date.

by Dmitry Timoshkov

"Vijay Kiran Kamuju" <infyquest(a)gmail.com> wrote: > What do we need to setup, if we want a test framework for messages in > comctl32 similar to user32? Some kind of a message queue is needed and a mechanism to check what has been gathered with an expected sequence. I'd suggest to not invent a wheel and copy existing parts from dlls/user32/tests/msg.c. -- Dmitry.

Dec. 28, 2006

Re: Vijay Kiran Kamuju : comctl32: MonthCalendar - Fix highlightingof current date.

by Vijay Kiran Kamuju

Hi, It might be because of the MULTISELECT style not being set. Can you please test with the MULTISELECT set? In the older version of the control spy test its set by default, and in the new version its not set. Can you please test that and also test by applying the other patch as well? Currently I am tidying it up and putting some comments. As the order of messages sent is a bit messed up. Dimitry: What do we need to setup, if we want a test framework for messages in comctl32 similar to user32? Lei and Dan, This can also be a good exercise. But I will try to do it myself first. Cheers, VJ On 12/27/06, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > "Lei Zhang" <thestig(a)google.com> wrote: > > >I see the problem Duane reports as well. As long as you stay with in > > the current month, the current day will remain highlighted even if you > > click another date. It will disappear if you (a) highlight the current > > date, then another date, or (b) if you go to another month. > > > > On 12/26/06, Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: > >> Hi, > >> > >> It did it for me. when I did the tests. > >> I will check again. > >> Currently I am out of net access for atleast 2 weeks. > >> Shifting to a new room(hostel). > >> So I will test it soon, please bear with me, and also please test with > >> my other patch(month calander one). May be I should leave that for > >> Dan's students. > >> But I will fix it as this is my bug, anyways. > > Since 2 independent persons do see that the patch has caused a regression, > and it's not going to be fixed in a reasonable amount of time, I'd suggest > to revert that patch as an obviously wrong then. > > -- > Dmitry. >

Dec. 28, 2006

Re: WGL: fix wglGetProcAddress bug

by Roderick Colenbrander

Vitaly just pointed out that the previous version added some extra spaces. This one fixes that. Roderick > Hi, > > This patch fixes a nasty wglGetProcAddress bug. In case the name of an > unknown GL extension (one which is not in wine yet) was passed to > wglGetProcAddress it was assumed that it was a WGL extension. > > WGL extensions are in the end looked up in winex11.drv. The > wglGetProcAddress function in winex11.drv can return WGL extensions but it can also > return native GL functions. This ability is used in order to fill the opengl32 > thunks (win32 GL -> native GL). > > The problem was that unknown extensions were also passed to the > winex11.drv code. This resulted that code to look up a native GL functions (the > winex11.drv code returns wgl extensions if the function name starts with 'wgl' > and else it calls glXGetProcAddress). > > In the end this patch makes sure that only functions which start with a > 'w' are passed to the winex11.drv code in the other cases a warning is > printed that the function wasn't found. > > Regards, > Roderick Colenbrander -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Dec. 28, 2006

function_grep.pl - idutils

by Claudio Fontana

Hello, I noticed that you are using function_grep.pl to search for a certain function. Have you considered GNU idutils? They can do that and more (and faster): http://www.gnu.org/software/idutils It is as simple as $ cd $WINE_SRC_PATH $ mkid (generate ID database, takes about 4 seconds on my machine for wine) $ gid -r PATTERN Claudio

Dec. 27, 2006

Re: kernel32 console bug?

by Frank Richter

On 21.12.2006 21:28, Eric Pouech wrote: > perhaps ShellExecute is supposed to create a console when calling > CreateProcess for CUI subprocesses (this should be tested) Or CreateProcess() itself creates the console window. -f.r.

Dec. 27, 2006

Re: Bug 50

by Keith Dunwoody

Hi Pedro, Suppose the user asks for (on average) 5.5 pixels per space. At the moment wine is using 5 pixels per space, and then tacking on all the remaining .5 pixels at the end of the line. The correct answer would be to use 5 pixels in half the spaces, and 6 in the other half. This is essentially doing pulse width modulation (PWM) on the space sizes, and you can probably find algorithms for doing this on the Internet. However, I think wine is storing the wrong information in the hDC. From what I remember, wine is storing the average number of pixels per space, and the number of pixels left over. This isn't enough, because you need to know how many spaces the "left over" pixels are to be distributed over. -- Keith --- "Pedro Araújo Chaves Jr." <inckie(a)gmail.com> wrote: > I've been trying to get the lpDx array to be properly calculated, but > unfortunately to no avail. I did find, though, that GetTextExtentExPointW is > never called with a maxExt value other than zero, and thus nfit is not > calculated. > > Regarding that, would any of you know where I should look for the proper > method of calculating the maximum width (maxExt) of a formatted string? I'm > somewhat puzzled... neither lprect nor dc->BoundsRect seem to hold the > proper values for getting that value [1], or (more likely, I guess) I'm just > looking at it the wrong way. > > Btw, I'd add that I've been testing this in Lotus Notes R5, just in case it > helps, and no, I haven't found a link to download a trial. [2] [3] > > Cheers, > Pedro. > > [1] I'm investigating the SetTextJustification, ExtTextOutW, > GetTextExtentPointW, GetTextExtentPoint32W, GetTextExtentExPointW, and > WineEngGetTextExtentExPoint functions from gdi32 (the latter in freetype.c, > the rest in font.c). I am yet to look into their *I counterparts, where > applicable. > > [2] http://appdb.winehq.org/viewbugs.php?bug_id=50 > > [3] http://bugs.winehq.org/show_bug.cgi?id=7016 > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Dec. 27, 2006

Re: Bug 50

by Pedro Araújo Chaves Jr.

Followup: you can download Lotus trial versions here: http://www.ibm.com/developerworks/lotus/downloads/ Hope this helps. Regards, Pedro.

Dec. 27, 2006

Re: adding a data point to ALSA vs Wine sound discussion

by Andreas Mohr

Hi, On Tue, Dec 26, 2006 at 03:41:56AM +0100, Molle Bestefich wrote: > Adding a data point to the ALSA and Wine sound discussion. That data point unfortunately doesn't contain the ALSA version number, thus it's almost useless ;) Andreas Mohr

Dec. 27, 2006

Re: Bug 50

by Pedro Araújo Chaves Jr.

I've been trying to get the lpDx array to be properly calculated, but unfortunately to no avail. I did find, though, that GetTextExtentExPointW is never called with a maxExt value other than zero, and thus nfit is not calculated. Regarding that, would any of you know where I should look for the proper method of calculating the maximum width (maxExt) of a formatted string? I'm somewhat puzzled... neither lprect nor dc->BoundsRect seem to hold the proper values for getting that value [1], or (more likely, I guess) I'm just looking at it the wrong way. Btw, I'd add that I've been testing this in Lotus Notes R5, just in case it helps, and no, I haven't found a link to download a trial. [2] [3] Cheers, Pedro. [1] I'm investigating the SetTextJustification, ExtTextOutW, GetTextExtentPointW, GetTextExtentPoint32W, GetTextExtentExPointW, and WineEngGetTextExtentExPoint functions from gdi32 (the latter in freetype.c, the rest in font.c). I am yet to look into their *I counterparts, where applicable. [2] http://appdb.winehq.org/viewbugs.php?bug_id=50 [3] http://bugs.winehq.org/show_bug.cgi?id=7016

Dec. 27, 2006

Re: make test failure

by Dmitry Timoshkov

"Kai Blin" <kai.blin(a)gmail.com> wrote: > Well, both emulate virtual desktop and managed windows are both ticked. It's impossible to have managed windows in a virtual Wine desktop. > I switched off the desktop emulation and reran the tests, giving me the following errors: > > msg.c:8624: Test failed: 15: ShowWindow(SW_HIDE): in msg 0x0046 expecting wParam 0x93 got 0x83 > msg.c:8624: Test failed: 15: ShowWindow(SW_HIDE): in msg 0x0047 expecting wParam 0x1893 got 0x1883 > > This is on xorg 6.9.0-50.24(a)i586, KDE 3.5.1 That one also fails for me, but passes for Alexandre. Wonder if that's another race. Anyway having this only test failing sounds much more reasonable. -- Dmitry.

Dec. 27, 2006

Re: make test failure

by Kai Blin

On Wednesday 27 December 2006 05:00, Dmitry Timoshkov wrote: > "Kai Blin" <kai.blin(a)gmail.com> wrote: > > over christmas, I decided to give make test another try. > > > > I'm running this on an openSUSE 10.1 box, ati radeon mobility x300 with > > open source drivers. (Probably unimportant for the errors I'm getting) > > > > My procedure to get the tests setup were: > > > > export WINEPREFIX=~/.wine-test > > rm -rf $WINEPREFIX > > wineprefixcreate > > winecfg (set to emulate virtual desktop, nothing else touched) > > If virtual desktop means not managed windows then that's what broke > the test. Well, both emulate virtual desktop and managed windows are both ticked. I switched off the desktop emulation and reran the tests, giving me the following errors: msg.c:8624: Test failed: 15: ShowWindow(SW_HIDE): in msg 0x0046 expecting wParam 0x93 got 0x83 msg.c:8624: Test failed: 15: ShowWindow(SW_HIDE): in msg 0x0047 expecting wParam 0x1893 got 0x1883 This is on xorg 6.9.0-50.24(a)i586, KDE 3.5.1 Cheers, Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

Dec. 27, 2006

Re: ole32: Marshal the ORPCTHAT structure prefixed to the server data.

by Robert Shearman

Dmitry Timoshkov wrote: > "Robert Shearman" <rob(a)codeweavers.com> wrote: > >> + *hook_count = 0; >> + *extension_count = 0; >> + >> + EnterCriticalSection(&csChannelHook); >> + >> + LIST_FOR_EACH_ENTRY(entry, &channel_hooks, struct >> channel_hook_entry, entry) >> + (*hook_count)++; >> + >> + if (hook_count) >> + *data = HeapAlloc(GetProcessHeap(), 0, *hook_count * >> sizeof(struct channel_hook_buffer_data)); >> + else >> + *data = NULL; > > Perhaps 'if (hook_count)' should be 'if (*hook_count)' ? Is that a typo? Yes, well spotted. -- Rob Shearman

Dec. 27, 2006

Re: ole32: Marshal the ORPCTHAT structure prefixed to the server data.

by Dmitry Timoshkov

"Robert Shearman" <rob(a)codeweavers.com> wrote: > + *hook_count = 0; > + *extension_count = 0; > + > + EnterCriticalSection(&csChannelHook); > + > + LIST_FOR_EACH_ENTRY(entry, &channel_hooks, struct channel_hook_entry, entry) > + (*hook_count)++; > + > + if (hook_count) > + *data = HeapAlloc(GetProcessHeap(), 0, *hook_count * sizeof(struct channel_hook_buffer_data)); > + else > + *data = NULL; Perhaps 'if (hook_count)' should be 'if (*hook_count)' ? Is that a typo? -- Dmitry.

Dec. 27, 2006

Re: oleaut32: Fix failing VarMod tests in WinXP, fix VarMod(VT_DECIMAL) in Wine

by Alexandre Julliard

Alex Villacís Lasso <a_villacis(a)palosanto.com> writes: > BTW, in case nobody knows, the BOOL->BSTR conversion is localized in > WinXP (so that in Spanish locales, conversion to strings gives > "Verdadero", not "True" as tested). Apparently it is *not* localized > in Win98SE. I don't have any other Windows versions available, but > this means at least two test failures on non-English versions of > WinXP. Does this mean that a comparison to a specific string is > pointless and should be removed? It should not be removed, but it can be disabled when the current locale is not English. -- Alexandre Julliard julliard(a)winehq.org

Dec. 27, 2006

Re: Vijay Kiran Kamuju : comctl32: MonthCalendar - Fix highlightingof current date.

by Dmitry Timoshkov

"Lei Zhang" <thestig(a)google.com> wrote: >I see the problem Duane reports as well. As long as you stay with in > the current month, the current day will remain highlighted even if you > click another date. It will disappear if you (a) highlight the current > date, then another date, or (b) if you go to another month. > > On 12/26/06, Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: >> Hi, >> >> It did it for me. when I did the tests. >> I will check again. >> Currently I am out of net access for atleast 2 weeks. >> Shifting to a new room(hostel). >> So I will test it soon, please bear with me, and also please test with >> my other patch(month calander one). May be I should leave that for >> Dan's students. >> But I will fix it as this is my bug, anyways. Since 2 independent persons do see that the patch has caused a regression, and it's not going to be fixed in a reasonable amount of time, I'd suggest to revert that patch as an obviously wrong then. -- Dmitry.

Dec. 27, 2006

Re: Vijay Kiran Kamuju : comctl32: MonthCalendar - Fix highlighting of current date.

by Lei Zhang

I see the problem Duane reports as well. As long as you stay with in the current month, the current day will remain highlighted even if you click another date. It will disappear if you (a) highlight the current date, then another date, or (b) if you go to another month. On 12/26/06, Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: > Hi, > > It did it for me. when I did the tests. > I will check again. > Currently I am out of net access for atleast 2 weeks. > Shifting to a new room(hostel). > So I will test it soon, please bear with me, and also please test with > my other patch(month calander one). May be I should leave that for > Dan's students. > But I will fix it as this is my bug, anyways. > > bye, > VJ > > On 12/26/06, Duane Clark <dclark(a)akamail.com> wrote: > > Alexandre Julliard wrote: > > > Module: wine > > > Branch: master > > > Commit: c5b8df481f2bb0362b57188a8c7df423030ba8b0 > > > URL: http://source.winehq.org/git/wine.git/?a=commit;h=c5b8df481f2bb0362b57188a8… > > > > > > Author: Vijay Kiran Kamuju <infyquest(a)gmail.com> > > > Date: Sun Dec 24 13:31:56 2006 +0530 > > > > > > comctl32: MonthCalendar - Fix highlighting of current date. > > > > That does highlight the current date on startup. But I notice that when > > I click another date, the current date doesn't get unhighlighted. > > > > > > > > >

Dec. 27, 2006

Re: Vijay Kiran Kamuju : comctl32: MonthCalendar - Fix highlighting of current date.

by Vijay Kiran Kamuju

Hi, It did it for me. when I did the tests. I will check again. Currently I am out of net access for atleast 2 weeks. Shifting to a new room(hostel). So I will test it soon, please bear with me, and also please test with my other patch(month calander one). May be I should leave that for Dan's students. But I will fix it as this is my bug, anyways. bye, VJ On 12/26/06, Duane Clark <dclark(a)akamail.com> wrote: > Alexandre Julliard wrote: > > Module: wine > > Branch: master > > Commit: c5b8df481f2bb0362b57188a8c7df423030ba8b0 > > URL: http://source.winehq.org/git/wine.git/?a=commit;h=c5b8df481f2bb0362b57188a8… > > > > Author: Vijay Kiran Kamuju <infyquest(a)gmail.com> > > Date: Sun Dec 24 13:31:56 2006 +0530 > > > > comctl32: MonthCalendar - Fix highlighting of current date. > > That does highlight the current date on startup. But I notice that when > I click another date, the current date doesn't get unhighlighted. > > >

Dec. 27, 2006

Re: make test failure

by Dmitry Timoshkov

"Kai Blin" <kai.blin(a)gmail.com> wrote: > over christmas, I decided to give make test another try. > > I'm running this on an openSUSE 10.1 box, ati radeon mobility x300 with open > source drivers. (Probably unimportant for the errors I'm getting) > > My procedure to get the tests setup were: > > export WINEPREFIX=~/.wine-test > rm -rf $WINEPREFIX > wineprefixcreate > winecfg (set to emulate virtual desktop, nothing else touched) If virtual desktop means not managed windows then that's what broke the test. -- Dmitry.

Dec. 27, 2006

Re: Vijay Kiran Kamuju : comctl32: MonthCalendar - Fix highlighting of current date.

by Duane Clark

Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: c5b8df481f2bb0362b57188a8c7df423030ba8b0 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=c5b8df481f2bb0362b57188a8… > > Author: Vijay Kiran Kamuju <infyquest(a)gmail.com> > Date: Sun Dec 24 13:31:56 2006 +0530 > > comctl32: MonthCalendar - Fix highlighting of current date. That does highlight the current date on startup. But I notice that when I click another date, the current date doesn't get unhighlighted.

Dec. 26, 2006

Re: [Winmm/winealsa] Don't use asynchronous callbacks in dsound any more

by Eric Pouech

Maarten Lankhorst a écrit : > 2006/12/25, Eric Pouech <eric.pouech(a)wanadoo.fr>: >> Maarten, >> >> nice work on Alsa (which is definitively needed !!) >> >> a couple of comments: >> - I know the winmm code (and drivers) is crippled by bad synchronisation >> tricks (like cleaning a field in a structure to signal a thread). This >> is bad (TM). So I'd suggest using here a real synchronisation object. > > Well, what I have now works well enough, thread is sure to be killed, > which makes life easier. I don't see the point in making code more > complicated then it needs to be. the compiler may just optimize things away, and there's no guarantee that NULL:ing a handle in a struct share across threads will always do what you want. For the sake of record, some of the others place do mark the field as volatile to make things a bit more clearer. > >> - I wonder if it's a good idea to create another thread for this... but >> before merging all existing drivers' threads into a single one, I'd >> suggest using the fd oriented functions & poll (see >> snd_pcm_poll_descriptors and friends) instead of snd_pcm_wait, that'll >> ease up the future work. > > I'm not sure if it's a good thing either to create a new thread for > it, but in the current driver model there are no other alternatives, > you are right it is easy enough to use poll(), but basically all I > would be doing is copy the code from snd_pcm_wait(), which does it for > me. If anyone wants to use poll() it is easy enough to copy the code > 1:1 from the LGPL alsa sound library. However I saw no need for it and > to keep the code simple I just used snd_pcm_wait. > > See alsa-lib/src/pcm/pcm.c for how snd_pcm_wait is implemented: It > just uses poll() I know, that's why I'm asking you to do it ;-) A+

Dec. 26, 2006

Re: oleaut32: Fix failing VarMod tests in WinXP, fix VarMod(VT_DECIMAL) in Wine

by Alex Villacís Lasso

Robert Shearman escribió: > a_villacis(a)palosanto.com wrote: >> In a preparation for a possible implementation of IDispatch >> tests in oleaut32, I decided to clean up the failing tests in >> Windows XP: >> > > Great, thanks for fixing this. > > I was about to do this myself. It's about time we get the number of > failing tests on XP as close to zero as possible. > BTW, in case nobody knows, the BOOL->BSTR conversion is localized in WinXP (so that in Spanish locales, conversion to strings gives "Verdadero", not "True" as tested). Apparently it is *not* localized in Win98SE. I don't have any other Windows versions available, but this means at least two test failures on non-English versions of WinXP. Does this mean that a comparison to a specific string is pointless and should be removed? -- The following cryptic message was allegedly found in the inner edge of a Windows XP installation CD: 4F6E65204F5320746F2072756C65207468656D20616C6C2C204F6E65204F5320746F2066696E6420 7468656D2C0D0A4F6E65204F5320746F206272696E67207468656D20616C6C20616E6420696E2074 6865206461726B6E6573732062696E64207468656D2E0A It is rumored that only a true Unix Wizard can decypher this mysterious message, which supposedly encodes the true nature and purpose of the software.

Dec. 26, 2006

make test failure

by Kai Blin

Hi folks, over christmas, I decided to give make test another try. I'm running this on an openSUSE 10.1 box, ati radeon mobility x300 with open source drivers. (Probably unimportant for the errors I'm getting) My procedure to get the tests setup were: export WINEPREFIX=~/.wine-test rm -rf $WINEPREFIX wineprefixcreate winecfg (set to emulate virtual desktop, nothing else touched) make test This fails in user32, with the attached error message: Any thoughts? Cheers, Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

Dec. 26, 2006

window managment bug

by Clinton Stimpson

Does bug #6006 fall under window management? When buttons are turned invisible, the invalidated area in the parent window is not repainted, so it looks like the button is still there. Also, there's two invisible buttons that seem to repaint themselves when the parent window resizes, clicking on them does nothing. Any ideas where I can go to track this down? Thanks, Clinton

Dec. 26, 2006

Re: [Winmm/winealsa] Don't use asynchronous callbacks in dsound any more

by Maarten Lankhorst

2006/12/25, Eric Pouech <eric.pouech(a)wanadoo.fr>: > Maarten, > > nice work on Alsa (which is definitively needed !!) > > a couple of comments: > - I know the winmm code (and drivers) is crippled by bad synchronisation > tricks (like cleaning a field in a structure to signal a thread). This > is bad (TM). So I'd suggest using here a real synchronisation object. Well, what I have now works well enough, thread is sure to be killed, which makes life easier. I don't see the point in making code more complicated then it needs to be. > - I wonder if it's a good idea to create another thread for this... but > before merging all existing drivers' threads into a single one, I'd > suggest using the fd oriented functions & poll (see > snd_pcm_poll_descriptors and friends) instead of snd_pcm_wait, that'll > ease up the future work. I'm not sure if it's a good thing either to create a new thread for it, but in the current driver model there are no other alternatives, you are right it is easy enough to use poll(), but basically all I would be doing is copy the code from snd_pcm_wait(), which does it for me. If anyone wants to use poll() it is easy enough to copy the code 1:1 from the LGPL alsa sound library. However I saw no need for it and to keep the code simple I just used snd_pcm_wait. See alsa-lib/src/pcm/pcm.c for how snd_pcm_wait is implemented: It just uses poll() > Maarten Lankhorst a écrit : > > Instead of using asynchronous callbacks that uses signals, use a > > seperate thread that can be cancelled, this prevents deadlock issues. > > > > Basically we use snd_pcm_wait() that tells us when enough room is free > > to commit another buffer, then we commit the previous buffer and make > > the next buffer ready. > > .....

Dec. 26, 2006

Re: oleaut32: preliminary support for VT_DISPATCH as parameters to VarAdd (and other 2-operand operations) (try 3)

by Alexandre Julliard

a_villacis(a)palosanto.com writes: > This is another attempt to add IDispatch support to several 2-operand > functions. Now the macro was removed and the VT_DISPATCH handling was > copied to every affected function. Thanks, it's better that way. Still, it seems to me you don't always clean the variants properly, you should do some sort of "goto end" in all cases instead of simply returning. Also renaming the function parameters in most cases is not necessary. I'd also suggest to do a separate patch for each function, especially since in some functions a bit of restructuring will be needed to cleanup properly on error. -- Alexandre Julliard julliard(a)winehq.org

Dec. 26, 2006

Re: dlls/kernel32/tests: test failure in locale.c

by Eric Pouech

Claudio Fontana a écrit : > Hello, > > while tweaking other things in kernel32, I noticed that latest version > fails a test in locale.c: > > $ cd dlls/kernel32/tests > $ make test > ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p > kernel32_test.exe.so locale.c && touch locale.ok > locale.c:1990: Test failed: Enumerated grp locale 1084 not valid > locale.c:1990: Test failed: Enumerated grp locale 1170 not valid > locale.c:1990: Test failed: Enumerated grp locale 1171 not valid > locale.c:1990: Test failed: Enumerated grp locale 2108 not valid > locale.c:1990: Test failed: Enumerated grp locale 3132 not valid > make: *** [locale.ok] Error 5 > > Hope this helps. this is because you don't run the tests from a newly created environment some programs you've installed likely declared those locales, which wine doesn't completly handle A+

Dec. 26, 2006

adding a data point to ALSA vs Wine sound discussion

by Molle Bestefich

Adding a data point to the ALSA and Wine sound discussion. ALSA has a general problem with: * Doubling volume * Playing sound bites two times when it doesn't receive data fast enough from an application. I tried playing a video file over a network using a non-wine player, then paused the network stream. The sound paused. Then restarted the network stream. The volume now doubles for the next sound bite (always), and the next sound bite is played twice (sometimes). So, just in case anyone is hearing the above two effects, they may actually be bugs in ALSA occuring when samples are delivered slower than expected, rather than bugs in Wine.

Dec. 26, 2006

more meaningful traces?

by Lei Zhang

Hi, I noticed several files in dlls/winmm have a getMessage() function to translate message numbers to message names. This is extremely helpful for debug traces, where one can immediately see the name of the messages sent, instead of wondering what 0x105 is. So my question is, why is winmm the only component translating its message? Is there some downside to having message names in the traces? Happy Holidays! - Lei

Dec. 26, 2006

Re: [2/2] wined3d: Restore texture bindings in the FBO code

by H. Verbeet

On 25/12/06, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Why are you not using glPushAttrib / glPopAttrib? The relevant bit to push would be GL_TEXTURE_BIT, but that pushes the bindings for all texture units and pretty much all related state, ie glTexParameter & glTexEnv state. Since we're only interested in the texture binding, I doubt it would be more efficient, and we would have to make sure the texture isn't currently bound to some unit.

Dec. 25, 2006

Re: [2/2] wined3d: Restore texture bindings in the FBO code

by Stefan Dösinger

Am 25.12.2006 um 17:12 schrieb H. Verbeet: > Previously all textures were (re)bound each DrawPrimitive call. With > the new state management only dirty textures are bound, so we need to > restore the texture binding if we change it. > > Changelog: > - Restore texture bindings in the FBO code > <wined3d_fbo_texture_binding.diff.txt> Why are you not using glPushAttrib / glPopAttrib?

Dec. 25, 2006

Re: [comctl32] MonthCalendar - Fix wrong date selected whenclicknext/prev months day (#6967)

by Dmitry Timoshkov

"Vijay Kiran Kamuju" <infyquest(a)gmail.com> wrote: >> > - return TRUE; >> > + /*return TRUE;*/ >> >> If you are not sure that the return should be removed, it's a sign that you >> need a test case, just commenting it out without any explanation is not a solution. >> Same comment to all other similar cases. > Should I add comments or Do I have to add test cases? That's up to you, but having any code simply commented out without a single word of an explanation is confusing and misleading. I'd say that having a commented out 'return' with any sort of an explanation is bad IMO. > test cases are bit difficult as they are all UI based, and dont have > exact testcases. > As I rearranged the codes and removed the returns as the necessary > messages are not being sent (in order as observed on windows using > both old and latest versions of ControlSpy) > If you think I should add comments, I would be glad to modify. > Tests are a bit difficult :( (if you can help, I will try) Of course the tests are preferable, but if it's a pure UI thing it's pretty hard to test, yes. Message sequences can be tested, but that's a bit trickier since comctl32 doesn't have a message sequnce test infrastructure. > Should I send a new version of the patch, with the changes? I don't think that the patch will be magically fixed on its own. -- Dmitry.

Dec. 25, 2006

Re: [comctl32] MonthCalendar - Fix wrong date selected when clicknext/prev months day (#6967)

by Vijay Kiran Kamuju

Hi, On 12/25/06, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > "Vijay Kiran Kamuju" <infyquest(a)gmail.com> wrote: > > > - retval = *daypos + (7 * *weekpos) - firstDay; > > + retval = *daypos + ((7 * *weekpos) - firstDay); > > return retval; > > } > > This change doesn't make any difference, neither in functionality, > nor in readability IMO. Please avoid this kind of changes, it only > clutters the patch, making it hard to see what is the real change. > This was a mistake I didnt notice. > > - lpht->st.wDay = MONTHCAL_MonthLength(lpht->st.wMonth,lpht->st.wYear) -day; > > + lpht->st.wDay = day+MONTHCAL_MonthLength(lpht->st.wMonth,lpht->st.wYear) ; > > A couple of spaces around '+' won't hurt, and a space before ';' doesn't match > an existing code style. > Will change this one, I was bit out of style. > > - return TRUE; > > + /*return TRUE;*/ > > If you are not sure that the return should be removed, it's a sign that you > need a test case, just commenting it out without any explanation is not a solution. > Same comment to all other similar cases. Should I add comments or Do I have to add test cases? test cases are bit difficult as they are all UI based, and dont have exact testcases. As I rearranged the codes and removed the returns as the necessary messages are not being sent (in order as observed on windows using both old and latest versions of ControlSpy) If you think I should add comments, I would be glad to modify. Tests are a bit difficult :( (if you can help, I will try) > > > + MONTHCAL_CopyTime(&infoPtr->minSel,&nmsc.stSelStart); > > + MONTHCAL_CopyTime(&infoPtr->maxSel,&nmsc.stSelEnd); > > nmsc.nmhdr.hwndFrom = infoPtr->hwndSelf; > > nmsc.nmhdr.idFrom = GetWindowLongPtrW(infoPtr->hwndSelf, GWLP_ID); > > nmsc.nmhdr.code = MCN_SELCHANGE; > > - MONTHCAL_CopyTime(&infoPtr->minSel,&nmsc.stSelStart); > > - MONTHCAL_CopyTime(&infoPtr->maxSel,&nmsc.stSelEnd); > > This change is not needed. I agree. This came up because it while doing regression testing with new control spy V2.0 where MULTISELECT message is not eanbled by default. Should I send a new version of the patch, with the changes? Waiting for your reply. --- VJ

Dec. 25, 2006

Re: Building a full win32 winetest.exe

by Hans Leidekker

On Monday 25 December 2006 11:22, Paul Vriens wrote: > These are the MinGW packages I'm currently using: > > mingw-binutils-2.16.91-9hl > mingw-w32api-3.6-18hl > mingw-gcc-core-3.4.5-13hl > mingw-runtime-3.9-18hl I think I'll get around to building a new set of RPMs this week. Lets go for a Wine 1.0 release without any failing test on XP. -Hans

Dec. 25, 2006

Re: [comctl32] MonthCalendar - Fix wrong date selected when clicknext/prev months day (#6967)

by Dmitry Timoshkov

"Vijay Kiran Kamuju" <infyquest(a)gmail.com> wrote: > - retval = *daypos + (7 * *weekpos) - firstDay; > + retval = *daypos + ((7 * *weekpos) - firstDay); > return retval; > } This change doesn't make any difference, neither in functionality, nor in readability IMO. Please avoid this kind of changes, it only clutters the patch, making it hard to see what is the real change. > - lpht->st.wDay = MONTHCAL_MonthLength(lpht->st.wMonth,lpht->st.wYear) -day; > + lpht->st.wDay = day+MONTHCAL_MonthLength(lpht->st.wMonth,lpht->st.wYear) ; A couple of spaces around '+' won't hurt, and a space before ';' doesn't match an existing code style. > - return TRUE; > + /*return TRUE;*/ If you are not sure that the return should be removed, it's a sign that you need a test case, just commenting it out without any explanation is not a solution. Same comment to all other similar cases. > + MONTHCAL_CopyTime(&infoPtr->minSel,&nmsc.stSelStart); > + MONTHCAL_CopyTime(&infoPtr->maxSel,&nmsc.stSelEnd); > nmsc.nmhdr.hwndFrom = infoPtr->hwndSelf; > nmsc.nmhdr.idFrom = GetWindowLongPtrW(infoPtr->hwndSelf, GWLP_ID); > nmsc.nmhdr.code = MCN_SELCHANGE; > - MONTHCAL_CopyTime(&infoPtr->minSel,&nmsc.stSelStart); > - MONTHCAL_CopyTime(&infoPtr->maxSel,&nmsc.stSelEnd); This change is not needed. -- Dmitry.

Dec. 25, 2006

Re: [Winmm/winealsa] Don't use asynchronous callbacks in dsound any more

by Eric Pouech

Maarten, nice work on Alsa (which is definitively needed !!) a couple of comments: - I know the winmm code (and drivers) is crippled by bad synchronisation tricks (like cleaning a field in a structure to signal a thread). This is bad (TM). So I'd suggest using here a real synchronisation object. - I wonder if it's a good idea to create another thread for this... but before merging all existing drivers' threads into a single one, I'd suggest using the fd oriented functions & poll (see snd_pcm_poll_descriptors and friends) instead of snd_pcm_wait, that'll ease up the future work. Maarten Lankhorst a écrit : > Instead of using asynchronous callbacks that uses signals, use a > seperate thread that can be cancelled, this prevents deadlock issues. > > Basically we use snd_pcm_wait() that tells us when enough room is free > to commit another buffer, then we commit the previous buffer and make > the next buffer ready. > > Since snd_pcm_wait() uses poll(), we don't have signals in winealsa > any more. > ------------------------------------------------------------------------ > > diff --git a/dlls/winmm/winealsa/audio.c b/dlls/winmm/winealsa/audio.c > index 6043680..e1676ed 100644 > --- a/dlls/winmm/winealsa/audio.c > +++ b/dlls/winmm/winealsa/audio.c > @@ -6,6 +6,7 @@ > * Copyright 2002 Eric Pouech > * 2002 Marco Pietrobono > * 2003 Christian Costa : WaveIn support > + * 2006 Maarten Lankhorst > * > * This library is free software; you can redistribute it and/or > * modify it under the terms of the GNU Lesser General Public > @@ -70,11 +71,6 @@ WINE_DEFAULT_DEBUG_CHANNEL(wave); > > #ifdef HAVE_ALSA > > -/* internal ALSALIB functions */ > -/* FIXME: we shouldn't be using internal functions... */ > -snd_pcm_uframes_t _snd_pcm_mmap_hw_ptr(snd_pcm_t *pcm); > - > - > /* state diagram for waveOut writing: > * > * +---------+-------------+---------------+---------------------------------+ > @@ -2627,7 +2623,6 @@ #undef EXIT_ON_ERROR > snd_pcm_hw_params_free(wwo->hw_params); > wwo->hw_params = hw_params; > > - > return wodNotifyClient(wwo, WOM_OPEN, 0L, 0L); > > errexit: > @@ -3045,11 +3040,8 @@ struct IDsDriverBufferImpl > DWORD mmap_buflen_bytes; > snd_pcm_uframes_t mmap_buflen_frames; > snd_pcm_channel_area_t * mmap_areas; > - snd_async_handler_t * mmap_async_handler; > snd_pcm_uframes_t mmap_ppos; /* play position */ > - > - /* Do we have a direct hardware buffer - SND_PCM_TYPE_HW? */ > - int mmap_mode; > + HANDLE mmap_thread; > }; > > static void DSDB_CheckXRUN(IDsDriverBufferImpl* pdbi) > @@ -3076,71 +3068,66 @@ static void DSDB_CheckXRUN(IDsDriverBuff > } > } > > -static void DSDB_MMAPCopy(IDsDriverBufferImpl* pdbi, int mul) > +/** > + * The helper thread for DirectSound > + * > + * Basically it does an infinite loop until it is told to die > + * > + * snd_pcm_wait() is a call that polls the sound buffer and waits > + * until there is at least 1 period free before it returns. > + * > + * We then commit the buffer filled by the owner of this > + * IDSDriverBuffer */ > +static DWORD CALLBACK DBSB_MMAPStart(LPVOID data) > { > + IDsDriverBufferImpl* pdbi = (IDsDriverBufferImpl*)data; > WINE_WAVEDEV * wwo = &(WOutDev[pdbi->drv->wDevID]); > - snd_pcm_uframes_t period_size; > - snd_pcm_sframes_t avail; > - int err; > - int dir=0; > - > + snd_pcm_uframes_t frames, wanted, ofs; > const snd_pcm_channel_area_t *areas; > - snd_pcm_uframes_t ofs; > - snd_pcm_uframes_t frames; > - snd_pcm_uframes_t wanted; > > - if ( !pdbi->mmap_buffer || !wwo->hw_params || !wwo->pcm) > - return; > - > - err = snd_pcm_hw_params_get_period_size(wwo->hw_params, &period_size, &dir); > - avail = snd_pcm_avail_update(wwo->pcm); > + TRACE("\n"); > > - DSDB_CheckXRUN(pdbi); > - > - TRACE("avail=%d, mul=%d\n", (int)avail, mul); > - > - frames = pdbi->mmap_buflen_frames; > - > - EnterCriticalSection(&pdbi->mmap_crst); > + if (areas != pdbi->mmap_areas || areas->addr != pdbi->mmap_areas->addr) > + FIXME("Can't access sound driver's buffer directly.\n"); > > - /* we want to commit the given number of periods, or the whole lot */ > - wanted = mul == 0 ? frames : period_size * 2; > + while (pdbi->mmap_thread) > + { > + snd_pcm_wait(wwo->pcm, -1); > + wanted = frames = pdbi->mmap_buflen_frames; > + DSDB_CheckXRUN(pdbi); > > - snd_pcm_mmap_begin(wwo->pcm, &areas, &ofs, &frames); > - if (areas != pdbi->mmap_areas || areas->addr != pdbi->mmap_areas->addr) > - FIXME("Can't access sound driver's buffer directly.\n"); > - > - /* mark our current play position */ > - pdbi->mmap_ppos = ofs; > - > - if (frames > wanted) > - frames = wanted; > - > - err = snd_pcm_mmap_commit(wwo->pcm, ofs, frames); > - > - /* Check to make sure we committed all we want to commit. ALSA > - * only gives a contiguous linear region, so we need to check this > - * in case we've reached the end of the buffer, in which case we > - * can wrap around back to the beginning. */ > - if (frames < wanted) { > - frames = wanted -= frames; > + EnterCriticalSection(&pdbi->mmap_crst); > snd_pcm_mmap_begin(wwo->pcm, &areas, &ofs, &frames); > snd_pcm_mmap_commit(wwo->pcm, ofs, frames); > - } > > - LeaveCriticalSection(&pdbi->mmap_crst); > + /* mark our current play position */ > + pdbi->mmap_ppos = ofs; > + > + /* Check to make sure we committed all we want to commit. ALSA > + * only gives a contiguous linear region, so we need to check this > + * in case we've reached the end of the buffer, in which case we > + * can wrap around back to the beginning. */ > + if (frames < wanted) { > + frames = wanted - frames; > + snd_pcm_mmap_begin(wwo->pcm, &areas, &ofs, &frames); > + snd_pcm_mmap_commit(wwo->pcm, ofs, frames); > + } > + LeaveCriticalSection(&pdbi->mmap_crst); > + } > + TRACE("Destroyed MMAP thread\n"); > + return 0; > } > > -static void DSDB_PCMCallback(snd_async_handler_t *ahandler) > +/** > + * Cancel running MMAP thread */ > +static void DBSB_MMAPStop(IDsDriverBufferImpl* This) > { > - int periods; > - /* snd_pcm_t * handle = snd_async_handler_get_pcm(ahandler); */ > - IDsDriverBufferImpl* pdbi = snd_async_handler_get_callback_private(ahandler); > - TRACE("callback called\n"); > - > - /* Commit another block (the entire buffer if it's a direct hw buffer) */ > - periods = pdbi->mmap_mode == SND_PCM_TYPE_HW ? 0 : 1; > - DSDB_MMAPCopy(pdbi, periods); > + HANDLE Thread; > + TRACE("Destroying MMAP thread\n"); > + if (This->mmap_thread == NULL) return; > + Thread = This->mmap_thread; > + This->mmap_thread = NULL; > + WaitForSingleObject(Thread, INFINITE); > } > > /** > @@ -3158,21 +3145,47 @@ static int DSDB_CreateMMAP(IDsDriverBuff > unsigned int bits_per_sample; > unsigned int bits_per_frame; > int err; > + int mmap_mode; > + > + mmap_mode = snd_pcm_type(wwo->pcm); > + pdbi->mmap_thread = NULL; > + > + /* If we have a software buffer, change buffer size to only get 2 > + * > + * Why 2? We want a small number so that we don't get ahead of the > + * DirectSound mixer. But we don't want to ever let the buffer get > + * completely empty - having 2 periods gives us time to commit another > + * period when the first expires. > + * > + * The potential for buffer underrun is high, but that's the reality > + * of using a translated buffer (the whole point of DirectSound is > + * to provide direct access to the hardware). > + */ > > - err = snd_pcm_hw_params_get_format(wwo->hw_params, &format); > - err = snd_pcm_hw_params_get_buffer_size(wwo->hw_params, &frames); > - err = snd_pcm_hw_params_get_channels(wwo->hw_params, &channels); > - bits_per_sample = snd_pcm_format_physical_width(format); > - bits_per_frame = bits_per_sample * channels; > - pdbi->mmap_mode = snd_pcm_type(wwo->pcm); > - > - if (pdbi->mmap_mode == SND_PCM_TYPE_HW) { > + if (mmap_mode == SND_PCM_TYPE_HW) { > TRACE("mmap'd buffer is a hardware buffer.\n"); > } > else { > + snd_pcm_uframes_t psize; > + err = snd_pcm_hw_params_get_period_size(wwo->hw_params, &psize, NULL); > + /* Set only a buffer of 2 period sizes, to decrease latency */ > + if (err >= 0) > + err = snd_pcm_hw_params_set_buffer_size_near(wwo->pcm, wwo->hw_params, &psize); > + > + > + psize *= 2; > + if (err < 0) { > + ERR("Errno %d (%s) occured when setting buffer size\n", err, strerror(errno)); > + } > TRACE("mmap'd buffer is an ALSA emulation of hardware buffer.\n"); > } > > + err = snd_pcm_hw_params_get_format(wwo->hw_params, &format); > + err = snd_pcm_hw_params_get_buffer_size(wwo->hw_params, &frames); > + err = snd_pcm_hw_params_get_channels(wwo->hw_params, &channels); > + bits_per_sample = snd_pcm_format_physical_width(format); > + bits_per_frame = bits_per_sample * channels; > + > if (TRACE_ON(wave)) > ALSA_TraceParameters(wwo->hw_params, NULL, FALSE); > > @@ -3208,19 +3221,13 @@ static int DSDB_CreateMMAP(IDsDriverBuff > InitializeCriticalSection(&pdbi->mmap_crst); > pdbi->mmap_crst.DebugInfo->Spare[0] = (DWORD_PTR)"WINEALSA_mmap_crst"; > > - err = snd_async_add_pcm_handler(&pdbi->mmap_async_handler, wwo->pcm, DSDB_PCMCallback, pdbi); > - if ( err < 0 ) > - { > - ERR("add_pcm_handler failed. reason: %s\n", snd_strerror(err)); > - return DSERR_GENERIC; > - } > - > return DS_OK; > } > > static void DSDB_DestroyMMAP(IDsDriverBufferImpl* pdbi) > { > TRACE("mmap buffer %p destroyed\n", pdbi->mmap_buffer); > + DBSB_MMAPStop(pdbi); > pdbi->mmap_areas = NULL; > pdbi->mmap_buffer = NULL; > pdbi->mmap_crst.DebugInfo->Spare[0] = 0; > @@ -3254,6 +3261,7 @@ static ULONG WINAPI IDsDriverBufferImpl_ > > if (refCount) > return refCount; > + IDsDriverBuffer_Stop(iface); > if (This == This->drv->primary) > This->drv->primary = NULL; > DSDB_DestroyMMAP(This); > @@ -3372,29 +3380,13 @@ static HRESULT WINAPI IDsDriverBufferImp > err = snd_pcm_prepare(wwo->pcm); > state = snd_pcm_state(wwo->pcm); > } > - if ( state == SND_PCM_STATE_PREPARED ) > + if ( state == SND_PCM_STATE_PREPARED && This->mmap_thread == NULL) > { > - /* If we have a direct hardware buffer, we can commit the whole lot > - * immediately (periods = 0), otherwise we prime the queue with only > - * 2 periods. > - * > - * Why 2? We want a small number so that we don't get ahead of the > - * DirectSound mixer. But we don't want to ever let the buffer get > - * completely empty - having 2 periods gives us time to commit another > - * period when the first expires. > - * > - * The potential for buffer underrun is high, but that's the reality > - * of using a translated buffer (the whole point of DirectSound is > - * to provide direct access to the hardware). > - * > - * A better implementation would use the buffer Lock() and Unlock() > - * methods to determine how far ahead we can commit, and to rewind if > - * necessary. > - */ > - int periods = This->mmap_mode == SND_PCM_TYPE_HW ? 0 : 2; > - > - DSDB_MMAPCopy(This, periods); > - err = snd_pcm_start(wwo->pcm); > + err = snd_pcm_start(wwo->pcm); > + This->mmap_thread = CreateThread(NULL, 0, DBSB_MMAPStart, (LPVOID)(DWORD)This, 0, NULL); > + if (This->mmap_thread == NULL) > + return DSERR_GENERIC; > + SetThreadPriority(This->mmap_thread, THREAD_PRIORITY_TIME_CRITICAL); > } > return DS_OK; > } > @@ -3419,6 +3411,8 @@ static HRESULT WINAPI IDsDriverBufferImp > return DS_OK; > } > > + DBSB_MMAPStop(This); > + > if ( ( err = snd_pcm_drop(wwo->pcm)) < 0 ) > { > ERR("error while stopping pcm: %s\n", snd_strerror(err)); > > ------------------------------------------------------------------------ > > >

Dec. 25, 2006

dlls/kernel32/tests: test failure in locale.c

by Claudio Fontana

Hello, while tweaking other things in kernel32, I noticed that latest version fails a test in locale.c: $ cd dlls/kernel32/tests $ make test ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.exe.so locale.c && touch locale.ok locale.c:1990: Test failed: Enumerated grp locale 1084 not valid locale.c:1990: Test failed: Enumerated grp locale 1170 not valid locale.c:1990: Test failed: Enumerated grp locale 1171 not valid locale.c:1990: Test failed: Enumerated grp locale 2108 not valid locale.c:1990: Test failed: Enumerated grp locale 3132 not valid make: *** [locale.ok] Error 5 Hope this helps. Claudio

Dec. 25, 2006

Re: kernel32 (profile.c): current section and key implementation

by Claudio Fontana

Hello Robert, On 12/24/06, Robert Shearman <rob(a)codeweavers.com> wrote: > Hi Claudio, > > The patch looks good, apart from the specific version check for win95. > Do you think you could add some tests to our test framework > (dlls/kernel32/tests) to test for this issue that you've found. Then the > tests could be run on a variety of platforms to see if it is only win95 > that has that specific behaviour or if the original author of the > comment was wrong about that. > > The tests that fail on Wine will then determine what needs to be fixed. > > Thanks, > > -- > Rob Shearman Sure, here's what I came up with. I do not understand, however, what the difference between result and result9x in the test structure is. Is result9x the result expected on windows 95/98? I have set result == result9x for my test for now. I do not know whether the comment (and code) of the original author is correct, and have no access to a Windows 95 installation to test it (or any other Windows version for that matter). I do not respect the 80 columns limit in the test, since the file already violates it. The complete change would be (also attached): --- dlls/kernel32/profile.c 21 Dec 2006 16:37:29 -0000 1.4 +++ dlls/kernel32/profile.c 25 Dec 2006 00:27:55 -0000 @@ -599,9 +599,8 @@ while (*section) { - if ( ((*section)->name[0]) - && (!(strncmpiW( (*section)->name, section_name, seclen ))) - && (((*section)->name)[seclen] == '\0') ) + if (!strncmpiW((*section)->name, section_name, seclen) && + ((*section)->name)[seclen] == '\0') { PROFILEKEY **key = &(*section)->key; @@ -959,11 +958,6 @@ if (!def_val) def_val = empty_strW; if (key_name) { - if (!key_name[0]) - { - /* Win95 returns 0 on keyname "". Tested with Likse32 bon 000227 */ - return 0; - } key = PROFILE_Find( &CurProfile->section, section, key_name, FALSE, FALSE); PROFILE_CopyEntry( buffer, (key && key->value) ? key->value : def_val, len, TRUE ); --- dlls/kernel32/tests/profile.c 12 Sep 2006 12:31:37 -0000 1.1 +++ dlls/kernel32/tests/profile.c 25 Dec 2006 00:27:56 -0000 @@ -68,6 +68,8 @@ { SECTION, KEY, "42A94967297", TESTFILE, 1, 42 , 42}, { SECTION, KEY, "B4294967297", TESTFILE, -1, 0 , 0}, { SECTION, KEY, "B4294967297", TESTFILE, 1, 0 , 0}, + { "", KEY, "1", TESTFILE, 0, 1 , 1}, /* 25 */ + { SECTION, "", "1", TESTFILE, 0, 1 , 1}, }; int i, num_test = (sizeof(profileInt)/sizeof(struct _profileInt)); UINT res; @@ -76,8 +78,10 @@ for (i=0; i < num_test; i++) { if (profileInt[i].value) - WritePrivateProfileStringA(SECTION, KEY, profileInt[i].value, - profileInt[i].iniFile); + WritePrivateProfileStringA(profileInt[i].section, + profileInt[i].key, + profileInt[i].value, + profileInt[i].iniFile); res = GetPrivateProfileIntA(profileInt[i].section, profileInt[i].key, profileInt[i].defaultVal, profileInt[i].iniFile); Claudio

Dec. 25, 2006

Re: ntdll: Added stubs for the Rtl*GenericTable* functions

by Patrik Stridvall

On Monday 25 December 2006 00:23, Vitaliy Margolen wrote: > Patrik Stridvall wrote: > >>> In any case having them stubbed in better than nothing. I don't think > >> > >> Not really. As I said before, if a program uses these functions, then > >> it's: a) Probably a kernel driver (which acre currently not supported) > >> b) Won't run at all with stubbed implementation (in case we implement > >> "kernel" > >> > >> From what I've seen Wine prefers to crash instead of returning bogus > >> data or unimplemented functionality. > > > > Any implementation of anything must start somewhere. But OK we can let > > the stubs remain in the spec file if crashing applications is preferred > > and unstub them for each complete implementation. > > > > Still applying the patch minus the .spec change won't hurt and is a good > > start... > > No. Having stubs that won't ever be called in a totally separate file > makes no sense at all. Until you have a real life program that depends > on this functionality, there is no reason to do anything about them. Nothing really important. I was just playing around with the Windows XP EXEs and DLLs. The VSSAPI.DLL which is used for backup uses them. But yes it is filesystem related as you said. It was just something that I noticed was missing and seemed reasonably easy to add. But sure they not really very useful unless 100% correctly implemented. However waiting for an 100% correct patch is not a good strategy either. It is also something that we possible could use in other parts of Wine like OpenGL and/or DirectX. Just because Windows possible just uses them for file system stuff doesn't mean that we need to be equally limited. There reason I wrote the patch was more like cool, Windows have APIs for Splay and AVL trees. Oh they are not implemented yet. Oh well, if I send in a stubbed implementation somebody might start using it and writing the rest. As I said it seem to exists open sourced code that can be borrowed or linked to.

Dec. 25, 2006

Re: oleaut32: Fix failing VarMod tests in WinXP, fix VarMod(VT_DECIMAL) in Wine

by Robert Shearman

a_villacis(a)palosanto.com wrote: > In a preparation for a possible implementation of IDispatch > tests in oleaut32, I decided to clean up the failing tests in > Windows XP: > Great, thanks for fixing this. I was about to do this myself. It's about time we get the number of failing tests on XP as close to zero as possible. -- Rob Shearman

Dec. 24, 2006

Re: ntdll: Added stubs for the Rtl*GenericTable* functions

by Vitaliy Margolen

Patrik Stridvall wrote: >>> In any case having them stubbed in better than nothing. I don't think >> Not really. As I said before, if a program uses these functions, then it's: >> a) Probably a kernel driver (which acre currently not supported) >> b) Won't run at all with stubbed implementation (in case we implement >> "kernel" >> >> From what I've seen Wine prefers to crash instead of returning bogus >> data or unimplemented functionality. > > Any implementation of anything must start somewhere. But OK we can let the > stubs remain in the spec file if crashing applications is preferred and > unstub them for each complete implementation. > > Still applying the patch minus the .spec change won't hurt and is a good > start... No. Having stubs that won't ever be called in a totally separate file makes no sense at all. Until you have a real life program that depends on this functionality, there is no reason to do anything about them. Vitaliy.

Dec. 24, 2006

Re: ntdll: Added stubs for the Rtl*GenericTable* functions

by Patrik Stridvall

On Sunday 24 December 2006 17:53, Vitaliy Margolen wrote: > Patrik Stridvall wrote: > > On Sunday 24 December 2006 05:37, Vitaliy Margolen wrote: > >> Is there are any reason why do you need this functions at all? According > >> to ddk they are part of "Installable File System Drivers". This is a > >> kernel level thing only and no user app should use these routines. > > > > Should, perhaps. Does, well that is a different matter entirely. :-) > > > > Secondly we could perhaps find use for them ourselves. Splay and AVL > > trees are nice. > > > >> Especially stabbing them won't do you any good if something actually > >> using them. But that something has no place to run in Wine yet. > > > > ReactOS has some sort of implementation of them so I guess we can borrow > > Please don't mention ros' code here. It's barred from Wine. Huh? OK, I have been away from Wine development for a few years but it not ReactOS under GPL and/or LGPL? Or have I missed something. In any case implementing Splay and AVL trees is hardly rocket science and just looking at other implementation and being inspired is allowed regardless of license. > > In any case having them stubbed in better than nothing. I don't think > > Not really. As I said before, if a program uses these functions, then it's: > a) Probably a kernel driver (which acre currently not supported) > b) Won't run at all with stubbed implementation (in case we implement > "kernel" > > From what I've seen Wine prefers to crash instead of returning bogus > data or unimplemented functionality. Any implementation of anything must start somewhere. But OK we can let the stubs remain in the spec file if crashing applications is preferred and unstub them for each complete implementation. Still applying the patch minus the .spec change won't hurt and is a good start...

Dec. 24, 2006

Re: winex11.drv: Only try to initialize OpenGL if the display has the GLX extension.

by Patrik Stridvall

On Sunday 24 December 2006 15:17, Roderick Colenbrander wrote: > I have played a bit with Mesa and it indeed works fine without the GLX > extension (just a software renderer ofcourse). I know what error you are > seeing for instance the nvidia drivers output it when GLX isn't present. It > really depends just on the opengl implementation. I see both a OpenGL library error and a Wine error. > Perhaps the right thing > to do is to 'test' the OpenGL implementation by making a GLX call like > glXQueryVersion or whatever. Errors can be caught using a > X11DRV_expect_error. I fear that something like this is the only way. Actually I think it is glXQueryVersion that fails... Not 100% sure though. But OK perhaps it can be caught but the point that 1. Our implementation of OpenGL doesn't work without GLX. Initialization fails and it returns FALSE. 2. It output confusing messages. So applying the patch won't break anything. Anybody wishing to make Wine run OpenGL applications without GLX are welcome to submit additional patches. > > On Sunday 24 December 2006 10:12, Roderick Colenbrander wrote: > > > Hi, > > > > > > I'm not sure if checking for the GLX extension is such a good idea as > > > it > > > > is > > > > > possible to use OpenGL without having the GLX extension. For instance > > > > when > > > > > plain Mesa is used. > > > > OK. The thing is that if I have the OpenGL libraries installed and I try > > to > > run Wine under VNC server I get I complaints that it doesn't have the GLX > > extension. So I found some code that checks for the existence of the > > extension. > > > > In any case the initialisation of OpenGL fails under VNC server so > > something > > needs to be fixed. But perhaps disabling it if GLX doesn't exist is too > > brutal. > > > > What do you suggest?

Dec. 24, 2006

Re: winex11.drv: Only try to initialize OpenGL if the display has the GLX extension.

by Patrik Stridvall

On Sunday 24 December 2006 10:55, Chris Robinson wrote: > On Sunday 24 December 2006 01:12, Roderick Colenbrander wrote: > > Hi, > > > > I'm not sure if checking for the GLX extension is such a good idea as it > > is possible to use OpenGL without having the GLX extension. For instance > > when plain Mesa is used. > > Wine requires GLX 1.2 or higher though, doesn't it? In that case, the GLX > extension would have to be there. Indeed, perhaps I should point out that if the display doesn't support GLX like the case of VNC server the initialisation of OpenGL fails and a lot of confusing messages are outputted even if the application doesn't actually use OpenGL. So the patch doesn't really break anything except that has_opengl returns FALSE earlier and thus removes the messsages. That said I'm sure that it possible to implement limited OpenGL without GLX but that is another problem for another day.

Dec. 24, 2006

Re: [Winmm/winealsa] Don't use asynchronous callbacks in dsound any more

by Tomas Carnecky

Maarten Lankhorst wrote: > Instead of using asynchronous callbacks that uses signals, use a > seperate thread that can be cancelled, this prevents deadlock issues. > > Basically we use snd_pcm_wait() that tells us when enough room is free > to commit another buffer, then we commit the previous buffer and make > the next buffer ready. > > Since snd_pcm_wait() uses poll(), we don't have signals in winealsa any > more. > Correct me if I'm wrong, but doesn't your code create and destroy the thread in ::Play() and ::Stop()? It would be better to destroy it together with the DirectSoundBuffer object (whether you create the thread when the object is created or the first time ::Play() is called is not so important, but I've been told the CreateFrame() overhead is big so that we should try to minimize its use). but I would suggect to create teh thread when the DSB object is created, as the CreateThread() in ::Play() may have side-effects (delay in the sound etc). tom

Dec. 24, 2006

Re: [SPAM] [Winmm/winealsa] Don't use asynchronous callbacks in dsound any more

by a_villacis＠palosanto.com

> Instead of using asynchronous callbacks that uses signals, use a > seperate thread that can be cancelled, this prevents deadlock issues. > > Basically we use snd_pcm_wait() that tells us when enough room is free > to commit another buffer, then we commit the previous buffer and make > the next buffer ready. > > Since snd_pcm_wait() uses poll(), we don't have signals in winealsa any > more. > > This patch causes a hang in the interactive dsound tests: bash$ cd wine-0.9.28-cvs-patch/dlls/dsound/tests bash$ WINETEST_INTERACTIVE=1 wine dsound_test.exe.so dsound ... fixme:wave:DBSB_MMAPStart Can't access sound driver's buffer directly. ds3d.c:655: Test failed: The sound played for 835 ms instead of 1000 ms dsound.c:602: Testing a primary buffer at 48000x8x1 with a secondary buffer at 11025x16x2 ds3d.c:447: Playing 1 second 440Hz tone at 11025x16x2 fixme:wave:DBSB_MMAPStart Can't access sound driver's buffer directly. fixme:wave:DBSB_MMAPStart Can't access sound driver's buffer directly. fixme:wave:DBSB_MMAPStart Can't access sound driver's buffer directly. ds3d.c:655: Test failed: The sound played for 371 ms instead of 1000 ms dsound.c:602: Testing a primary buffer at 48000x8x2 with a secondary buffer at 11025x16x2 ds3d.c:447: Playing 1 second 440Hz tone at 11025x16x2 fixme:wave:DBSB_MMAPStart Can't access sound driver's buffer directly. fixme:wave:DBSB_MMAPStart Can't access sound driver's buffer directly. ds3d.c:655: Test failed: The sound played for 834 ms instead of 1000 ms dsound.c:602: Testing a primary buffer at 48000x16x1 with a secondary buffer at 11025x16x2 ds3d.c:447: Playing 1 second 440Hz tone at 11025x16x2 fixme:wave:DBSB_MMAPStart Can't access sound driver's buffer directly. fixme:wave:DBSB_MMAPStart Can't access sound driver's buffer directly. ds3d.c:655: Test failed: The sound played for 767 ms instead of 1000 ms dsound.c:602: Testing a primary buffer at 48000x16x2 with a secondary buffer at 11025x16x2 ds3d.c:447: Playing 1 second 440Hz tone at 11025x16x2 fixme:wave:DBSB_MMAPStart Can't access sound driver's buffer directly. dsound.c:602: Testing a primary buffer at 96000x8x1 with a secondary buffer at 11025x16x2 ds3d.c:447: Playing 1 second 440Hz tone at 11025x16x2 fixme:wave:DBSB_MMAPStart Can't access sound driver's buffer directly. (then silent hang) kernel 2.6.19 wine 0.9.28 Fedora Core 5, snd_via82xx module

Dec. 24, 2006

Re: kernel32 (profile.c): current section and key implementation

by Robert Shearman

Claudio Fontana wrote: > Hello all, > > I posted previously a patch to wine-patches here: > > http://www.winehq.org/pipermail/wine-patches/2006-December/034022.html > > However, I now understand that although it solves the issue I had with > the > specific program, the change is incomplete, since in several other > places, > sections and keys are only considered meaningful when not equal to the > empty string. > In the Microsoft implementation, the unnamed section is valid, as are > zero length keys. > > Thus, I think a broader scope change is required. > Before I start working on a new patch, do you acknowledge that the > current implementation > is incorrect, and a patch fixing it by not requiring name[0] to be != > '\0' is likely to be accepted? (btw, I've noticed you switched to git, > so I will be using that instead now). Hi Claudio, The patch looks good, apart from the specific version check for win95. Do you think you could add some tests to our test framework (dlls/kernel32/tests) to test for this issue that you've found. Then the tests could be run on a variety of platforms to see if it is only win95 that has that specific behaviour or if the original author of the comment was wrong about that. The tests that fail on Wine will then determine what needs to be fixed. Thanks, -- Rob Shearman

Dec. 24, 2006

Re: ntdll: Added stubs for the Rtl*GenericTable* functions

by Vitaliy Margolen

Patrik Stridvall wrote: > On Sunday 24 December 2006 05:37, Vitaliy Margolen wrote: >> Is there are any reason why do you need this functions at all? According >> to ddk they are part of "Installable File System Drivers". This is a >> kernel level thing only and no user app should use these routines. > > Should, perhaps. Does, well that is a different matter entirely. :-) > > Secondly we could perhaps find use for them ourselves. Splay and AVL trees are > nice. > >> Especially stabbing them won't do you any good if something actually >> using them. But that something has no place to run in Wine yet. > > ReactOS has some sort of implementation of them so I guess we can borrow Please don't mention ros' code here. It's barred from Wine. > In any case having them stubbed in better than nothing. I don't think Not really. As I said before, if a program uses these functions, then it's: a) Probably a kernel driver (which acre currently not supported) b) Won't run at all with stubbed implementation (in case we implement "kernel" >From what I've seen Wine prefers to crash instead of returning bogus data or unimplemented functionality. Vitaliy.

Dec. 24, 2006

Re: winex11.drv: Only try to initialize OpenGL if the display has the GLX extension.

by Roderick Colenbrander

I have played a bit with Mesa and it indeed works fine without the GLX extension (just a software renderer ofcourse). I know what error you are seeing for instance the nvidia drivers output it when GLX isn't present. It really depends just on the opengl implementation. Perhaps the right thing to do is to 'test' the OpenGL implementation by making a GLX call like glXQueryVersion or whatever. Errors can be caught using a X11DRV_expect_error. I fear that something like this is the only way. Roderick > On Sunday 24 December 2006 10:12, Roderick Colenbrander wrote: > > Hi, > > > > I'm not sure if checking for the GLX extension is such a good idea as it > is > > possible to use OpenGL without having the GLX extension. For instance > when > > plain Mesa is used. > > OK. The thing is that if I have the OpenGL libraries installed and I try > to > run Wine under VNC server I get I complaints that it doesn't have the GLX > extension. So I found some code that checks for the existence of the > extension. > > In any case the initialisation of OpenGL fails under VNC server so > something > needs to be fixed. But perhaps disabling it if GLX doesn't exist is too > brutal. > > What do you suggest? > -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Dec. 24, 2006

Re: winex11.drv: Only try to initialize OpenGL if the display has the GLX extension.

by Chris Robinson

On Sunday 24 December 2006 01:12, Roderick Colenbrander wrote: > Hi, > > I'm not sure if checking for the GLX extension is such a good idea as it is > possible to use OpenGL without having the GLX extension. For instance when > plain Mesa is used. Wine requires GLX 1.2 or higher though, doesn't it? In that case, the GLX extension would have to be there.

Dec. 24, 2006

Re: Building a full win32 winetest.exe

by Paul Vriens

On Sun, 2006-12-24 at 00:59 +0000, Paul Millar wrote: > Hi Paul, > > On Friday 22 December 2006 15:38, Paul Vriens wrote: > > any pointers how to build a winetest.exe I can run on Windows? > > Try make inside programs/winetest/ directory. > > However, winetest.exe has dependencies on all the DLL tests: to build the > single winetest.exe executable, all the <dll>_test.exe executables must build > correctly. > > You say you're having difficulty with crypt32 and hlink DLL tests. To build > winetest.exe, you must either fix building of these tests (the preferred > option) or remove the winetest.exe dependency on these executables (not so > good). > > Try posting the problems with the crypt32 and hlink tests: it could be you > need to patch you MinGW compiler to support extra functions. > > HTH, > > Paul. > > PS. I'll have sporadic access to email for the next couple of weeks, but if > you post the problems I'll try and catch up. > Doing a simple 'make clean' and 'make' only gives me a winetest.exe.so which is a 'ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped'. Is there something I'm missing here? Cheers, Paul.

Dec. 24, 2006

Re: winex11.drv: Only try to initialize OpenGL if the display has the GLX extension.

by Patrik Stridvall

On Sunday 24 December 2006 10:12, Roderick Colenbrander wrote: > Hi, > > I'm not sure if checking for the GLX extension is such a good idea as it is > possible to use OpenGL without having the GLX extension. For instance when > plain Mesa is used. OK. The thing is that if I have the OpenGL libraries installed and I try to run Wine under VNC server I get I complaints that it doesn't have the GLX extension. So I found some code that checks for the existence of the extension. In any case the initialisation of OpenGL fails under VNC server so something needs to be fixed. But perhaps disabling it if GLX doesn't exist is too brutal. What do you suggest?

Dec. 24, 2006

Re: ntdll: Added stubs for the Rtl*GenericTable* functions

by Patrik Stridvall

On Sunday 24 December 2006 05:37, Vitaliy Margolen wrote: > Is there are any reason why do you need this functions at all? According > to ddk they are part of "Installable File System Drivers". This is a > kernel level thing only and no user app should use these routines. Should, perhaps. Does, well that is a different matter entirely. :-) Secondly we could perhaps find use for them ourselves. Splay and AVL trees are nice. > Especially stabbing them won't do you any good if something actually > using them. But that something has no place to run in Wine yet. ReactOS has some sort of implementation of them so I guess we can borrow that I think the code in under the correct license. It seems to depend on some sort of external library though. Not 100% sure. In any case having them stubbed in better than nothing. I don't think implementing them is that difficult either. There are very likely to be code there beside the ReactOS code that we can borrow or link to. Splay and AVL trees are not really rocket science.

Dec. 24, 2006

Re: winex11.drv: Only try to initialize OpenGL if the display has the GLX extension.

by Roderick Colenbrander

Hi, I'm not sure if checking for the GLX extension is such a good idea as it is possible to use OpenGL without having the GLX extension. For instance when plain Mesa is used. Regards, Roderick -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Dec. 24, 2006

Re: user32: fix return value in DialogBoxParamA if no resource can befound + simple test

by Dmitry Timoshkov

Louis. Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > --- a/dlls/user32/dialog.c > +++ b/dlls/user32/dialog.c > @@ -800,7 +800,12 @@ INT_PTR WINAPI DialogBoxParamA( HINSTANC > HRSRC hrsrc; > LPCDLGTEMPLATEA ptr; > > - if (!(hrsrc = FindResourceA( hInst, name, (LPSTR)RT_DIALOG ))) return 0; > + if (!(hrsrc = FindResourceA( hInst, name, (LPSTR)RT_DIALOG ))) > + { > + SetLastError(ERROR_RESOURCE_NAME_NOT_FOUND); > + ERR("FindResource %s failed, returning -1\n",debugstr_a(name)); > + return -1; > + } Most likely the last error should be set by FindResource itself, not a more high level DialogBoxParam call. If that's not the case it should be fixed there. -- Dmitry.

Dec. 24, 2006