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

Re: PATCH: accept-deferred.diff (5 in series)

by Alexandre Julliard

Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> writes: > PATCH: accept-deferred.diff > > If a connection request is deferred in a call to WSAAccept(), > a subsequent accept()/WSAAccept() call must return the > previously deferred connection rather than a new one. You cannot store a handle to the deferred socket in the server, you must store a pointer to the object and allocate a handle when returning it to the application. Handles are only valid in one process so they cannot be part of a server object that is potentially shared between several processes. -- Alexandre Julliard julliard(a)winehq.com

April 17, 2002

Re: building documentation failed

by Michael Stefaniuc

Hello! On Tue, Apr 16, 2002 at 09:25:44AM +0200, Stefan Leichter wrote: > > > > On Sat, Apr 13, 2002 at 01:36:37PM +0200, Stefan Leichter wrote: > > > when i run make inside the ~wine/documentation directory i get an error when > > > the pdf is created. The fix is easy for me, just an additional parameter (-s) > > > for the command db2pdf. > > > > > > But before i send the attached patch to wine-patches i like to know if anyone > > > can run make successful in the documentation directory. In this case we may > > > have to add a check in the configure script. > > > > > > If someone is able to build the documentation successful please post the > > > output of "db2pdf -v". > > Yes, it works without the "-s" for me. > > camus:~/work/wine/documentation$ db2pdf -v > > DocBook-utils version 0.6.9 (jw version 1.1) > > does the documentation build with '-s' too? No, it fails with unknown option and presents me the db2pdf -h output. 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

April 17, 2002

Re: small patch for ./tools/wineinstall

by Speeddymon

my first patch fixes that problem and quite a few others --- Tony Lambregts <tony_lambregts(a)telusplanet.net> wrote: > I seems with all the changes to ./tools/wineinstall > the installation of > the default wine registries does not happen when we > have a no windows > install. This little patch seems to do the trick > > Tony Lambregts > > > > > ? wineinstall.dif > Index: wineinstall > =================================================================== > RCS file: /home/wine/wine/tools/wineinstall,v > retrieving revision 1.26 > diff -u -r1.26 wineinstall > --- wineinstall 1 Apr 2002 20:56:51 -0000 1.26 > +++ wineinstall 17 Apr 2002 20:56:27 -0000 > @@ -578,7 +578,7 @@ > # (not to be done if windows registry exists) > if [ "$DOREG" = 'auto' ] > then { > - CROOT=`sed -n '/^\[Drive C\]$/,/^\[.*\]$/ > s/^Path=$.*$/\1/p' $CONF` > + CROOT=`awk -F\" '/\[Drive C]/ {if (getline) print > $4}' $LCONF` > echo "Checking for real Windows registry..." > if [ -f "$CROOT/windows/system.dat" ] > then DOREG=no > __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/

April 17, 2002

Installing MS Office gives error in installer

by Speeddymon

I just recently installed wine-20020411 (as you may have noticed from my patch) I haven't tried installing Office 2000 on previous versions, but heard that it worked, so I decided to try it. First I tried it in Crossover Office (since i just recently got that also) and the Office 2000 installer complained that it couldnt find a package to install on the installation media. So I tried it in wine and it did the same thing... There were no debug messages or anything (in the console). If anyone knows of a way around this, please let me know... If it has been mentioned before please point me to the right wine-devel archive so I can find it... Thanks, Dustin __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/

April 17, 2002

PATCH: TOOLTIPS_GetTipText

by Christian COSTA

