August 2002 - Wine-Devel - list.winehq.org

Re: Recent patches introduced a regression error

by Paul Millar

On Thu, 1 Aug 2002, [iso-8859-1] Sylvain Petreolle wrote: > http://www.winehq.com/hypermail/wine-devel/2002/07/0386.html Hi Sylvain, Sorry, I meant to reply to that email earlier. I've notice the same or similar thing with WRT. If you look at around Friday July 19 (see Win3.0 tests column in [1]), you'll see four tests weren't conducted. Next build cycle they were. The same thing happened earlier, although less clearly, around 5th July (see [2]). On Friday, new regression tests were added, two of which failed straight away (the C:, D: problem). Because the tests are only known by their file-name and line-number, the new tests cause the "-27 tests +42 tests" on each build. Except, for Win2.0 tests 31 tests were not conducted, ie 4 extra test. The following Monday, these tests were conducted, but 4 tests were not conducted for the Win3.1 platform, only for those tests to be conducted on Tuesday (+59 tests for Win3.1 instead of +55). What happened was this: the patches tend to be applied during the night (local time) and unless I happen to be working late, I discover the effects of the patches in the morning. For those particular builds I discovered that the regression tests had frozen, just as you describe. I had to kill wine so the cycle could complete. With a bit of detective work, I traced the problem down to wininet. It seemed that the exact order in which the tests are run is random (multiple threads? -- I haven't had a chance to check the code yet). As the problem didn't immediately resurface after Monday 8th July, I assumed that it was a low-probability thread contention/deadlock issue. I tried conducting just the regression tests for wininet, without being able to reproducing the problem, but I didn't think to try the whole tests (just assumed that the tests were independent). It looks like something has changed, so the occasional-hard-lock problem has been replaced by the system freezing for many minutes before reporting a regression test failure. So, Sylvain, when you run the tests now, does it eventually time-out returning a error, or does it freeze forever? Cheers, Paul [1] http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php?max=5&start=102 [2] http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php?max=5&start=94 ---- Paul Millar > --- Paul Millar <paulm(a)astro.gla.ac.uk> a �crit�: > Hi, > > > > According to WRT [1], one of todays patches caused a regression > > error, > > picked up by one of the wininet DLL tests. Only, none of the patches > > seem > > to have touched wininet. > > > > The problem is with the tests at dlls/wininet/tests/http.c lines 117 > > and > > 157. The test freezes for up to 4 minutes, then returns the failures. > > > > As an act in desperation, I've tried reversing some of the patches > > (1-4, > > 6, and 7 from the WRT list) without success. > > > > I'm also a little suspicious that this might be something to do with > > Glasgow (or me :) I've been able to reproduce the problem on two > > other > > (local) machines, but I've not tried on any remote machines. I've > > also > > tried using earlier cvs versions (from a few days ago), but that > > build > > fails the wininet tests too. It would be good if someone could > > confirm the > > problem. > > > > Sorry if this turns out to be a red herring ... > > > > Paul. > > > > PS It's quite late here, so I might not be able to reply until > > tomorrow. > > > > [1] http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php

Aug. 1, 2002

Re: Translation wine documentation to other languages

by Andreas Mohr

