September 2005 - Wine-Devel

Re: OleFont: Fix IDispatch Implementation (was Re: olefont: GetIDsOfNames)

by Walt Ogburn

On Wed, 14 Sep 2005, Robert Shearman wrote: > > You're not being lazy enough. All of this stuff can be easily > implemented in one go using CreateStdDispatch, as long as you know how > to use it. Try the attached patch. > > Changelog: > Return the standard font IDispatch interface created using > CreateStdDispatch on top of a typelib instead of manually implementing > the necessary methods. > That doesn't look very lazy to me, but it simplifies olefont very nicely (300 fewer lines!). Please use this patch for GetIDsOfNames instead of mine. My patch for DispGetIDsOfNames and the test for IFontDisp_GetIDsOfNames are still OK. With Robert Shearman's big patch to olefont.c and my small one to typelib.c, the tests in my patch to tests/olefont.c all pass. Thanks, Walter

Sept. 14, 2005

Internet Explorer Registry entries

by Stefan Dösinger

Hello, I just tried to install Palm Desktop on a clean Wine installation to test the msi file on Wine's MSI implementation. Well, it cancelled the installation because it needs MSIE 4.0 or higher. My suggestion is to include the most important Internet Explorer identification registry entries in the default wine registry to make apps like this install without the hassle of installing Internet explorer. If the version is set to 4.0, 5.0 or 5.5 IE6.0 SP1 should still install without problems. To my knowledge most apps check for the existance of MSIE to be sure some DLLs are available on Win95 systems, which wine brings in builtin versions. All apps(except of Steam) that I've seen and require MSIE work fine with Wines shdocvw, mshtml and friends. What do you think about this? Stefan

Sept. 14, 2005

Re: [Regression] WSACleanup() again?

by JustFillBug