Hi! The following patch fix at least one app but I don't know if it could break something. Assuming Loadstring accept handle equal to 0, I modified the function accordingly but is it right? Can somenone enlighten me? Bye. Changelog : dlls/comctl32/tooltips.c : TOOLTIPS_GetTipText allows module handle equal to 0 which refer to the current module Christian COSTA titan.costa(a)wanadoo.fr Index: tooltips.c =================================================================== RCS file: /home/wine/wine/dlls/comctl32/tooltips.c,v retrieving revision 1.42 diff -u -r1.42 tooltips.c --- tooltips.c 9 Mar 2002 23:29:34 -0000 1.42 +++ tooltips.c 17 Apr 2002 19:11:40 -0000 @@ -184,7 +184,7 @@ { TTTOOL_INFO *toolPtr = &infoPtr->tools[nTool]; - if ((toolPtr->hinst) && (HIWORD((UINT)toolPtr->lpszText) == 0)) { + if (HIWORD((UINT)toolPtr->lpszText) == 0) { /* load a resource */ TRACE("load res string %x %x\n", toolPtr->hinst, (int)toolPtr->lpszText); @@ -208,7 +208,7 @@ SendMessageA (toolPtr->hwnd, WM_NOTIFY, (WPARAM)toolPtr->uId, (LPARAM)&ttnmdi); - if ((ttnmdi.hinst) && (HIWORD((UINT)ttnmdi.lpszText) == 0)) { + if (HIWORD((UINT)ttnmdi.lpszText) == 0) { LoadStringW (ttnmdi.hinst, (UINT)ttnmdi.lpszText, infoPtr->szTipText, INFOTIPSIZE); if (ttnmdi.uFlags & TTF_DI_SETITEM) {

April 17, 2002

Kernel32 segfaults on compile

by Ben Woodhead