On Fri, May 31, 2002 at 11:49:50AM -0700, Andriy Palamarchuk wrote: > Sorry for crossposting initial message to both lists. > I think the topic may be interesting for both - users > and developers. > > Any volunteers to help to translate the documentation > to languages other than English? This is very big job, > so there can be more than one person, working on the > same language. Well, as long as there's no suitable infrastructure in place, we could just as well forget about doing this, due to the overwhelming size. IMHO we should have a separate CVS for internationalization. Also every patch to the english docu should trigger a ToDo item on a web page for a specific language. Whether the notifications get done automatically or manually doesn't matter. What matters is that there is a *lossless* notification of translation requirements for certain languages (in order to make dead sure that the docu does stay in sync). The CVS used for committing changes to the internationalization project should be as public as possible, and as closed as required. Whenever someone commits a translation patch for his specific language, he will remove the corresponding ToDo item on the language's web page. I already talked to certain web development related people (you know whom ;-) but so far I haven't received any input. Thus we should actually code some interface to a web page that enables Alexandre to trigger a ToDo notification on the various language bug pages. Having such notification web pages with delete functionality is no small functionality (and no, BugZilla doesn't qualify, IMHO), so does anyone know of some web based package that enables us to design such a thing with a *minimum* amount of effort ? (most likely a database backend is required, too) Or, better yet (aka: "million $$ question"), would someone code this up for us ? -- Microsoft Licensing 6.0: "Pay us now in advance, so that we can own you later."

Aug. 1, 2002

Re: PATCH: Convert HMIDI to void*

by Alexandre Julliard

Michael Stefaniuc <mstefani(a)redhat.de> writes: > No, use my version instead ;) (it's attached). It proper handles > HMIDI*16 <-> HMIDI* conversions. It would be better to add HMIDIIN_16 etc. macros to do the 32->16 conversion, just like you did for the 16->32 one. This way if we need a more complex conversion one day it's easy to change; if you just use LOWORD everywhere we have no way of spotting places that need to be changed. -- Alexandre Julliard julliard(a)winehq.com

Aug. 1, 2002

Re: Recent patches introduced a regression error

by Sylvain Petreolle

http://www.winehq.com/hypermail/wine-devel/2002/07/0386.html --- Paul Millar <paulm(a)astro.gla.ac.uk> a écrit : > Hi, > > According to WRT [1], one of todays patches caused a regression > error, > picked up by one of the wininet DLL tests. Only, none of the patches > seem > to have touched wininet. > > The problem is with the tests at dlls/wininet/tests/http.c lines 117 > and > 157. The test freezes for up to 4 minutes, then returns the failures. > > As an act in desperation, I've tried reversing some of the patches > (1-4, > 6, and 7 from the WRT list) without success. > > I'm also a little suspicious that this might be something to do with > Glasgow (or me :) I've been able to reproduce the problem on two > other > (local) machines, but I've not tried on any remote machines. I've > also > tried using earlier cvs versions (from a few days ago), but that > build > fails the wininet tests too. It would be good if someone could > confirm the > problem. > > Sorry if this turns out to be a red herring ... > > Paul. > > PS It's quite late here, so I might not be able to reply until > tomorrow. > > [1] http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php > > ---- > Paul Millar > > ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Aug. 1, 2002

Re: PATCH: Convert HMIDI to void*

by Michael Stefaniuc

On Thu, Aug 01, 2002 at 09:13:40AM +0200, Eric Pouech wrote: > Michael Stefaniuc a écrit : > > > > Hello, > > > > am I right that HMIDI and HMIDIIN, HMIDIOUT shouldn't be > > interchangeable? Would save some conversions. > > > > License: LGPL, X11 > > Changelog: > > Michael Stefaniuc <mstefani(a)redhat.com> > > Convert HMIDI to a void* > I just modified a bit Michael's patch: > - better fix for midimap file > - changed all HMIDI???? > > Alexandre, use this version instead. No, use my version instead ;) (it's attached). It proper handles HMIDI*16 <-> HMIDI* conversions. The patch is based on Eric patch which is based on my patch ... License: LGPL, X11 Changelog: Eric Pouech <eric.pouech(a)wanadoo.fr> Michael Stefaniuc <mstefani(a)redhat.com> - Convert HMIDI, HMIDIIN, HMIDIOUT, HMIDISTRM to void* bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Aug. 1, 2002

Compilation error with newer CVS on glibc -2.0

by Martin Cracauer

Hi, guys, since Jul 20 or so I get this compilation error on glibc-2.1.3/linux-2.4.18: gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -fno-strength-reduce -mpreferred-stack-boundary=2 -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o wrc.o wrc.c In file included from wrc.h:25, from wrc.c:61: wrctypes.h:447: redefinition of `struct user' make[2]: *** [wrc.o] Error 1 make[2]: Leaving directory `/disks/part9/home/cracauer/work/cvs-packages-work/stupids/wine/wine/tools/wrc' Wine's definition of struct user is clashing with the one from /usr/include/sys/user.h Now, it appears that /usr/include/sys/user.h (a glibc-2.1.3 file) is in error having this struct in first place, since newer kernels have this struct in asm/user.h. I fixed the problem in my /usr/include, but I guess it is better to use a different name for the struct in Wine to be compatible with this configuration (it's Debian-2.1 with an upgraded kernel). Unless somebody disagrees with that analysis, I'll submit a patch to rename the struct. Suggestions about a suitable name welcome. Martin

Aug. 1, 2002

Re: PATCH: Convert HMIDI to void*

by Eric Pouech

Michael Stefaniuc a écrit : > > Hello, > > am I right that HMIDI and HMIDIIN, HMIDIOUT shouldn't be > interchangeable? Would save some conversions. > > License: LGPL, X11 > Changelog: > Michael Stefaniuc <mstefani(a)redhat.com> > Convert HMIDI to a void* I just modified a bit Michael's patch: - better fix for midimap file - changed all HMIDI???? Alexandre, use this version instead. A+ Name: mm_midih ChangeLog: HMIDI??? handles are no long OLD_HANDLE License: X11 GenDate: 2002/08/01 07:11:07 UTC ModifiedFiles: dlls/winmm/lolvldrv.c dlls/winmm/mmsystem.c dlls/winmm/mciseq/mcimidi.c dlls/winmm/midimap/midimap.c include/mmsystem.h AddedFiles: =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/dlls/winmm/lolvldrv.c,v retrieving revision 1.29 diff -u -u -r1.29 lolvldrv.c --- dlls/winmm/lolvldrv.c 3 Jul 2002 21:10:44 -0000 1.29 +++ dlls/winmm/lolvldrv.c 1 Aug 2002 06:51:25 -0000 @@ -693,7 +693,7 @@ *(LPDWORD)((char*)ptr + sizeof(LPMIDIOPENDESC)) = *lpdwUser; mod16 = (LPMIDIOPENDESC16)((LPSTR)ptr + sizeof(LPMIDIOPENDESC) + 2*sizeof(DWORD)); - mod16->hMidi = mod32->hMidi; + mod16->hMidi = LOWORD(mod32->hMidi); mod16->dwCallback = mod32->dwCallback; mod16->dwInstance = mod32->dwInstance; mod16->dnDevNode = mod32->dnDevNode; Index: dlls/winmm/mmsystem.c =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/dlls/winmm/mmsystem.c,v retrieving revision 1.63 diff -u -u -r1.63 mmsystem.c --- dlls/winmm/mmsystem.c 29 Jul 2002 23:29:23 -0000 1.63 +++ dlls/winmm/mmsystem.c 1 Aug 2002 06:51:25 -0000 @@ -2188,7 +2188,7 @@ *lphMidiOut = hMidiOut; if (lpwm) { - lpwm->mod.hMidi = hMidiOut; + lpwm->mod.hMidi = (HMIDI) hMidiOut; lpwm->mod.dwCallback = *lpdwCallback; lpwm->mod.dwInstance = *lpdwInstance; lpwm->mod.dnDevNode = 0; @@ -2739,7 +2739,7 @@ if (lpwm == NULL) return MMSYSERR_NOMEM; - lpwm->mod.hMidi = hMidiIn; + lpwm->mod.hMidi = (HMIDI) hMidiIn; lpwm->mod.dwCallback = dwCallback; lpwm->mod.dwInstance = dwInstance; Index: dlls/winmm/mciseq/mcimidi.c =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/dlls/winmm/mciseq/mcimidi.c,v retrieving revision 1.16 diff -u -u -r1.16 mcimidi.c --- dlls/winmm/mciseq/mcimidi.c 31 May 2002 23:40:57 -0000 1.16 +++ dlls/winmm/mciseq/mcimidi.c 1 Aug 2002 06:51:25 -0000 @@ -817,7 +817,7 @@ wmm->dwStatus = MCI_MODE_NOT_READY; if (oldstat == MCI_MODE_PAUSE) - dwRet = midiOutReset(wmm->hMidi); + dwRet = midiOutReset((HMIDIOUT)wmm->hMidi); while (wmm->dwStatus != MCI_MODE_STOP) Sleep(10); @@ -962,7 +962,7 @@ MIDI_mciReadNextEvent(wmm, mmt); /* FIXME == 0 */ } - dwRet = midiOutOpen(&wmm->hMidi, MIDIMAPPER, 0L, 0L, CALLBACK_NULL); + dwRet = midiOutOpen((LPHMIDIOUT)&wmm->hMidi, MIDIMAPPER, 0L, 0L, CALLBACK_NULL); /* dwRet = midiInOpen(&wmm->hMidi, MIDIMAPPER, 0L, 0L, CALLBACK_NULL);*/ if (dwRet != MMSYSERR_NOERROR) { return dwRet; @@ -1142,7 +1142,7 @@ break; default: if (doPlay) { - dwRet = midiOutShortMsg(wmm->hMidi, mmt->dwEventData); + dwRet = midiOutShortMsg((HMIDIOUT)wmm->hMidi, mmt->dwEventData); } else { switch (LOBYTE(LOWORD(mmt->dwEventData)) & 0xF0) { case MIDI_NOTEON: @@ -1150,7 +1150,7 @@ dwRet = 0; break; default: - dwRet = midiOutShortMsg(wmm->hMidi, mmt->dwEventData); + dwRet = midiOutShortMsg((HMIDIOUT)wmm->hMidi, mmt->dwEventData); } } } @@ -1163,9 +1163,9 @@ } } - midiOutReset(wmm->hMidi); + midiOutReset((HMIDIOUT)wmm->hMidi); - dwRet = midiOutClose(wmm->hMidi); + dwRet = midiOutClose((HMIDIOUT)wmm->hMidi); /* to restart playing at beginning when it's over */ wmm->dwPositionMS = 0; @@ -1212,7 +1212,7 @@ midiHdr.dwBufferLength = 1024; midiHdr.dwUser = 0L; midiHdr.dwFlags = 0L; - dwRet = midiInPrepareHeader(wmm->hMidi, &midiHdr, sizeof(MIDIHDR)); + dwRet = midiInPrepareHeader((HMIDIIN)wmm->hMidi, &midiHdr, sizeof(MIDIHDR)); TRACE("After MIDM_PREPARE \n"); wmm->dwStatus = MCI_MODE_RECORD; /* FIXME: there is no buffer added */ @@ -1220,12 +1220,12 @@ TRACE("wmm->dwStatus=%p %d\n", &wmm->dwStatus, wmm->dwStatus); midiHdr.dwBytesRecorded = 0; - dwRet = midiInStart(wmm->hMidi); + dwRet = midiInStart((HMIDIIN)wmm->hMidi); TRACE("midiInStart => dwBytesRecorded=%lu\n", midiHdr.dwBytesRecorded); if (midiHdr.dwBytesRecorded == 0) break; } TRACE("Before MIDM_UNPREPARE \n"); - dwRet = midiInUnprepareHeader(wmm->hMidi, &midiHdr, sizeof(MIDIHDR)); + dwRet = midiInUnprepareHeader((HMIDIIN)wmm->hMidi, &midiHdr, sizeof(MIDIHDR)); TRACE("After MIDM_UNPREPARE \n"); if (midiHdr.lpData != NULL) { HeapFree(GetProcessHeap(), 0, midiHdr.lpData); @@ -1255,7 +1255,7 @@ /* stop all notes */ unsigned chn; for (chn = 0; chn < 16; chn++) - midiOutShortMsg(wmm->hMidi, 0x78B0 | chn); + midiOutShortMsg((HMIDIOUT)(wmm->hMidi), 0x78B0 | chn); wmm->dwStatus = MCI_MODE_PAUSE; } if (lpParms && (dwFlags & MCI_NOTIFY)) { Index: dlls/winmm/midimap/midimap.c =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/dlls/winmm/midimap/midimap.c,v retrieving revision 1.13 diff -u -u -r1.13 midimap.c --- dlls/winmm/midimap/midimap.c 31 May 2002 23:40:57 -0000 1.13 +++ dlls/winmm/midimap/midimap.c 1 Aug 2002 06:46:12 -0000 @@ -81,7 +81,7 @@ { char name[MAXPNAMELEN]; int loaded; - HMIDI hMidi; + HMIDIOUT hMidi; unsigned short uDevID; LPBYTE lpbPatch; unsigned int aChn[16]; Index: include/mmsystem.h =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/include/mmsystem.h,v retrieving revision 1.51 diff -u -u -r1.51 mmsystem.h --- include/mmsystem.h 31 May 2002 23:06:48 -0000 1.51 +++ include/mmsystem.h 1 Aug 2002 06:52:49 -0000 @@ -34,10 +34,10 @@ DECLARE_OLD_HANDLE(HWAVE); DECLARE_OLD_HANDLE(HWAVEIN); DECLARE_OLD_HANDLE(HWAVEOUT); -DECLARE_OLD_HANDLE(HMIDI); -DECLARE_OLD_HANDLE(HMIDIIN); -DECLARE_OLD_HANDLE(HMIDIOUT); -DECLARE_OLD_HANDLE(HMIDISTRM); +DECLARE_HANDLE(HMIDI); +DECLARE_HANDLE(HMIDIIN); +DECLARE_HANDLE(HMIDIOUT); +DECLARE_HANDLE(HMIDISTRM); DECLARE_OLD_HANDLE(HMIXER); DECLARE_OLD_HANDLE(HMIXEROBJ); DECLARE_OLD_HANDLE(HMMIO);

Aug. 1, 2002

Recent patches introduced a regression error

by Paul Millar

Hi, According to WRT [1], one of todays patches caused a regression error, picked up by one of the wininet DLL tests. Only, none of the patches seem to have touched wininet. The problem is with the tests at dlls/wininet/tests/http.c lines 117 and 157. The test freezes for up to 4 minutes, then returns the failures. As an act in desperation, I've tried reversing some of the patches (1-4, 6, and 7 from the WRT list) without success. I'm also a little suspicious that this might be something to do with Glasgow (or me :) I've been able to reproduce the problem on two other (local) machines, but I've not tried on any remote machines. I've also tried using earlier cvs versions (from a few days ago), but that build fails the wininet tests too. It would be good if someone could confirm the problem. Sorry if this turns out to be a red herring ... Paul. PS It's quite late here, so I might not be able to reply until tomorrow. [1] http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php ---- Paul Millar

Aug. 1, 2002

Re: Netbios and Wins support

by Mike McCormack

Hi Claudiu, I've been doing some work to get Windows shares to work in Wine without having to use smbmount. There's still a very long way to go before we can use DCOM over named pipes. I'm pretty sure, however, that Outlook does not depend on NETBIOS support when connecting to an Exchange server. Mike Claudiu Costin wrote: > Dear friends, > > Is there anybody working on Netbios/MS Windows Network support? > I want to run Outlook with Exchange. I can help testing > and hacking, but not writing real code. > > > kind regards,

Aug. 1, 2002