[Bug 17195] NamedPipe datagrams need to be _really_ datagrams

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=17195

--- Comment #126 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> 2013-01-03 15:30:22 CST ---
(In reply to comment #125)
> (In reply to comment #123)
> > (In reply to comment #119)
> > > You can (and should) split it some more. Changing flush deserves its separate
> > > patch, and so does changing ioctl.
> > 
> > You mean split patch 5 more?
> 
> Yes. If some app breaks after your commits, you'll get a regression test
> pointing to one of them. The smaller that patch is, the better for you. Apps
> tend to break on good commits too, so even if you're sure everything is OK,
> splitting is always a good idea.

daniel: this is a... a... severely fundamental and critical functional patch
which should have been done a long, *long* time ago.  i'm staggered that
the NamedPipes functionality wasn't designed right from the start (and i mean
when the very first implementation of NamedPipes was ever conceived) to
be properly compliant with the NamedPipes specification.

how in hell's teeth's name wine got as far as it has without having proper
datagram support in NamedPipes is an absolute mystery.

the point is: as adam points out, this is very much an all-or-nothing patch.
if it works, it will "just work".  if it fails, it will fail so spectacularly
and so early that it will be blindingly f*****g obvious, it's *that*
fundamental.

NamedPipes are used at the absolute most fundamental level by the
infrastructure
of wine.  \PIPE\svcctl for example - to start even the very first services? 
registry access?  all done through named pipes (\PIPE\winreg).

if this patch didn't do its job, wine wouldn't work... period.

if with this patch you can start wine, it's called so many times even at the
very startup that that is, in its own way, its own test.

the patch is so fundamental to wine that not even the tests that i created
which test the functionality of this patch can be run unless the functionality
itself has been correctly implemented in the patch.

after startup, if there is even one single 3rd party program that fails because
of this patch, i would actually be more inclined to start any investigation
with that application more than i would investigate this patch as the cause.

i'm emphasising the same point in several different ways, but is it clear that
this is very much an all-or-nothing patch which either works 100% or fails
spectacularly 100%?

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.