First of all I want to thank the community for the efforts spent in
developing wine. It's simple a cool tool (sorry, it's more, I know).
Now my problem: I installed wine-20020411 without having a native
windows installation. I installed successfully a simulator software
which obviously uses a
Try searching for PeekNamedPipe on msdn.microsoft.com and at the bottom it
will tell you what dll the function is in.
unfortunately, if it's in the kernel, you won't be able to use a native dll.
On Tuesday 16 April 2002 03:40 am, Michael Riedel wrote:
First of all I want to thank the
Thanks for the hint, and yes it is a kernel32 function.
BOOL PeekNamedPipe(
HANDLE hNamedPipe, // handle to pipe
LPVOID lpBuffer,// data buffer
DWORD nBufferSize, // size of data buffer
LPDWORD lpBytesRead,// number of bytes read
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 (0080, (nil), , (nil),
0x406a2194, (nil)): stub
this means that at least a valid handle was created so that there is
already some code
Hi all,
please consider the following problem:
On sockets, when POLLHUP is received, it is perfectly legitimate to
continue reading data until a read() or recv() call returns 0 bytes.
The current wine implementation calls set_select_events( sock-obj, -1 )
when POLLHUP or POLLERR is received,
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
__
Do You Yahoo!?
Martin Wilck wrote:
My first reaction to this was to comment out the above call to
set_select_events() and continue listening to events from the socket.
However, due to the semantics of poll(), this will cause a POLLHUP event
on this socket for each and every iteration of the wineserver's main
On Tue, 16 Apr 2002, Michael Cardenas wrote:
Could you use the set_select_events to say that you don't want any more
POLLHUP events?
No you can't - that's how poll() works (at least on Linux).
man poll
int poll(struct pollfd *ufds, unsigned int nfds, int timeout);
[...]
The field revents
I just might remark that with the two changes I discussed in the previous
message (do not call set_select_events (..., -1), signal FD_CLOSE only
once) I seem to finally get rid of the problems with the
close()/shutdown() semantics that I talked about before.
But only at the cost of very high
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
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
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-dbgparse error
Cannot pass on last chance exception. You must use
cont
Wine-dbgparse error
Cannot pass on last chance
My first reaction to this was to comment out the above call to
set_select_events() and continue listening to events from the socket.
However, due to the semantics of poll(), this will cause a POLLHUP event
on this socket for each and every iteration of the wineserver's main select
loop,
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-dbgparse error
some questions:
- do you use the wineconsole or directly from the Unix
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
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
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
17 matches
Mail list logo
