Erich Hoover ehoo...@mines.edu writes:
Maybe I'm missing something, but the only case I found that required extra
wineserver work was for handling asynchronous ReadFile requests (since these
requests don't go through the ws2_32 path, see patch 6). Using ReadFile
like that is technically
On Saturday 10 October 2009 01:15:17 Juan Lang wrote:
Hi Eric,
it seems to me that if this is the best we can do, we're fixing it at
the wrong layer. Surely putting the fix in the Linux kernel would be
much smaller in code size, and higher performing, as we wouldn't have
to filter packets
Erich Hoover ehoo...@mines.edu writes:
The maintainer has pretty much put his foot down on the matter (several
times actually, here's a nicer one):
http://www.mail-archive.com/linux-...@vger.kernel.org/msg01306.html
This is rather embarrasing, but apparently I left server/protocol.def out of
2009/10/9 Erich Hoover ehoo...@mines.edu:
I've been a bit busy lately, but I sent in a patchset at the end of
September to fix the CC3 LAN networking bug. If I could get some feedback
on these patches then I would greatly appreciate it:
Maybe I'm missing something, but the only case I found that required extra
wineserver work was for handling asynchronous ReadFile requests (since these
requests don't go through the ws2_32 path, see patch 6). Using ReadFile
like that is technically something you're not supposed to do, but we all
I've been a bit busy lately, but I sent in a patchset at the end of
September to fix the CC3 LAN networking bug. If I could get some feedback
on these patches then I would greatly appreciate it:
http://www.winehq.org/pipermail/wine-patches/2009-September/079193.html[1/6]
Hi Eric,
it seems to me that if this is the best we can do, we're fixing it at
the wrong layer. Surely putting the fix in the Linux kernel would be
much smaller in code size, and higher performing, as we wouldn't have
to filter packets in user space.
--Juan
On Fri, Oct 9, 2009 at 5:15 PM, Juan Lang juan.l...@gmail.com wrote:
Hi Eric,
it seems to me that if this is the best we can do, we're fixing it at
the wrong layer. Surely putting the fix in the Linux kernel would be
much smaller in code size, and higher performing, as we wouldn't have
to
This is rather embarrasing, but apparently I left server/protocol.def out of
the patchset. I could have sworn I tested these patches on a clean git, but
apparently I made a mistake. Is there any chance that this mistake is the
reason for the rejection?
It very well could be, but you'll have