Hello Everybody.. I just tried but the 20020411 release and cvs and I get the same results running ./tools/wineinstall make[2]: Entering directory `/home/ben/homes/src/wine/dlls/kernel' LD_LIBRARY_PATH="../../unicode:$LD_LIBRARY_PATH" ../../tools/winebuild/winebuild -fPIC -L../../dlls -o kernel32.spec.c -spec ./kernel32.spec make[2]: *** [kernel32.spec.c] Segmentation fault make[2]: *** Deleting file `kernel32.spec.c' make[2]: Leaving directory `/home/ben/homes/src/wine/dlls/kernel' make[1]: *** [kernel/kernel32.dll.so] Error 2 make[1]: Leaving directory `/home/ben/homes/src/wine/dlls' make: *** [dlls] Error 2 I am running Slackware8.. GCC version - 2.95.3 GLIB version - 2.2.5 GNU make verison - 3.79.1 Thanks, Ben ps Is anybody else having this problem..

April 17, 2002

Re: PATCH : VGA_ioport_in and vertical refresh

by Christian COSTA

Eric Pouech a écrit : > > Christian COSTA a écrit : > > > > Changelog : > > dlls/winedos/vga.c : VGA_ioport_in > > Fake the occurence of the vertical refresh when no graphic mode > > has been set > > > > Christian COSTA titan.costa(a)wanadoo.fr > avec le patch ca serait mieux ;-) > A+ Ah ben alors! ;-) I've just resent it... A+

April 17, 2002

Re: fixme:win32:PeekNamedPipe

by Andriy Palamarchuk

I just came across bugzilla entry about this issue - bug 297: http://wine.codeweavers.com/bugs/show_bug.cgi?id=297 If anybody starts to work on the bug, please take this bug and keep it updated. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/

April 17, 2002

Re: Urgent need for advice: POLLHUP and sockets

by Martin Wilck

Dear Ove - thanks a lot for your comments & explanations. It seems that I will finally be able to present an implementation of overlapped IO on sockets that works. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

April 17, 2002

Re: Why Wine is like playing the guitar

by Kari Hurtta

http://www.winehq.com/hypermail/wine-devel/2002/03/0226.html | From: Steven Edwards (steven_ed4153(a)yahoo.com) | Date: Wed Mar 20 2002 - 03:14:30 CST | On a Side Note: | One thing that Wine/Lindows and Reactos will need is | to be able to run alot of the newer programs with | tighter Mozzila/NS intigration. This was discussed a | little during James's presentation on the Jscript.dll | interface to Seamonkey. Some of the newer software | loads Internet Explorers MSHTML.DLL for rendering | and I belive that this software with a little help | from wine could run better with tigher Mozilla | Intergration. Perhaps following is related: http://www.iol.ie/~locka/mozilla/control.htm | ActiveX Control Implementation | Not just a similar API | An identical one! That's right, the Mozilla control will implement the | IWebBrowser and DWebBrowserEvents interfaces that Microsoft have | already defined for Internet Explorer. | | Since the Mozilla control implements exactly the same API, it will | mean that developers can take existing IE code and port it, sometimes | in a matter of minutes!

April 17, 2002

Re: PATCH : VGA_ioport_in and vertical refresh

by Dimitrie O. Paun

On April 16, 2002 03:18 pm, Christian COSTA wrote: > Changelog : > dlls/winedos/vga.c : VGA_ioport_in > Fake the occurence of the vertical refresh when no graphic mode > has been set A patch would be nice... ;) -- Dimi.

April 17, 2002

Re: PATCH : VGA_ioport_in and vertical refresh

by Eric Pouech

Christian COSTA a écrit : > > Changelog : > dlls/winedos/vga.c : VGA_ioport_in > Fake the occurence of the vertical refresh when no graphic mode > has been set > > Christian COSTA titan.costa(a)wanadoo.fr avec le patch ca serait mieux ;-) A+

April 17, 2002

Re: Debugger looping busy

by Eric Pouech

Sylvain Petreolle a écrit : > > > some questions: > > - do you use the wineconsole or directly from the > > Unix console > I run it directly from the Unix console. could you try to run it from the wineconsole (use set $UseXTerm = 1 in a winedbg session and exit winedbg to use that as a default setting) could you send me the -debugmsg +console,+server (at least the part when the debugger is started and fails on line reading) TIA

April 17, 2002

Re: Urgent need for advice: POLLHUP and sockets

by Martin Wilck

On Wed, 17 Apr 2002, Ove Kaaven wrote: > are you talking about something else? Hmm, sounds like you may be talking > about sock_poll_event... ok, let's see... Of course I meant poll_event. Well I am a bit confused ... :-) > The event mask to check for may change during sock_poll_event and it would > be nice to check for those new events immediately. But at the moment I > don't recall any situation where it would be necessary. I am currently trying to split the sock_reselect functionality and introduce a separate function that takes over the checking if the socket has been kicked out of main the select loop. I just need to figure out where exactly I need to call that function. I am also not sure whether any combination of the FD_... and FD_WINE... flags suffices to tell if the socket is in the select loop or not, because of the many different situations that may affect these flags. Even after working on this code for a few months now, I still find the management of the socket state flags and various masks pretty confusing. But I'm getting there. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

April 17, 2002

Re: Urgent need for advice: POLLHUP and sockets

by Ove Kaaven

On Wed, 17 Apr 2002, Martin Wilck wrote: > 1. In the code you're talking about, there is a potential mutual recursion > because sock_get_poll_events calls sock_reselect, which may in turn call > sock_get_poll_events. sock_get_poll_events does not call sock_reselect in the code I'm referring to, I see no reason it should. Its sole purpose is to return the event mask that should be polled next, it should not effectuate this mask. Or are you talking about something else? Hmm, sounds like you may be talking about sock_poll_event... ok, let's see... > I understand that infinite recursion is prevented by > handling the sock->hmask field, but I wonder whether it is necessary at > all that sock_get_poll_events calls sock_reselect() and not > only set_select_events(sock_get_poll_events()) ? The event mask to check for may change during sock_poll_event and it would be nice to check for those new events immediately. But at the moment I don't recall any situation where it would be necessary. > I'd prefer a solution where no call sequence > sock_get_poll_events->sock_reselect->sock_get_poll_events->... would > be possible. > > 2. IMO, the code snippet > > if (event & POLLIN) > { > char dummy; > /* Linux 2.4 doesn't report POLLHUP if only one side of the socket > * has been closed, so we need to check for it explicitly here */ > if (!recv( sock->obj.fd, &dummy, 1, MSG_PEEK )) event = POLLHUP; > } > [...] > > if (event & (POLLERR|POLLHUP)) > set_select_events( &sock->obj, -1 ); > > is wrong, because an empty read only signals that the upstream connection > was closed. Hmm. I don't think I wrote that code piece, so I don't recall its justification. It may well be that it was ill-conceived (at least I don't quite like the looks of that code), especially since POLLHUP is the "problem" we tried to solve with all this insidious code, not its "solution". There used to be different code to detect a closed socket, but it seems it was removed for some reason (probably because it had other issues), and then maybe that thing above was hacked on top because the old code was no longer there? > The downstream connection may still be open, i.e. FD_WRITE > events may well occur. In this case it seems to be wrong to do > set_select_events( &sock->obj, -1 ) _unless_ the kernel had signalled > POLLHUP|POLLIN, which means that both sides of the socket have been > closed. Thus, if we have an empty read but no POLLHUP from the kernel, > we should signal FD_CLOSE to the app, but not pretend we had got POLLHUP > as the current code does. > > Right? Yeah.

April 17, 2002

Re: Urgent need for advice: POLLHUP and sockets

by Martin Wilck

On Wed, 17 Apr 2002, Ove Kaaven wrote: > I can send you the sock.c I have if you wish, but you may be able to check > out an earlier revision yourself. Yeah, I checked out 1.27 and am stuying it right now. > If this code path was removed, then you'll probably have to put it back > in. I guess I need to do some more things for the overlapped IO, but basically you are right. I have 2 questions: 1. In the code you're talking about, there is a potential mutual recursion because sock_get_poll_events calls sock_reselect, which may in turn call sock_get_poll_events. I understand that infinite recursion is prevented by handling the sock->hmask field, but I wonder whether it is necessary at all that sock_get_poll_events calls sock_reselect() and not only set_select_events(sock_get_poll_events()) ? I'd prefer a solution where no call sequence sock_get_poll_events->sock_reselect->sock_get_poll_events->... would be possible. 2. IMO, the code snippet if (event & POLLIN) { char dummy; /* Linux 2.4 doesn't report POLLHUP if only one side of the socket * has been closed, so we need to check for it explicitly here */ if (!recv( sock->obj.fd, &dummy, 1, MSG_PEEK )) event = POLLHUP; } [...] if (event & (POLLERR|POLLHUP)) set_select_events( &sock->obj, -1 ); is wrong, because an empty read only signals that the upstream connection was closed. The downstream connection may still be open, i.e. FD_WRITE events may well occur. In this case it seems to be wrong to do set_select_events( &sock->obj, -1 ) _unless_ the kernel had signalled POLLHUP|POLLIN, which means that both sides of the socket have been closed. Thus, if we have an empty read but no POLLHUP from the kernel, we should signal FD_CLOSE to the app, but not pretend we had got POLLHUP as the current code does. Right? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

April 17, 2002

Re: Urgent need for advice: POLLHUP and sockets

by Ove Kaaven

On Wed, 17 Apr 2002, Martin Wilck wrote: > > > However, if an application uses asynchronous IO (or only asynchronous > > > notification via WSAAsyncSelect() or WSAEventSelect()), this also inhibits > > > reception of POLLIN events which can perfectly well occur if there are > > > still unread data in the kernel buffers. Thus the app will never notice > > > that there is still data to be read. > > > > Not quite. No more data will arrive on the socket when it's in POLLHUP > > state, so there's no need for the server to poll. > > Instead, it notifies the > > app that there's still data remaining to be read next time it reads from > > the socket (this is what the "check whether condition is satisfied > > already" case in sock_reselect does, it explicitly does a poll even if the > > socket is removed from the main polling loop, in order to check for > > remaining data). > > Hmm - this code went away with CVS version 1.28 of sock.c. > Perhaps we need to reintroduce it somehow. I can send you the sock.c I have if you wish, but you may be able to check out an earlier revision yourself. > > Sending the app new FD_READ events only after it has read > > old data is a documented Windows feature; further FD_READ events are held > > back until the app reads old data, and this is what the wineserver > > implements, especially in the POLLHUP case. > > Sorry, I cannot see what you are talking about, not in the current CVS > version. All that happens after a read() is issued is > _enable_event (FD_READ, 0, 0), and that clears the pending mask for > FD_READ. How would that ever be set again, and FD_READ signalled ? req->mask is here FD_READ, and the handler contains sock->pmask &= ~req->mask; sock->hmask &= ~req->mask; sock->state |= req->sstate; sock->state &= ~req->cstate; sock_reselect( sock ); where sock_reselect includes this at the end /* check whether condition is satisfied already */ pfd.fd = sock->obj.fd; pfd.events = ev; pfd.revents = 0; poll( &pfd, 1, 0 ); if (pfd.revents) sock_poll_event( &sock->obj, pfd.revents); result: sock_poll_event sets FD_READ flag and notifies the application in response to the _enable_event, i.e. after it has read something, even if the socket is not in the main poll loop. We never got around to change the comment to explain this additional function. > The key probably is that sock_poll_event() was called from > sock_reselect() if the "condition is satisfied", which is no longer the > case in 1.28. If this code path was removed, then you'll probably have to put it back in.

April 17, 2002

Re: Urgent need for advice: POLLHUP and sockets

by Martin Wilck

On Tue, 16 Apr 2002, Ove Kaaven wrote: > Sounds like one we've discussed and resolved before. Sorry, that was before my times :) Anyway, I think there are open issues yet. > Yes, it's still valid to read, but no more data will arrive on the socket, > so the only thing you'll read is data that's already waiting in the kernel > buffers. There's no reason to continue actively polling. Yes but read events must be signalled and/or async reads scheduled after POLLHUP was received. > > However, if an application uses asynchronous IO (or only asynchronous > > notification via WSAAsyncSelect() or WSAEventSelect()), this also inhibits > > reception of POLLIN events which can perfectly well occur if there are > > still unread data in the kernel buffers. Thus the app will never notice > > that there is still data to be read. > > Not quite. No more data will arrive on the socket when it's in POLLHUP > state, so there's no need for the server to poll. > Instead, it notifies the > app that there's still data remaining to be read next time it reads from > the socket (this is what the "check whether condition is satisfied > already" case in sock_reselect does, it explicitly does a poll even if the > socket is removed from the main polling loop, in order to check for > remaining data). Hmm - this code went away with CVS version 1.28 of sock.c. Perhaps we need to reintroduce it somehow. > Sending the app new FD_READ events only after it has read > old data is a documented Windows feature; further FD_READ events are held > back until the app reads old data, and this is what the wineserver > implements, especially in the POLLHUP case. Sorry, I cannot see what you are talking about, not in the current CVS version. All that happens after a read() is issued is _enable_event (FD_READ, 0, 0), and that clears the pending mask for FD_READ. How would that ever be set again, and FD_READ signalled ? (Consider an app that does not read _all_ remaining data after FD_CLOSE but only part of it and then issues further asynchronous read()s). The key probably is that sock_poll_event() was called from sock_reselect() if the "condition is satisfied", which is no longer the case in 1.28. Thanks for replying anyway, Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

April 17, 2002

Additional warnings (-W) revisited

by Joerg Mayer

Hello, a year or more ago I started an attempt to turn on additional warnings with gccs -W switch. The amount of additional warnings created made any warnings useless (the current count is >2700). I've just thought about the problem again and come up with a divide and conquer approach: Why not turn -W on and disable the additional warnings on a per directory basis? The idea is to turn on the additional warnings and then disable them on a per directory/type basis by putting a file into each directory turning off one or both of the additional warnings that occur very often (signed/unsigned comparisons and unused parameters/variables). If both warnings should be shown in a directory, the file may be removed. I've attached an example patch and the initial look of the .nowarn file. What do you think of the idea in general and this particular solution? Ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

April 16, 2002

Re: Urgent need for advice: POLLHUP and sockets

by Ove Kaaven

On Tue, 16 Apr 2002, Martin Wilck wrote: > please consider the following problem: Sounds like one we've discussed and resolved before. > On sockets, when POLLHUP is received, it is perfectly legitimate to > continue reading data until a read() or recv() call returns 0 bytes. Yes, it's still valid to read, but no more data will arrive on the socket, so the only thing you'll read is data that's already waiting in the kernel buffers. There's no reason to continue actively polling. > The current wine implementation calls set_select_events( &sock->obj, -1 ) > when POLLHUP or POLLERR is received, disabling any future events from the > socket. Yes. POLLHUP cannot be masked out, so letting the socket continue to be polled results in a busy-wait and 100% CPU usage. > However, if an application uses asynchronous IO (or only asynchronous > notification via WSAAsyncSelect() or WSAEventSelect()), this also inhibits > reception of POLLIN events which can perfectly well occur if there are > still unread data in the kernel buffers. Thus the app will never notice > that there is still data to be read. Not quite. No more data will arrive on the socket when it's in POLLHUP state, so there's no need for the server to poll. Instead, it notifies the app that there's still data remaining to be read next time it reads from the socket (this is what the "check whether condition is satisfied already" case in sock_reselect does, it explicitly does a poll even if the socket is removed from the main polling loop, in order to check for remaining data). Sending the app new FD_READ events only after it has read old data is a documented Windows feature; further FD_READ events are held back until the app reads old data, and this is what the wineserver implements, especially in the POLLHUP case. > A minor point is that sock_poll_event() also sets a FD_CLOSE event > (if present) everytime it is called with POLLHUP set, effectively > preventing any APC from being called, at least if the app waits for > FD_CLOSE and asynchronous send/recv operations at the same time (likely). > This can be worked around by setting FD_CLOSE only once and then blocking > it, although I am not sure if that is correct behaviour (permanently > signalling FD_CLOSE is obviously incorrect). The FD_CLOSE is only sent when there's no remaining data to be read (POLLIN is not present in the result of poll). It should not be a problem since the set_select_events( &sock->obj, -1 ) removes the socket from the main poll loop, so no further FD_CLOSEs would be sent.

April 16, 2002

Re: Debugger looping busy

by Sylvain Petreolle

> some questions: > - do you use the wineconsole or directly from the > Unix console I run it directly from the Unix console. > - was winedbg started from an exception or from the > command line from an exception > - did you try to redirect input and/or output to > some files no, was the direct output on the Unix console. Redirect as >stdout_log 2>stderr_log gives the same messages in the file stderr_log. > > (sounds like an error in reading the input stream, > which doesn't > seem to be correctly set up) > > A+ > ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

April 16, 2002

Re: Debugger looping busy

by Eric Pouech

Sylvain Petreolle a écrit : > > Hi, > > Using some programs with wine (last CVS), > the debugger enters a loop and cannot be > stopped other way than a kill on it. > > If I let it go, i see pages of these : > Wine-dbg>parse error some questions: - do you use the wineconsole or directly from the Unix console - was winedbg started from an exception or from the command line - did you try to redirect input and/or output to some files (sounds like an error in reading the input stream, which doesn't seem to be correctly set up) A+

April 16, 2002

Debugger looping busy

by Sylvain Petreolle

Hi, Using some programs with wine (last CVS), the debugger enters a loop and cannot be stopped other way than a kill on it. If I let it go, i see pages of these : Wine-dbg>parse error Cannot pass on last chance exception. You must use cont Wine-dbg>parse error Cannot pass on last chance exception. You must use cont Wine-dbg>parse error Cannot pass on last chance exception. You must use cont Had someone the same behaviour ? RH 7.2, kernel 2.4.9-31, glibc-2.2.4-24 ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

April 16, 2002

Re: Sorry for spamming wine bugs list

by Jeremy Newman

Hmmm, that is an issue isn't it. Can you enter that as a bug for Bugzilla itself. There should be a category for it. I'll see if I can update Bugzilla so it does not spam the list like that. Thanks for pointing it out. On Tue, 2002-04-16 at 13:56, Andriy Palamarchuk wrote: > I just changed a dependency of some task list bug and > a message was sent to the wine bugs list for each > entry in the task list. > Probably we need better filter for notifications which > sent to the bugs list. > > Andriy Palamarchuk -- __ _WebGeek/NetAdmin CodeWeavers -= http://www.codeweavers.com | \| |_____ __ ___ __ __ _ _ _ -= http://www.dracowulf.com | .` / -_) | | / ' \/ _` | ' \ -= mailto:jnewman(a)codeweavers.com |_|\_\___|\_/\_/|_|_|_\__,_|_||_| -= ICQ: 1842980 Yahoo: laxdragon

