You can duplicate a pipe handle with DuplicateHandle, make it inheritable and share it
between processes similar
to many other handles
On Sunday 04 January 2004 03:33 pm, Juan Lang wrote:
> --- Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> > You have to do inter-process synchronization, pipe
>
--- Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> You have to do inter-process synchronization, pipe
> handles can be
> shared between processes. I don't see how you can do
> that without
> putting everything into the wine server, which is
> the same as putting
> it into the kernel except with a
Juan Lang <[EMAIL PROTECTED]> writes:
> Again, why? The named pipe server has to support
> multiple accesses, so multiple processes can create
> unique connections to the same pipe, and let the
> server worry about concurrency. Even if that weren't
> the case, using a synchronization object and
--- Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> In the remote case, what we need is for the kernel
> to manage the whole
> protocol, so that we can do read() and write() calls
> as if it were a
> normal socket. You cannot manage the protocol in the
> client process,
> it breaks down as soon as
Juan Lang <[EMAIL PROTECTED]> writes:
> I'm still not getting it. Those two SMBs are SMBtrans
> SMBs, a single request and (typically) a single
> response. My NetShareEnum and NetServerEnum functions
> also use SMBtrans. What's hard? What does the kernel
> do for us that makes it easier?
Sett
--- Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> > The named pipe state can be queried via the
> > QNmPHandState SMB and changed via the
> SetNmPHandState
> > SMB. See the X/Open IPC mechanisms for SMB, p114
> and
> > p116 (
>
>
> Sure, if you already have SMB named pipes, then
> implementing
Juan Lang <[EMAIL PROTECTED]> writes:
> The named pipe state can be queried via the
> QNmPHandState SMB and changed via the SetNmPHandState
> SMB. See the X/Open IPC mechanisms for SMB, p114 and
> p116 (
> http://www.opengroup.org/products/publications/catalog/c195.htm
> )
Sure, if you already h
--- Dan Kegel <[EMAIL PROTECTED]> wrote:
> My goodness. I didn't know that document existed.
> Thanks for
> the link! Is there a complete list anywhere of
> Win32 APIs
> that have been documented by opengroup.org?
My pleasure. Don't know of one, but check out the
references section of Chris He
--- Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> Juan Lang <[EMAIL PROTECTED]> writes:
>
> > Why? What problems will we run into if we don't?
> It
> > may be clear to you, but it isn't to me.
>
> Mike can probably give you more details, but there
> are some features
> that cannot be supporte
Juan Lang <[EMAIL PROTECTED]> writes:
> Why? What problems will we run into if we don't? It
> may be clear to you, but it isn't to me.
Mike can probably give you more details, but there are some features
that cannot be supported on standard socket pairs, for instance
switching between byte and
On Saturday 03 January 2004 05:13 pm, Juan Lang wrote:
> having RPC be able to talk to a
> remote RPC server (running on Windows) ...
> That requires named pipes.
or tcp support
-gmt
--- Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> > discover RPC bugs. That requires named pipes. Do
> > they have to upgrade their kernel for that, too?
>
> Most likely yes. In fact we'll probably need some
> kernel support even
> for local named pipes.
Why? What problems will we run into i
Juan Lang <[EMAIL PROTECTED]> writes:
> Yeah, but what about RPC? Maybe all the RPC bugs in
> Wine are well known and people just don't want to work
> on them, but I figured having RPC be able to talk to a
> remote RPC server (running on Windows) would help
> discover RPC bugs. That requires nam
On Sat, 2004-01-03 at 23:13, Juan Lang wrote:
> Yeah, but what about RPC? Maybe all the RPC bugs in
> Wine are well known and people just don't want to work
> on them, but I figured having RPC be able to talk to a
> remote RPC server (running on Windows) would help
> discover RPC bugs. That requi
--- Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> I think it's reasonable to require people who want
> SMB file access to
> upgrade their kernel. It's not like it's a widely
> requested feature,
> we haven't had it for 10 years and nobody
> complained...
Yeah, but what about RPC? Maybe all the
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> Of course this stuff should be in the kernel (ideally, we should get
> the entire wine server in the kernel :)), but what about a fallback
> for boxes that don't have that in there? Even if we do the work now
> (to push things into the kernel), it w
On January 3, 2004 01:35 pm, Alexandre Julliard wrote:
> Oops, I agree this is confusing. In this case I mean the Linux kernel,
> this stuff cannot be done efficiently in user space.
Of course this stuff should be in the kernel (ideally, we should get
the entire wine server in the kernel :)), but
Eric Pouech <[EMAIL PROTECTED]> writes:
> when you write kernel, do you mean kernel32 or the kernel32/ntdll pair ?
> (IMO, it should rather be in ntdll)
Oops, I agree this is confusing. In this case I mean the Linux kernel,
this stuff cannot be done efficiently in user space.
--
Alexandre Julli
They should go in the kernel too. Anything that does I/O needs to be
there, because it can't be done reliably in the client process, and it
can't be done efficiently in the wine server.
Alexandre,
when you write kernel, do you mean kernel32 or the kernel32/ntdll pair ?
(IMO, it should rather be in
Juan Lang <[EMAIL PROTECTED]> writes:
> File I/O, fine. But how about named pipes?
> Mailslots? They are implemented with nearly the same
> SMBs, and belong in kernel32 or ntdll. netapi32 needs
> 'em too, for these two functions.
They should go in the kernel too. Anything that does I/O needs
Juan Lang wrote:
File I/O, fine. But how about named pipes?
Mailslots? They are implemented with nearly the same
SMBs, and belong in kernel32 or ntdll. netapi32 needs
'em too, for these two functions.
I'm happy to work with you (or even do most of the work) to put named
pipes and mailslots in
--- Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> As I said already, IMO the file I/O stuff should go
> in the kernel. The
> current approach is broken, as you noted in your
> FIXMEs.
File I/O, fine. But how about named pipes?
Mailslots? They are implemented with nearly the same
SMBs, and bel
Juan Lang <[EMAIL PROTECTED]> writes:
> Yeah, that's why I emailed the list twice before
> asking how to go about it. Is making a static SMB
> library preferrable? I haven't yet discovered the
> interface MS uses to SMB (public or private), so I
> haven't been able to hide it in the real place.
--- Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> You can't share C files across dlls, this violates
> dll separation and it won't build properly.
Yeah, that's why I emailed the list twice before
asking how to go about it. Is making a static SMB
library preferrable? I haven't yet discovered th
Juan Lang <[EMAIL PROTECTED]> writes:
> Relies on previously submitted SMB patch,
> http://www.winehq.org/hypermail/wine-patches/2003/12/0231.html
>
> ChangeLog: partially implement NetServerEnum and
> NetShareEnum using RAP over SMB
You can't share C files across dlls, this violates dll separati
25 matches
Mail list logo
