Yes, I certainly understand Wine's position... Be it me, I would do some kind of a simple wrapper, OR, check why Wine's implementation of winsock is so slow.
So, it's hiding a bug in winsock implementation ;)
WBR, Aleksey.
On Nov 7, 2008, at 4:59 PM, Steven Edwards wrote:
On Fri, Nov 7, 2008 at 4:54 AM, Aleksey Bragin aleksey@reactos.org wrote:
I highly doubt they work, in fact I'm sure they won't work at all. But their only duty is to allow building unmodified rpcrt4 from Wine. I still have a hope, somewhere very very deep in my soul, that Wine will stop using linux-specific APIs in DLLs.
You can hope and dream.
One of the problems we saw, such as in the case of wininet, using unix sockets instead of winsock gave something like a 20% speedup in performance. Another issue was that select on linux (thanks to glibc) fixes FD_SETSIZE at 1024 so the solution was to move to using poll(). The poll/select thing is not that big of a deal as it can be wrapped but fixing the winsock performance issues may require someone to dedicate a lot of time profiling. If you can fix all of the issues so that performance will be the same with pure win32, then I am sure Alexandre will accept it.
-- Steven Edwards
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev