wine-devel September 2005

wine-devel@winehq.org

136 participants
273 discussions

Re: wineserver: fix a gcc 4.0 warning
by Marcus Meissner 14 Sep '05

14 Sep '05

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

2 1

OpenOffice 2.0 beta 2 installs ok but locks up in File Open dialog with wine-20050830 + 2 patches
by Dan Kegel 14 Sep '05

14 Sep '05

With wine-20050830 and Mike's two MSI patches (thanks, Mike!), http://openoffice.mirrors.pair.com/ftp/stable/2.0beta2/OOo_2.0beta2_Win32In… 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: [dank@localhost program]$ wine soffice.exe fixme:advapi:LookupAccountSidW ((null),sid=0x7ad47428,0x7b949ac4,0x7b949bcc(256),0x7b9497c0,0x7b949bc8(256),0x7b949bc4): semi-stub fixme:font:GetKerningPairsW (0x6dc4,0,(nil)): almost empty stub! fixme:font:GetKerningPairsW (0x6dc4,0,(nil)): almost empty stub! fixme:font:GetKerningPairsW (0x6dc4,0,(nil)): almost empty stub! fixme:font:GetKerningPairsW (0x733c,0,(nil)): almost empty stub! fixme:imm:ImmGetContext (0x10030): stub fixme:imm:ImmReleaseContext (0x10030, 0x7bca5658): stub err:ole:CoInitializeEx Attempt to change threading model of this apartment from 0x2 to 0x0 err:ole:CoInitializeEx Attempt to change threading model of this apartment from 0x2 to 0x0 err:ole:CoInitializeEx Attempt to change threading model of this apartment from 0x0 to 0x2 fixme:commdlg:GetFileName95 Flags 0x02800000 not yet implemented That CoInitializeEx error sounds bad. The error is probably very easy to reproduce, perhaps a wine developer should try it out him/herself. Now to go rescue my wife so she can get some sleep. Having a two-year-old son seriously cuts down the amount of time I have for hacking. I'm doing a talk on Open Source this Thursday night. Mike's amazing turnaround time on the two MSI patches will be a nice story to tell during the talk. Is there any hope of continuing the run of good luck, and actually getting Wine to run OOo2.0 by Thursday? I dare not hope... - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

3 3

Stack overflow problem
by Vitaliy Margolen 14 Sep '05

14 Sep '05

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

2 1

Re: Fix Animate Control
by Dmitry Timoshkov 14 Sep '05

14 Sep '05

"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.

1 0

Re: DSOUND: tolerate inexact conversion between different frequencies
by Alex Villacís Lasso 13 Sep '05

13 Sep '05

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.

1 0

Re: Perform automatic bitmap font configuration. Take 4
by Alexandre Julliard 13 Sep '05

13 Sep '05

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

1 0

Re: Perform automatic bitmap font configuration. Take 4
by Huw D M Davies 13 Sep '05

13 Sep '05

On Tue, Sep 13, 2005 at 04:45:30PM +0900, Dmitry Timoshkov wrote: > > +static const struct nls_update_font_list > +{ > + UINT ansi_cp; > + const char *oem, *fixed, *system; > + const char *courier, *serif, *small, *sserif; > +} nls_update_font_list[] = Hi Dmitry, 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. Huw.

2 3

Looking for bugs in Wine's Microsoft Installer (MSI) implementation
by Mike McCormack 13 Sep '05

13 Sep '05

Hi All, If anybody is aware of any cases of Wine's Microsoft Installer code not working, please log them in Wine's bugzilla (http://bugs.winehq.org/), assign them to me, and I will attempt to fix them. Make sure to set "msi" = "builtin", "*msiexec" = "builtin" when testing your installers, and if possible test with the latest Wine CVS. If the installer is available as a free download, please include a link to it. thanks, Mike

2 1

GetIDsOfNames
by Walt Ogburn 13 Sep '05

13 Sep '05

Hi guys, Eric Tanguy asked on wine-users a while back about getting some geography games (http://olivier.leflon.free.fr/jeux/jeux.htm) to run. These seem to be Visual Basic, so oleaut32 issues come up. We succeeded with the first one (departments of France - font size problem fixed). Next, there is the issue that some of them call GetIDsOfNames on ole font objects (countries of Europe, http://olivier.leflon.free.fr/jeux/europe.htm). OLEFontImpl_GetIDsOfNames is currently a stub. What's needed is basically just to convert the strings "Name", "Size", "Bold", etc. into DISPID_FONT_NAME, etc. In particular, this game only needs "Size." It's not hard to code that, and make the game work. I'm not sure, though, what the proper approach would be for an acceptable patch: 1. Just code in the string comparisons, ignoring the locale. (Google provides no evidence that the property names vary by locale). 2. Call GetTypeInfo to get an ITypeInfo, and call DispGetIDsOfNames on that. I think this means that the information should be extracted from stdole32.tlb. Currently this doesn't find any match for these property names. Do they need to be added to stdole32.tlb somehow? 3. Something else. Any ideas? Thanks, Walter

2 2

Need help debugging a memory corruption bug in shfldr_unixfs.c
by Michael Jung 12 Sep '05

12 Sep '05

Hi, Sometimes while browsing the unixfs namespace in the file dialog wine crashes with the following console output: ============================================================================= wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x00004005 in 32-bit code (0x7b24fbf2). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:7b24fbf2 ESP:7b8af188 EBP:7b8af1ac EFLAGS:00210202( - 00 - -RI1) EAX:00000000 EBX:7b2e8b70 ECX:78560110 EDX:7b8af258 ESI:7b2e88f6 EDI:00004001 Stack dump: 0x7b8af188: 00000000 000007d0 7b8af298 00000000 0x7b8af198: 00000008 00000001 7b2e8b70 00000000 0x7b8af1a8: 7b8af1f8 7b8af244 7b2696a2 00004001 0x7b8af1b8: 00000015 00000040 00000000 78561a78 0x7b8af1c8: 78561a78 7b4e8448 7b8af298 00000000 0x7b8af1d8: 7b8af204 7b47bfd1 0036003e 0000004e Backtrace: =>1 0x7b24fbf2 DPA_GetPtr+0x32(hdpa=0x4001, nIndex=0x15) [dpa.c:479] in comctl32 (0x7b8af1ac) 2 0x7b2696a2 LISTVIEW_GetItemT(infoPtr=0x78560110, lpLVItem=0x7b8af258, isW=0x1) [/home/mjung/compile/wine/dlls/comctl32/listview.c:5225] in comctl32 (0x7b8af244) 3 0x7b273e7a notify_itemactivate+0x6a(infoPtr=0x78560110, htInfo=0x7b8af308) [/home/mjung/compile/wine/dlls/comctl32/listview.c:791] in comctl32 (0x7b8af2d4) 4 0x7b26fd5f LISTVIEW_LButtonDblClk+0x8f(infoPtr=0x78560110, wKey=0x1, x=0xad, y=0x39) [/home/mjung/compile/wine/dlls/comctl32/listview.c:8103] in comctl32 (0x7b8af334) ... =============================================================================== As you see, the hdpa parameter to DPA_GetPtr is invalid. The relevant code in LISTVIEW_GetItemT is (dlls/comctl32/listview.c, line 5126): /* find the item and subitem structures before we proceed */ hdpaSubItems = (HDPA)DPA_GetPtr(infoPtr->hdpaItems, lpLVItem->iItem); lpItem = (ITEM_INFO *)DPA_GetPtr(hdpaSubItems, 0); assert (lpItem); It's the first call to DPA_GetPtr that crashes. So the structure pointed to by infoPtr seems to be corrupted (infoPtr is a LISTVIEW_INFO *, which represents the listview item and which given as the first parameter to LISTVIEW_GetItemT). As I never saw this with the original shfldr_fs.c code, I assume that shfldr_unixfs.c has a memory corruption bug somewhere. I've tried to figure the problem for some time now, but to now avail. So my questions are: 1) Can someone give me some advice on how to debug such a problem? 2) Did other people see this bug already? 3) Would valgrind be of help to debug this? Thanks, -- Michael Jung mjung(a)iss.tu-darmstadt.de

7 21

← Newer
1
...
15
16
17
18
19
20
21
...
28
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel September 2005