On 8/25/2011 08:49, Bernhard Loos wrote:
---
dlls/ntdll/tests/pipe.c |2 +-
server/named_pipe.c |6 ++
2 files changed, 7 insertions(+), 1 deletions(-)
@@ -964,6 +964,12 @@ DECL_HANDLER(create_named_pipe)
struct unicode_str name;
struct directory *root = NULL;
+
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=13692
Your paranoid android
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=12804
Your paranoid android
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=12777
Your paranoid android
Hi Kai,
> However, Jeff Layton asked me about a use case, and I have to admit I can't
> think of one off the top of my head. So, what application do we have that
> fails to work due to the lack of remote named pipes?
I actually think the clearest use of remote named pipes is actual
Kai asked:
> Is there a use case for remote named pipes?
http://support.microsoft.com/kb/q238949/
shows that SQL Server supports named pipes as an
access method. Some apps or sites might assume that
works, and not be able to use TCP/IP for this.
Google finds at least three examples of peo
ve to admit I can't
think of one off the top of my head. So, what application do we have that
fails to work due to the lack of remote named pipes?
Cheers,
Kai
--
Kai Blin
WorldForge developer http://www.worldforge.org/
Wine developerhttp://wiki.winehq.org/KaiBlin
Samba team membe
-compliant system that intends to offer
interoperable "Windows NT Named Pipe Emulation".
the purpose of the document is to provide a guide to creating emulated
implementation of Windows NT Named Pipes. implementors could use this
to communicate between clients and servers inside their applicat
http://bugs.winehq.org/attachment.cgi?id=19477
* functionality of non-message-mode (byte type) is preserved.
* putting too many messages into the queue runs wineserver out of file
descriptors, but the solutions to that are too much work for this
revision, to be included, so - tough.
* research i
On Thu, Feb 5, 2009 at 6:38 PM, Juan Lang wrote:
>> and no, you _can't_ do "everything in wineserver", because you _still_
>> need a mechanism to be able to tell the client (ntdll) to "block".
>
> Well, if there are two fds still, but each end is either a client
> (reading or writing) and the othe
er.
> I guess I'm not that
> familiar with how reading from a socket works. I'd always assumed
> that the former was true, and that therefore the only correct approach
> would be to buffer message-mode named pipe data in the server.
"relax, luther - it's much worse
erver_get_unix_fd) each around "please start a new message"
and "please send some more read-data" would be sufficient.
what do you think?
also the advantage of double-socketing is that when it comes to doing
SMB named pipes there will be a clean "way in and out" for SM
ght direction.
Pointing out that handles can be shared between processes was a hint
about one fundamental flaw that can trip you up. I'll try to look at
what you're doing now and again to point out things that just can't
work. For the most part, though, I'll assume you know what you
> i think i've finally come up with an idea that i believe will work:
> double-socketing.
(snip)
> it'll be ok (and desirable) to allow multiple "readers" of the "read"
> socket. what you _don't_ want is more than one reader trying to
> indicate "please start sending a new message" whilst there are
> main process: blocking-read on namedpipe.
> 5 threads: write to same named pipe
>
> the writes NEVER return (this is with xp).
>
> so that WOULD indicate that there IS a per-pipe mutex (and that there
> are bugs in nt!)
unbelievable.
turns out it's an msvcrt bug (in windows nt). if you use
_
fascinatingly strange observation came out of writing the latest test
(threadwrites) to do namedpipe interoperability testing.
main process: blocking-read on namedpipe.
5 threads: write to same named pipe
the writes NEVER return (this is with xp).
so that WOULD indicate that there IS a per-pipe
Hi Luke,
> how about: ripping out the use of unix-pipes altogether, and replacing
> them with tdb (trivial database) in a mmap'd file? the nice thing
> about tdb is that it's LGPL'd. the messages could be saved and
> transferred via shared memory; tdb is multi-readable /
> multi-writeable, and i
mwhaaahahah, i just came up with a _horrible_ idea :)
how about: ripping out the use of unix-pipes altogether, and replacing
them with tdb (trivial database) in a mmap'd file? the nice thing
about tdb is that it's LGPL'd. the messages could be saved and
transferred via shared memory; tdb is mult
ok, alexandre: i tried moving named_pipe_read into wineserver - it's
not possible to do completely, as you cannot do blocking-reads in
wineserver but you still need blocking-read characteristics in the
client (kernel32, ntdll). if you start messing with the fd, setting
or clearing ioctl O_NONBLOCK
ISO FUSE file system integration
>
> Steven already took care of this part, so I'll wrap up the next one.
>
>
> > # A FUSE wrapper for remote named pipes using libsmbclient
>
> The goal of this is to be able to do RPC via Windows named pipes to remote
> machines. O
one.
> # A FUSE wrapper for remote named pipes using libsmbclient
The goal of this is to be able to do RPC via Windows named pipes to remote
machines. Of course the best solution would be to just use libsmbclient from
Wine directly, but libsmbclient is under the GPL and Wine is under the LGPL,
On Tue, Mar 25, 2008 at 9:24 PM, Cesar Izurieta <[EMAIL PROTECTED]> wrote:
> Besides the FUSE project for GSOC I see two items listed on the
> http://wiki.winehq.org/SummerOfCode page:
>
> # Better ISO FUSE file system integration
I don't know if the FUSE api supports enumeration of mounts in th
Besides the FUSE project for GSOC I see two items listed on the
http://wiki.winehq.org/SummerOfCode page:
# Better ISO FUSE file system integration
# A FUSE wrapper for remote named pipes using libsmbclient
Can anybody elaborate a little bit more on this?
On Monday 02 April 2007 02:02, Dan Kegel wrote:
> A user asked in
> http://groups.google.com/group/comp.emulators.ms-windows.wine/msg/06fbfdfb5
>3a28cbd whether Wine could communicate with remote
> machines via named pipes yet (he needs it to
> talk with an SQLServer box).
>
&g
A user asked in
http://groups.google.com/group/comp.emulators.ms-windows.wine/msg/06fbfdfb53a28cbd
whether Wine could communicate with remote
machines via named pipes yet (he needs it to
talk with an SQLServer box).
I know Alexandre's been poking around in that area, but
I think he's
Robert Shearman wrote:
> Thomas Weidenmueller wrote:
> If what you say is true about the PIPE_NOWAIT flag affecting this then
> it should be easy to fix.
The PIPE_NOWAIT flag is documented in the PSDK. In fact, named pipes are
handled slightly differently in ReadFile/WriteFile. Even if
Created the named pipes with the FILE_FLAG_OVERLAPPED flag, otherwise
the call to ConnectNamedPipe() will block the server thread if no
connection can be established, which causes the rpc server to dead-lock
during startup.
- Thomas
Index: dlls/rpcrt4/rpc_binding.c
Thomas Weidenmueller wrote:
Robert Shearman wrote:
I have a patch that converts rpcrt4 over to using overlapped I/O, but I
didn't submit it because the performance on Wine is horrible. When using
overlapped I/O we have to perform several more server calls than when
using non-overlapped I/O.
Robert Shearman wrote:
> I have a patch that converts rpcrt4 over to using overlapped I/O, but I
> didn't submit it because the performance on Wine is horrible. When using
> overlapped I/O we have to perform several more server calls than when
> using non-overlapped I/O. Also, I think that this pat
Thomas Weidenmueller wrote:
Created the named pipes with the FILE_FLAG_OVERLAPPED flag, otherwise
the call to ConnectNamedPipe() will block the server thread if no
connection can be established, which causes the rpc server to dead-lock
during startup.
Hi Thomas,
I have a patch that
Oops...this meant to go to wine-patches
Sorry about that.
- Thomas
Created the named pipes with the FILE_FLAG_OVERLAPPED flag, otherwise
the call to ConnectNamedPipe() will block the server thread if no
connection can be established, which causes the rpc server to dead-lock
during startup.
- Thomas
--
P.S.: Please let me know if there's something wrong
aking sure
that overlapped I/O on named pipes works now and making sure it works in
the future. Just to put your mind at ease about the first, I put it
through a very heavy work-out by converting rpcrt4 to use overlapped I/O
on named pipes instead of synchronous I/O. This would have provided a
> "Robert" == Robert Shearman <[EMAIL PROTECTED]> writes:
Robert> Hi, This patch depends on "Small RPC Bug Fixes" for the ole32
Robert> tests to pass.
I hope people don't think of me as a PITA, but here again my RFT (Request
for Tests):
Rob, can you please add a testcase in dlls/ker
On Wed, 28 Jan 2004 13:04:44 +, Peter Riocreux wrote:
> warn:ole:create_marshalled_proxy Could not open named pipe to broker
> \\.\pipe\{46A9F31C-E868-11D4-8BC9-000102A831DC}, le is 2
> [last message repeated indefinitely]
Hi,
Install native DCOM (see #winehq channel faq), then run with
WIN
repeated indefinitely]
Hi Peter,
This is a problem with OLE32, not with named pipes. The interprocess
marshalling code in Wine's OLE32 implementation is not yet complete...
Mike
Uwe Bonnes <[EMAIL PROTECTED]> writes:
> > "Peter" == Peter Riocreux <[EMAIL PROTECTED]> writes:
>
> Peter> "Robert Shearman" <[EMAIL PROTECTED]> writes:
> >> > warn:heap:HEAP_ValidateInUseArena Heap 4022: invalid in-use >
> >> arena magic for 402576a0
> >>
> >> Worry
n named pipe to broker
> > \\.\pipe\{46A9F31C-E868-11D4-8BC9-000102A831DC}, le is 2
> > [last message repeated indefinitely]
> This is a problem with OLE32, not with named pipes. The interprocess
> marshalling code in Wine's OLE32 implementation is not yet complete...
> "Peter" == Peter Riocreux <[EMAIL PROTECTED]> writes:
Peter> "Robert Shearman" <[EMAIL PROTECTED]> writes:
>> > warn:heap:HEAP_ValidateInUseArena Heap 4022: invalid in-use >
>> arena magic for 402576a0
>>
>> Worrying, but your program hasn't crashed so shouldn't be a
"Robert Shearman" <[EMAIL PROTECTED]> writes:
> > warn:heap:HEAP_ValidateInUseArena Heap 4022: invalid in-use
> > arena magic for 402576a0
>
> Worrying, but your program hasn't crashed so shouldn't be a problem.
Well the thing that I *think* should be on the other end of the pipe
crashes wit
>
>
> The management software (binary called pm5.exe) installed fairly
> easily and gets a long way in on execution but then stops making
> progress. It consumes pretty much all the CPU and when run with debug
> messages printed I get the following:
>
> fixme:ole:CoRegisterMessageFilter stub
Shoul
[reposted because I posted not from the subscribed address - Doh!
Sorry if you see it twice in the end]
Using the RH9 RPM from the SF downloads area (wine-20040121-1rh9winehq.i686.rpm)
This is my first serious attempt at getting a non-working app working,
so if I am giving insufficient, or the wr
On Sun, 2003-10-19 at 21:22, Alexandre Julliard wrote:
> Daniel Marmier <[EMAIL PROTECTED]> writes:
>
> > Are you talking about support for TLS in wine?
> > If so, is that already assigned?
>
> No, the problem is TLS support in glibc itself, since that bypasses
> our pthread wrappers. We don't ne
On Mon, 2003-10-20 at 00:19, Gregory M. Turner wrote:
> cool trick. an ironic side-note (I have not tried this on my without-nptl
> system yet, so the following is not relevant to my problem): on my nptl
> system (the one that works now), I get:
>
> # /lib/libc-2.3.2.so
> Inconsistency detected
On Sunday 19 October 2003 05:20 am, Mike Hearn wrote:
> On Sun, 19 Oct 2003 01:00:51 -0500, Sir Gregory M. Turner scribed thus:
> > which ostensibly would seem to contradict your prognosis... (although I
> > assume you are nevertheless correct -- this is not the root-dir
> > configure, so maybe it'
Daniel Marmier <[EMAIL PROTECTED]> writes:
> Are you talking about support for TLS in wine?
> If so, is that already assigned?
No, the problem is TLS support in glibc itself, since that bypasses
our pthread wrappers. We don't need to use glibc-style TLS in Wine
since we can use the Win32 TLS supp
On Sun, 19 Oct 2003 01:00:51 -0500, Sir Gregory M. Turner scribed thus:
> which ostensibly would seem to contradict your prognosis... (although I assume
> you are nevertheless correct -- this is not the root-dir configure, so maybe
> it's misleading me. I will poke at it again to see what gentoo
On Sat, 2003-10-18 at 19:38, Alexandre Julliard wrote:
> Mike Hearn <[EMAIL PROTECTED]> writes:
>
> > Alexandre - this is your area. Any ideas?
>
> Your glibc is using TLS. Support for that is not ready yet. Depending
> on your system you need to either set LD_ASSUME_KERNEL=2.4 or install
> anoth
On Saturday 18 October 2003 12:38 pm, Alexandre Julliard wrote:
> Mike Hearn <[EMAIL PROTECTED]> writes:
> > Alexandre - this is your area. Any ideas?
>
> Your glibc is using TLS. Support for that is not ready yet. Depending
> on your system you need to either set LD_ASSUME_KERNEL=2.4 or install
>
Mike Hearn <[EMAIL PROTECTED]> writes:
> Alexandre - this is your area. Any ideas?
Your glibc is using TLS. Support for that is not ready yet. Depending
on your system you need to either set LD_ASSUME_KERNEL=2.4 or install
another glibc that doesn't use TLS.
--
Alexandre Julliard
[EMAIL PROTECT
On Fri, 17 Oct 2003 16:20:04 -0500, Sir Gregory M. Turner scribed thus:
> Does everybody's kernel32 named pipes test pass (in wine)? Named pipes are
> acting very wierd here, lots of segfaults and other wierdness... the test
> seems to freeze attempting to create the
Does everybody's kernel32 named pipes test pass (in wine)? Named pipes are
acting very wierd here, lots of segfaults and other wierdness... the test
seems to freeze attempting to create the alarmThread in test_NamedPipe_2
(test 3 of 4). The wineserver holds up OK, but the client side lo
Notice that the number of bytes available in each Peek corresponds
exactly with the number that were written in each individual write. What
should be happening of course is that the total number of bytes should
have been reported in the first peek.
I made some further tests and basically FIONREA
> "Eric" == Eric Pouech <[EMAIL PROTECTED]> writes:
>> Nope ;) I think there was a problem when you tried to attach that :-)
Eric> oops (took the file from the wrong dir...)
Sorry for not coming back earlier. I was drouned in work...
No, the patch doesn't help :-(
Project navigator
54 matches
Mail list logo
