Re: fixme:win32:PeekNamedPipe

[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/

Bugzilla bug 297: implement PeekNamedPipe.

[David Jolley]

* Andriy Palamarchuk ([e-mail]) wrote:
> If anybody starts to work on the bug, please take this
> bug and keep it updated.

Hi all,

Newbie developer alert!

I've been meaning to do something with this bug for a while now, as it
seriously cripples my killer-app that's keeping me running Windows.

Basically, I've had a look through the sources, and found out what
I've got to do with the dll/server communication (I think!).  I've
fleshed out the PeekNamedPipe API Handler call (peek_named_pipe() in
dlls/kernel/sync.c) to do a SERVER_REQUEST, and put in what I think
needs putting in the server to handle said request
(server/protocol.def has been modified with the requisite structure).

Now, the problem I have is that the peek_named_pipe function that gets
called inside the server (declared with a DECL_HANDLER) seems from the
name (and it's associated function group too) that it's implementation
should be in the file server/named_pipe.c, but it seems to me that
this handler is more like a file read operation, and the other
handlers in server/named_pipe.c are more to do with the housekeeping  
of a pipe.

My question is, then, should the server's implementation of
peek_named_pipe go in named_pipe.c, or somewhere else (where?).

Also, PeekNamedPipe has two types of call - one where the call is
returning the data ahead of a read, and one where it just returns the
amount of bytes waiting.  My program only uses one of these types; the
"return amount of data waiting" type, and so I have no way of knowing
if I've implemented the "returns data" type of call correctly.  This
means there's still a FIXME in one branch - does this make any patch
I'd submit unnacceptable?

Cheers,

Dave.