April 16, 2002

Re: fixme:win32:PeekNamedPipe

by Mike McCormack

Hi Michael's, Implementing PeekNamedPipe will probably be difficult to do properly. Named pipes work through unix domain sockets at the moment. The code is in dlls/ntdll/sync.c and server/named_pipe.c. (I was the one who wrote most of it.) Unfortunately I don't have time to work on this at the moment, but i can give you a few hints on how to procede. You might be able to use recvfrom with the MSG_PEEK flag to do it... Tell me how it goes... Mike Michael Cardenas wrote: > Michael Riedel wrote: > >> Thanks for the hint, and yes it is a kernel32 function. > > > ok, then there's some work to do. > >> fixme:win32:PeekNamedPipe (00000080, (nil), 00000000, (nil), >> 0x406a2194, (nil)): stub >> >> this means that at least a valid handle was created so that there is >> already some code for CreateNamedPipe or CreatePipe? > > > This means there's a stub. So, there's a placeholder with no code in it. > >> Is there anybody knowing more before I am going to try looking into >> the sources? > > > I'm not more knowing about this function per se, I'm sure whoever else > wrote the rest of the named pipe implementation will know. But I do know > that you can do this to find the stub, and possibly the file that has > the other named pipe functions: > > find (winesrcdir) -name *.c | xargs grep PeekNamedPipe >

April 16, 2002