On 2005-09-14, Robert Shearman <rob(a)codeweavers.com> wrote: > > Does this patch fix it? > > RCS file: /home/wine/wine/dlls/winsock/socket.c,v > retrieving revision 1.189 > diff -u -p -r1.189 socket.c > --- dlls/winsock/socket.c 27 Aug 2005 09:20:24 -0000 1.189 > +++ dlls/winsock/socket.c 14 Sep 2005 15:53:41 -0000 > @@ -700,7 +700,10 @@ int WINAPI WSAStartup(WORD wVersionReque > INT WINAPI WSACleanup(void) > { > if (num_startup) > + { > + num_startup--; > return 0; > + } > SetLastError(WSANOTINITIALISED); > return SOCKET_ERROR; > } Yes but do you need to clean up whatever resources when num_startup == 0? I don't really know wine code but it seems the old way cleaned up some resources when num_startup went to zero: WINSOCK_DeleteIData();. Maybe free_per_thread_data() or DllMain()? Just an observation. Thanks.

Sept. 14, 2005

Re: [Regression] WSACleanup() again?

by Robert Shearman

JustFillBug wrote: >On 2005-09-10, JustFillBug <mozbugbox(a)yahoo.com.au> wrote: > > >>I saw the bug described in: >>http://winehq.com/hypermail/wine-users/2001/01/0516.html >>happened again to a program I was trying to use. At least the behavior >>is the same. I have no access to the source code. It seems the problem >>was fixed in revision 1.42 of socket.c. But now at 1.139, WSACleanup >>again return 0 forever on repeating calls. >> >> >> > >Someone please fix this up. From cvs, it was broken by revision 1.168 >(Robert Shearman at codeweavers.com) when the per-process buffer in >socket was converted to per-thread one. > > Does this patch fix it? -- Rob Shearman

Sept. 14, 2005

OleFont: Fix IDispatch Implementation (was Re: olefont: GetIDsOfNames)

by Robert Shearman

Walt Ogburn wrote: >Changelog: > Implement IFontDisp::GetIDsOfNames > > > You're not being lazy enough. All of this stuff can be easily implemented in one go using CreateStdDispatch, as long as you know how to use it. Try the attached patch. Changelog: Return the standard font IDispatch interface created using CreateStdDispatch on top of a typelib instead of manually implementing the necessary methods. -- Rob Shearman

Sept. 14, 2005

Re: listview crash fix

by Dimi Paun

From: "Michael Jung" <mjung(a)iss.tu-darmstadt.de> > Thanks, seems to work fine for me (no crash while browsing about 50 > directories). Good, thanks. > I've attached another patch, which fixes the crash in the file dialog applying > this scheme. I've only changed as much as necessary to fix the problem, > though. Yeah, this is one solution, but it pretty much means that after every function call we need to check the hwnd for validity. That's not really nice, to say the least. Give me a bit to get a chance to work on it. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

Sept. 14, 2005

Re: listview crash fix

by Michael Jung

Hi Dimi, On Wednesday 14 September 2005 14:24, Dimi Paun wrote: > Can you try this out and let me know if it works please? Thanks, seems to work fine for me (no crash while browsing about 50 directories). > To be honest, I don't like this solution at all, I'll try > a different approach tonight, but in the meanwhile... I had a short discussion with Alexandre on IRC yesterday. He says that the basic problem is probably the passing around of the infoPtr to represent the listview instead of the handle. As far as I understood, we should probably change all functions to take a HWND instead of a LISTVIEW_INFO* parameter. We should then try to retrieve infoPtr via GetWindowLongPtrW as soon as we need it. And we should be aware that infoPtr might point to a free'd location after every SendMessage. I've attached another patch, which fixes the crash in the file dialog applying this scheme. I've only changed as much as necessary to fix the problem, though. Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

Sept. 14, 2005

listview crash fix

by Dimi Paun

Hi Michael, Can you try this out and let me know if it works please? To be honest, I don't like this solution at all, I'll try a different approach tonight, but in the meanwhile... -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

Sept. 14, 2005

Re: olefont: GetIDsOfNames

by Alexandre Julliard

Walt Ogburn <reuben(a)ugcs.caltech.edu> writes: > OLEFontImpl *this = impl_from_IDispatch(iface); > - FIXME("(%p,%s,%p,%d,%04x,%p), stub!\n", this, debugstr_guid(riid), rgszNames, > - cNames, (int)lcid, rgDispId > - ); > - return E_NOTIMPL; > + TRACE("(%p,%s,%p,%d,%04x,%p)\n", this, debugstr_guid(riid), rgszNames, > + cNames, (int)lcid, rgDispId); > + if (S_OK != OLEFontImpl_GetTypeInfo (iface, 0, lcid, &pTInfo)) > + ERR("GetTypeInfo failed.\n"); You need to handle the failure properly, instead of just displaying an ERR and then going on with a bad pointer. -- Alexandre Julliard julliard(a)winehq.org

Sept. 14, 2005

Re: Problem detecting libxslt

by Alexandre Julliard

Vincent Béron <vberon(a)mecano.gme.usherb.ca> writes: > Is this acceptable? > > libxslt/xslt.h was never included, so I got rid of it. > > The variable declarations weren't protected with the HAVE_LIBXSLT_*_H > macros, so I simplified the test and removed the macros. I think keeping the standard header check is better. What didn't work with your previous solution? -- Alexandre Julliard julliard(a)winehq.org

Sept. 14, 2005

wineconsole --backend-user

by Robert Lunnon

After an underwhelming response to my last query, I dug a little deeper and while I'm not too familiar with windows code I can't seem to figure out what is wrong with user.c that gives me my funny display. It would seem that either bitblt isn't working as advertised or the memory DC isn't being written properly (or it's not compatible with the display context). Does --backend=user work under Linux ? Anyway, before I spend a great deal of time on this, I am prompted to ask how important is this backend, seeing I have curses working properly. I could easily make the user backend default to the curses implementation for compatibility short term. Is there a downside to this? Is this something that's likely to be deprecated soon ? Bob

Sept. 14, 2005

Re: wineserver: fix a gcc 4.0 warning

by Mike McCormack

Marcus Meissner wrote: >> if (mailslot->read_timeout != MAILSLOT_WAIT_FOREVER) >>- timeout = &mailslot->read_timeout; >>+ timeout = (int*) &mailslot->read_timeout; > > > It would be better to change read_timeout to "int" instead I guess. I'm not really sure, that why I've been avoiding changing this... CreateMailslot takes timeout as a DWORD, and timeouts should not be negative. Maybe fd_queue_async_timeout should take an unsigned int *? Mike

Sept. 14, 2005

Re: wineserver: fix a gcc 4.0 warning

by Marcus Meissner

On Wed, Sep 14, 2005 at 01:47:00PM +0900, Mike McCormack wrote: > ChangeLog: > fix a gcc 4.0 warning > Index: server/mailslot.c > =================================================================== > RCS file: /home/mike/src/wine-cvs/wine/server/mailslot.c,v > retrieving revision 1.9 > diff -u -p -r1.9 mailslot.c > --- server/mailslot.c 14 Jul 2005 12:18:05 -0000 1.9 > +++ server/mailslot.c 14 Sep 2005 00:18:08 -0000 > @@ -207,7 +207,7 @@ static void mailslot_queue_async( struct > } > > if (mailslot->read_timeout != MAILSLOT_WAIT_FOREVER) > - timeout = &mailslot->read_timeout; > + timeout = (int*) &mailslot->read_timeout; It would be better to change read_timeout to "int" instead I guess. Ciao, Marcus

Sept. 14, 2005

Re: OpenOffice 2.0 beta 2 installs ok but locks up in File Open dialog with wine-20050830 + 2 patches

by Dan Kegel

Robert Shearman wrote: >>> installs properly, and the app even appears to come up normally! >>> However, when you use the File Open dialog box, >>> it seems to lock up. Here's a session log: >> >> It seems to be an ole32 problem. Installing dcom95 makes it work fine >> for me. Maybe Rob or somebody more knowledgable about ole can help >> out... > > If you give me a +ole,+olerelay,+tid trace then I can take a look. With those options, I had to play around in the file open dialog for a while before it locked up (navigated through a directory or two), but it did lock up after twenty seconds or so. The log you requested is at http://kegel.com/ooolockup.txt The last few lines are: 001c:trace:ole:DllMain 0x7c090000 0x2 (nil) 001d:trace:ole:DllMain 0x7c090000 0x2 (nil) 001d:fixme:commdlg:GetFileName95 Flags 0x02800000 not yet implemented 001d:trace:ole:WINE_StringFromCLSID 0x7af75fa0->{9D20AAE8-0625-44B0-9CA7-71889C2254D9} 001d:trace:ole:__CLSIDFromStringA {450D8FBA-AD25-11D0-98A8-0800361B1103} -> 0x6f52d5f8 001d:trace:ole:__CLSIDFromStringA {9D20AAE8-0625-44B0-9CA7-71889C2254D9} -> 0x6f52d5f8 001d:trace:ole:WINE_StringFromCLSID 0x7cd46c94->{20D04FE0-3AEA-1069-A2D8-08002B30309D} 001d:trace:ole:WINE_StringFromCLSID 0x7cd46d2c->{450D8FBA-AD25-11D0-98A8-0800361B1103} 001d:trace:ole:WINE_StringFromCLSID 0x7cd46dc4->{9D20AAE8-0625-44B0-9CA7-71889C2254D9} 001d:trace:ole:RevokeDragDrop (0x10066) 001f:trace:ole:DllMain 0x7c090000 0x1 0x1 001d:err:ntdll:RtlpWaitForCriticalSection section 0x7ad046e0 "?" wait timed out in thread 001d, blocked by 001c, retrying (60 sec) That very last line didn't show up for a while. You can reproduce this yourself if you like; the download is at http://openoffice.mirrors.pair.com/ftp/stable/2.0beta2/OOo_2.0beta2_Win32In… - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

Sept. 14, 2005

Re: [Regression] WSACleanup() again?

by JustFillBug

On 2005-09-10, JustFillBug <mozbugbox(a)yahoo.com.au> wrote: > > I saw the bug described in: > http://winehq.com/hypermail/wine-users/2001/01/0516.html > happened again to a program I was trying to use. At least the behavior > is the same. I have no access to the source code. It seems the problem > was fixed in revision 1.42 of socket.c. But now at 1.139, WSACleanup > again return 0 forever on repeating calls. > Someone please fix this up. From cvs, it was broken by revision 1.168 (Robert Shearman at codeweavers.com) when the per-process buffer in socket was converted to per-thread one.

Sept. 14, 2005

Re: Stack overflow problem

by Mike McCormack

Vitaliy Margolen wrote: > Once more I need your help. It seems that wine is not correct with the way it > sets guard pages for stack. Here is an example that works fine on windows, and > fails on wine. And yes, I do have a program that does something like this: > > PDWORD p = TEB.Tib.StackLimit; > *p = 0; > > I'm not sure what to do here. It looks like there are several places that we > allocate stack, and both of them set first page (last for stack) as a > PAGE_GUARD. Could that be that this wasn't what we wanted? Since both places > using size of 1. But this looks like sets whole page to be guard page. Looks like you're investigating a software crippling scheme :) Wine handles the StackLimit in the wrong way. On Windows, the ntteb->StackLimit is set to a low value when the program starts, and as more stack is committed, the kernel increase StackLimit. On Wine, we never change StackLimit, and it is fixed at the larger of 2Mb or the size the application requests. The above code results in StackLimit changing. It's possible your crippling software is checking that it changes in a "windows like" way. Mike

Sept. 13, 2005

Stack overflow problem

by Vitaliy Margolen

Once more I need your help. It seems that wine is not correct with the way it sets guard pages for stack. Here is an example that works fine on windows, and fails on wine. And yes, I do have a program that does something like this: PDWORD p = TEB.Tib.StackLimit; *p = 0; I'm not sure what to do here. It looks like there are several places that we allocate stack, and both of them set first page (last for stack) as a PAGE_GUARD. Could that be that this wasn't what we wanted? Since both places using size of 1. But this looks like sets whole page to be guard page. -- Best regards, Vitaliy

Sept. 13, 2005

Re: Fix Animate Control

by Dmitry Timoshkov

"Robert Shearman" <rob(a)codeweavers.com> wrote: > Initialize unused members of the MMCKINFO structs to 0 to fix chunk detection with mmioDescend. > --- dlls/comctl32/animate.c 30 Aug 2005 10:07:18 -0000 1.68 > +++ dlls/comctl32/animate.c 13 Sep 2005 20:36:03 -0000 > @@ -476,6 +476,7 @@ static BOOL ANIMATE_GetAviInfo(ANIMATE_I > DWORD numFrame; > DWORD insize; > > + memset(&ckMainRIFF, 0, sizeof(ckMainRIFF)); > if (mmioDescend(infoPtr->hMMio, &ckMainRIFF, NULL, 0) != 0) { I don't think that this is a correct fix, mmioDescend works under Windows without a need to initialize ckMainRIFF. -- Dmitry.

Sept. 13, 2005

Re: wineconsole and solaris

by Eric Pouech

Robert Lunnon wrote: > I have managed to sort out a solution to the curses problem with wineconsole, > but I noticed that -backend=user doesn't work properly either. I get a window > with alternating stripes of black and the root window image and text output > doesn't emerge (perhaps a font problem ?). I uploaded an image of the problem > to: http://members.optusnet.com.au/bobl/wineconsole.png > > Guesses anyone ? > > I set +wineconsole and got > > trace:wineconsole:WINECON_RegLoad loading L"wcmd" registry settings. > trace:wineconsole:WINECON_DumpConfig load cell=(16,28) cursor=(25,1) attr=0f > font=L"Wine Courier"/0 hist=50/2 flags=qX msk=00000000 sb=(80,25) > win=(0,0)x(80,25) edit=0 registry=L"wcmd" > trace:wineconsole:WINECON_Init using hConIn 28, hSynchro event 2c > trace:wineconsole:WINECON_Init using hConOut 30 > warn:wineconsole:WCUSER_SetFontPmt Couldn't match the font from registry... > trying to find one > trace:wineconsole:WINECON_RegLoad loading default registry settings. > trace:wineconsole:WINECON_DumpConfig load cell=(16,28) cursor=(25,1) attr=0f > font=L"Wine Courier"/0 hist=50/2 flags=qX msk=00000000 sb=(80,25) > win=(0,0)x(80,25) edit=0 registry=(null) > trace:wineconsole:WINECON_RegSave saving registry settings. > trace:wineconsole:WINECON_DumpConfig save cell=(16,28) cursor=(25,1) attr=0f > font=L"Wine Courier"/0 hist=50/2 flags=qX msk=00000000 sb=(80,25) > win=(0,0)x(80,25) edit=0 registry=(null) > trace:wineconsole:WINECON_GrabChanges Events: title() active(68) > resize(80,150) win-size(80,25)crsr cell=(16,28) cursor=(0,0) attr=0f > font=L"Wine Courier"/400 hist=50/2 flags=qX msk=00000000 sb=(80,150) > win=(0,0)x(80,25) edit=0 registry=(null) > trace:wineconsole:WINECON_GrabChanges update(0,149) curs-geom(100,1)crsr > cell=(16,28) cursor=(100,1) attr=0f font=L"Wine Courier"/400 hist=50/2 > flags=qX msk=00000000 sb=(80,150) win=(0,0)x(80,25) edit=0 registry=(null) > trace:wineconsole:WINECON_GrabChanges curs-geom(25,0)crsr cell=(16,28) > cursor=(25,0) attr=0f font=L"Wine Courier"/400 hist=50/2 flags=qX > msk=00000000 sb=(80,150) win=(0,0)x(80,25) edit=0 registry=(null) > trace:wineconsole:WINECON_GrabChanges curs-geom(25,1)crsr cell=(16,28) > cursor=(25,1) attr=0f font=L"Wine Courier"/400 hist=50/2 flags=qX > msk=00000000 sb=(80,150) win=(0,0)x(80,25) edit=0 registry=(null) > trace:wineconsole:WINECON_GrabChanges resize(80,25)crsr cell=(16,28) > cursor=(25,1) attr=0f font=L"Wine Courier"/400 hist=50/2 flags=qX > msk=00000000 sb=(80,25) win=(0,0)x(80,25) edit=0 registry=(null) > trace:wineconsole:WINECON_GrabChanges update(0,24). > trace:wineconsole:WINECON_DumpConfig fint cell=(16,28) cursor=(25,1) attr=0f > font=L"Wine Courier"/400 hist=50/2 flags=qX msk=00000000 sb=(80,25) > win=(0,0)x(80,25) edit=0 registry=L"wcmd" > trace:wineconsole:WinMain calling MainLoop. > trace:wineconsole:WCUSER_MainLoop dispatching msg 000f > trace:wineconsole:WCUSER_MainLoop dispatching msg 0118 > trace:wineconsole:WCUSER_MainLoop dispatching msg 0118 > trace:wineconsole:WINECON_GrabChanges Events: title(). > trace:wineconsole:WINECON_GrabChanges Events: update(0,0). > trace:wineconsole:WINECON_GrabChanges Events: curs-pos(0,2). > trace:wineconsole:WINECON_GrabChanges Events: update(2,2). > trace:wineconsole:WINECON_GrabChanges Events: curs-pos(4,2). > trace:wineconsole:WCUSER_MainLoop dispatching msg 0118 > > > > did you try to pick up another font for the console and then get back to "Wine Courier" ? Likely, there's a discrepency between font cell size (in registry) and what the font actually does. A+ -- Eric Pouech

Sept. 13, 2005

Re: OpenOffice 2.0 beta 2 installs ok but locks up in File Open dialog with wine-20050830 + 2 patches

by Robert Shearman

Mike McCormack wrote: > > Dan Kegel wrote: > >> installs properly, and the app even appears to come up normally! >> However, when you use the File Open dialog box, >> it seems to lock up. Here's a session log: > > > It seems to be an ole32 problem. Installing dcom95 makes it work fine > for me. Maybe Rob or somebody more knowledgable about ole can help > out... If you give me a +ole,+olerelay,+tid trace then I can take a look. -- Rob Shearman

Sept. 13, 2005

Re: DSOUND: tolerate inexact conversion between different frequencies

by Alex Villacís Lasso

Robert Reif wrote: > Alex Villacís Lasso wrote: > >> During the winealsa tests, I am frequently annoyed by the following: >> say, in playing a 11050Hz secondary buffer with an 8000Hz primary >> buffer, the number of samples are converted form secondary->primary >> and back. In the process, the number of consumed samples in the >> secondary buffer drifts by a few frames from the actual value, and >> this triggers the warning about "problem with underflow detection". >> This patch allows a tolerance of up to 4 bytes before issuing the >> message. >> >> Alex Villacís Lasso >> > Does this patch help? It should only fix the errors that are off by > one sample (up to 4 bytes). It will not help with the errors greater > than 4 bytes. > > It works by keeping track of the round off error and factoring it back > in. > >------------------------------------------------------------------------ > >Index: dlls/dsound/buffer.c >=================================================================== >RCS file: /home/wine/wine/dlls/dsound/buffer.c,v >retrieving revision 1.51 >diff -p -u -r1.51 buffer.c >--- dlls/dsound/buffer.c 1 Jun 2005 19:57:42 -0000 1.51 >+++ dlls/dsound/buffer.c 10 Sep 2005 02:20:21 -0000 >@@ -416,7 +416,9 @@ DWORD DSOUND_CalcPlayPosition(IDirectSou > pmix /= This->dsound->device->pwfx->nBlockAlign; > TRACE("primary back-samples=%ld\n",pmix); > /* adjust for our frequency */ >- pmix = (pmix * This->freqAdjust) >> DSOUND_FREQSHIFT; >+ pmix = pmix * This->freqAdjust; >+ This->freqRem = pmix & ((1 << DSOUND_FREQSHIFT) - 1); >+ pmix = pmix >> DSOUND_FREQSHIFT; > /* multiply by our own sample size */ > pmix *= This->pwfx->nBlockAlign; > TRACE("this back-offset=%ld\n", pmix); >@@ -426,6 +428,7 @@ DWORD DSOUND_CalcPlayPosition(IDirectSou > if (This->leadin && ((bplay < This->startpos) || (bplay > This->buf_mixpos))) { > /* seems we haven't started playing yet */ > TRACE("this still in lead-in phase\n"); >+ This->freqRem = 0; > bplay = This->startpos; > } > /* return the result */ >@@ -1123,6 +1126,8 @@ HRESULT WINAPI IDirectSoundBufferImpl_Cr > dsb->buf_mixpos = 0; > dsb->state = STATE_STOPPED; > >+ dsb->freqAcc = 0; >+ dsb->freqRem = 0; > dsb->freqAdjust = (dsb->freq << DSOUND_FREQSHIFT) / > ds->device->pwfx->nSamplesPerSec; > dsb->nAvgBytesPerSec = dsb->freq * >Index: dlls/dsound/dsound_private.h >=================================================================== >RCS file: /home/wine/wine/dlls/dsound/dsound_private.h,v >retrieving revision 1.31 >diff -p -u -r1.31 dsound_private.h >--- dlls/dsound/dsound_private.h 12 Jul 2005 19:21:37 -0000 1.31 >+++ dlls/dsound/dsound_private.h 10 Sep 2005 02:20:22 -0000 >@@ -212,7 +212,7 @@ struct IDirectSoundBufferImpl > DSVOLUMEPAN volpan, cvolpan; > DSBUFFERDESC dsbd; > /* used for frequency conversion (PerfectPitch) */ >- ULONG freqAdjust, freqAcc; >+ ULONG freqAdjust, freqAcc, freqRem; > /* used for intelligent (well, sort of) prebuffering */ > DWORD probably_valid_to, last_playpos; > DWORD primary_mixpos, buf_mixpos; >Index: dlls/dsound/mixer.c >=================================================================== >RCS file: /home/wine/wine/dlls/dsound/mixer.c,v >retrieving revision 1.40 >diff -p -u -r1.40 mixer.c >--- dlls/dsound/mixer.c 3 Aug 2005 19:13:58 -0000 1.40 >+++ dlls/dsound/mixer.c 10 Sep 2005 02:20:22 -0000 >@@ -746,10 +746,19 @@ static DWORD DSOUND_MixOne(IDirectSoundB > * there's no telling what the app is thinking anyway */ > } else { > /* adjust for our frequency and our sample size */ >- probably_valid_left = MulDiv(probably_valid_left, >- 1 << DSOUND_FREQSHIFT, >- dsb->pwfx->nBlockAlign * dsb->freqAdjust) * >- dsb->dsound->device->pwfx->nBlockAlign; >+ ULONGLONG left = probably_valid_left / dsb->pwfx->nBlockAlign; >+ left <<= DSOUND_FREQSHIFT; >+ if (dsb->freqRem >= dsb->freqAcc) >+ left += (dsb->freqRem - dsb->freqAcc); >+ else { >+ DWORD sub = dsb->freqAcc - dsb->freqRem; >+ if (sub > left) >+ left = 0; >+ else >+ left -= sub; >+ } >+ probably_valid_left = left / dsb->freqAdjust; >+ probably_valid_left *= dsb->dsound->device->pwfx->nBlockAlign; > /* check whether to clip mix_len */ > if (probably_valid_left < mixlen) { > TRACE("clipping to probably_valid_left=%ld\n", probably_valid_left); > > I tried this patch. Yes, it does remove the messages about buffer underruns, but it also introduces a delay in the playing of many tests, so they fail with the message "sample played for 1504 ms instead of 1000 ms", with varying values for the actual value of the delay. However, all of these problems went away when I modified my modprobe.conf file: alias eth0 via-rhine alias snd-card-0 snd-via82xx alias snd-card-1 snd-via82xx-modem options snd-card-0 index=0 options snd-via82xx index=0 dxs_support=5 remove snd-via82xx { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; }; /sbin/modprobe -r --ignore-remove snd-via82xx alias usb-controller ehci-hcd alias usb-controller1 uhci-hcd options parport_pc io=0x378,0xe800 irq=7,none options lp parport=1 alias char-major-4 8250-pci alias char-major-29 savagefb I added the dxs_support=5 option to the snd-via82xx module, and now the tests play correctly. The odd thing is that, when the dxs_support option, I can no longer trigger the buffer underrun message, even without the patch. But since the patch did not make anything worse in any of the actual games I have (with or without dxs_support), I kept it applied.

Sept. 13, 2005

Re: Perform automatic bitmap font configuration. Take 4

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -313,10 +312,7 @@ void LOCALE_InitRegistry(void) > } > else TRACE( "updating registry, locale changed none -> %08lx\n", lcid ); > > - sprintf( buffer, "%08lx", lcid ); > - /* Note: '9' constant below is strlen(buffer) + 1 */ > - RtlMultiByteToUnicodeN( bufferW, sizeof(bufferW), NULL, buffer, 9 ); > - NtSetValueKey( hkey, &nameW, 0, REG_SZ, bufferW, 9 * sizeof(WCHAR) ); > + /* GDI32 detects locale change as well, it will update the registry */ You can't depend on GDI updating the kernel's key, they need to be independent. -- Alexandre Julliard julliard(a)winehq.org

Sept. 13, 2005

Re: Perform automatic bitmap font configuration. Take 4

by Dmitry Timoshkov

"Huw D M Davies" <h.davies1(a)physics.ox.ac.uk> wrote: > One other thing about your patch - I don't think we want the magic > registry comment above the external fonts registry key, as this isn't > user configurable data, it's just internal housekeeping. I've just added the comment to make it look similar to the earlier occurence of 'if(RegCreateKeyExW(HKEY_CURRENT_USER, external_fonts_reg_key' in that file. -- Dmitry.

Sept. 13, 2005

Re: Perform automatic bitmap font configuration. Take 4

by Huw D M Davies

On Tue, Sep 13, 2005 at 06:21:22PM +0900, Dmitry Timoshkov wrote: > "Huw D M Davies" <h.davies1(a)physics.ox.ac.uk> wrote: > > > I think you also need to take into account the OEM codepage here. For > > example in the UK the OEM font would be vga850.fon while in the US it > > would be vgaoem.fon. > > Once Alexandre accepts the patch I'll send the fix, it should be a small > one. Fair enough. I'd suggest separating the ansi fonts from the oem fonts and installing them according to the appropiate codepage. One other thing about your patch - I don't think we want the magic registry comment above the external fonts registry key, as this isn't user configurable data, it's just internal housekeeping. Huw.

Sept. 13, 2005

Re: Perform automatic bitmap font configuration. Take 4

by Dmitry Timoshkov

"Huw D M Davies" <h.davies1(a)physics.ox.ac.uk> wrote: > I think you also need to take into account the OEM codepage here. For > example in the UK the OEM font would be vga850.fon while in the US it > would be vgaoem.fon. Once Alexandre accepts the patch I'll send the fix, it should be a small one. -- Dmitry.

Sept. 13, 2005