September 2006 - Wine-Devel

Re: Governance revisited
by jimtabor Sept. 26, 2006

Sept. 26, 2006

Wow, just like that! James Hawkins wrote: >> It is shocking to most FOSS code writers that maybe this is a real, >> truly, paid for project. "No! It can not be! I contribute to someones >> profit? NOOoooooooo~~~!". > The above is a famous quote I read from Linux Journal magazine. > > I am well aware that Codeweavers funds most of Wine development, and I > appreciate every bit of support coming from them, but this project > would continue even without their support. > > -- > James Hawkins > >> NO! You are WRONG, sir! >> NOOoooooooo~~~! > > > P.S. You should really calm down. It's hard to take you seriously > when you act immature. > I am calm, lol! immature? just a little! 8^D So, after reading this ML for years and assessing. Seriously, If I was a contractor representative researching code weavers ability to support their product, the last thing I would expect from any of their developers would be the lack of customer support and poor attitude on IRC. At lest if one of my employees does go out and join wine IRC, I would hope they will not get kicked or banned for asking to many questions. Understanding this, has made my mind up and forced to stop linux migration due to the lack of support and maturity of wine and code weavers. We do have contracts with Red Hat, SCO, Solaris, Raytheon,,,,, Oh the shock of that, yes we are considering the use of wine for moving away from Microsoft windows. Wine was the stop gap in our mission to provide both Linux and Window applications in a real time environment. That M$ update thingy is a ass kicker on real time systems, that must operate 24/7. Having said that,,,, sorry I can't authorize any contracts with code weavers. Sorry, you just never know sometime, James

1 0

make test failing in shell32
by Kai Blin Sept. 25, 2006

Sept. 25, 2006

Hi folks, running make test repeatedly in a new wine prefix finally gives this error: make[2]: Entering directory `/home/nowhere/dev/wine/wine-build/dlls/shell32/tests' ../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p shell32_test.exe.so shlfileop.c && touch shlfileop.ok shlfileop.c:168: Test failed: The requested file does not exist, ret=3 I've attached the +shell trace bzip2ed, the uncompressed trace is 2.2 megs. Cheers, Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

1 0

Re: [RPCRT4] support for RPC TCP servers
by Robert Shearman Sept. 25, 2006

Sept. 25, 2006

Damjan Jovanovic wrote: > Changelog: > * Makes RPCRT4 use Winsock2 instead of native sockets (needed for > event object support) > * Adds support for TCP (ncacn_ip_tcp protocol) servers I appreciate your attempt at solving this hard problem, but I don't believe this is the right approach. Using winsock2 instead of Unix sockets adds overhead in terms of wineserver calls and extra processing time to mangle arguments, which we shouldn't need. The reasoning for this is that at some point I want to use Unix domain sockets for the ncalrpc provider, so it should be as fast as possible. More detailed comments inline: > > --- a/include/ws2tcpip.h 2006-08-28 20:35:33.000000000 +0200 > +++ b/include/ws2tcpip.h 2006-09-16 08:55:45.000000000 +0200 > @@ -137,6 +137,8 @@ > #define WS_IFF_MULTICAST 0x00000010 /* multicast is supported */ > #endif /* USE_WS_PREFIX */ > > +#define INET_ADDRSTRLEN 16 > + > #ifndef USE_WS_PREFIX > #define IP_OPTIONS 1 > #define IP_HDRINCL 2 > This change looks good. Please submit it separately. > +static const char *gai_strerror(int errcode) > +{ > + switch (errcode) > + { > + case EAI_AGAIN: return "Temporary failure in name resolution"; > + case EAI_BADFLAGS: return "Bad value for ai_flags"; > + case EAI_FAIL: return "Non-recoverable failure in name resolution"; > + case EAI_FAMILY: return "ai_family not supported"; > + case EAI_MEMORY: return "Memory allocation failure"; > + case EAI_NONAME: return "Name or service not known"; > + case EAI_SERVICE: return "Servname not supported for ai_socktype"; > + case EAI_SOCKTYPE: return "ai_socktype not supported"; > + } > + return "Unknown error"; > +} > + > +static const char *inet_ntop(int af, const void *src, char *dst, int cnt) > +{ > + if (af == AF_INET) > + { > + unsigned int addr = * (unsigned int*) src; > + if (cnt < INET_ADDRSTRLEN) > + return NULL; > + snprintf(dst, cnt, "%u.%u.%u.%u", (addr >> 24) & 0xFF, > + (addr >> 16) & 0xFF, (addr >> 8) & 0xFF, addr & 0xFF); > + return dst; > + } > + else > + return NULL; > +} > + > These should obviously not be here. I believe gai_strerror is implemented as a macro in one of the winsock header files. I think inet_ntop should be implemented in ws2_32.dll. > @@ -506,51 +516,115 @@ > continue; > } > > - if (0>connect(sock, ai_cur->ai_addr, ai_cur->ai_addrlen)) > + if (Connection->server) > { > - WARN("connect() failed\n"); > - close(sock); > - continue; > + BOOL success = FALSE; > + if (bind(sock, ai_cur->ai_addr, ai_cur->ai_addrlen) == 0) > + { > + if (listen(sock, 5) == 0) > + { > + if ((tcpc->event = WSACreateEvent()) != NULL) > + { > + if (WSAEventSelect(sock, tcpc->event, FD_ACCEPT) == 0) > + success = TRUE; > + else > + WARN("WSAEventSelect() failed\n"); > Using WSAEVENTs is an interesting approach, but I'd rather see Unix sockets being used with a thread that select's on the socket and sets a Win32 event instead. Also, I think this amount of nesting is confusing and could be avoided. > > static int rpcrt4_conn_tcp_read(RpcConnection *Connection, > void *buffer, unsigned int count) > { > RpcConnection_tcp *tcpc = (RpcConnection_tcp *) Connection; > - int r = recv(tcpc->sock, buffer, count, MSG_WAITALL); > - TRACE("%d %p %u -> %d\n", tcpc->sock, buffer, count, r); > - return r; > + int rtotal = 0; > + int r = 0; > + do > + { > + r = recv(tcpc->sock, buffer, count, 0); > + if (r > 0) > + rtotal += r; > + else > + break; > + } while (rtotal < count); > + if (r < 0) > + rtotal = r; > + TRACE("%d %p %u -> %d\n", tcpc->sock, buffer, count, rtotal); > + return rtotal; > } > Hmmm. Is the MSG_WAITALL flag not supported in winsock? I think that should be fixed there. > > static int rpcrt4_conn_tcp_write(RpcConnection *Connection, > const void *buffer, unsigned int count) > { > RpcConnection_tcp *tcpc = (RpcConnection_tcp *) Connection; > - int r = write(tcpc->sock, buffer, count); > + int r = send(tcpc->sock, buffer, count, 0); > TRACE("%d %p %u -> %d\n", tcpc->sock, buffer, count, r); > return r; > } > This is a good change. Please submit this as a separate fix. Thanks, -- Rob Shearman

3 3

Re: [RPCRT4] support for RPC TCP servers
by Robert Shearman Sept. 25, 2006

Sept. 25, 2006

Damjan Jovanovic wrote: > On 9/22/06, Robert Shearman <rob(a)codeweavers.com> wrote: >> Using WSAEVENTs is an interesting approach, but I'd rather see Unix >> sockets being used with a thread that select's on the socket and sets a >> Win32 event instead. Also, I think this amount of nesting is confusing >> and could be avoided. > > Are you working on that approach, or am I free to try it? No, I am not working on that so you are free to try it. (You would be free to try it anyway, since your implementation might be better than an implementation I was working on.) > >> > >> > static int rpcrt4_conn_tcp_read(RpcConnection *Connection, >> > void *buffer, unsigned int count) >> > { >> > RpcConnection_tcp *tcpc = (RpcConnection_tcp *) Connection; >> > - int r = recv(tcpc->sock, buffer, count, MSG_WAITALL); >> > - TRACE("%d %p %u -> %d\n", tcpc->sock, buffer, count, r); >> > - return r; >> > + int rtotal = 0; >> > + int r = 0; >> > + do >> > + { >> > + r = recv(tcpc->sock, buffer, count, 0); >> > + if (r > 0) >> > + rtotal += r; >> > + else >> > + break; >> > + } while (rtotal < count); >> > + if (r < 0) >> > + rtotal = r; >> > + TRACE("%d %p %u -> %d\n", tcpc->sock, buffer, count, rtotal); >> > + return rtotal; >> > } >> > >> >> Hmmm. Is the MSG_WAITALL flag not supported in winsock? I think that >> should be fixed there. > > It isn't supported in the native winsock either. You think too highly > of winsock - remeber it was made by Microsoft ;-). Both MSDN and dlls/ws2_32/socket.c suggest that it is supported, although only in non-blocking mode. Is that the problem? > >> > >> > static int rpcrt4_conn_tcp_write(RpcConnection *Connection, >> > const void *buffer, unsigned int >> count) >> > { >> > RpcConnection_tcp *tcpc = (RpcConnection_tcp *) Connection; >> > - int r = write(tcpc->sock, buffer, count); >> > + int r = send(tcpc->sock, buffer, count, 0); >> > TRACE("%d %p %u -> %d\n", tcpc->sock, buffer, count, r); >> > return r; >> > } >> > >> >> This is a good change. Please submit this as a separate fix. > > But if we use UNIX sockets, it shouldn't matter? Correct. This won't make any difference either way, so we should use send. -- Rob Shearman

1 0

Re: kernel32: Remove unwanted null terminator
by Alexandre Julliard Sept. 25, 2006

Sept. 25, 2006

Andrew Talbot <Andrew.Talbot(a)talbotville.com> writes: > Changelog: > kernel32: Remove unwanted null terminator. There's no null terminator since the array size is specified explicitly. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: dmime: Dangling references fix
by Alexandre Julliard Sept. 25, 2006

Sept. 25, 2006

Andrew Talbot <Andrew.Talbot(a)talbotville.com> writes: > Changelog: > dmime: Dangling references fix. The right way is to use wine_dbg_sprintf("%s") to allocate a copy of the buffer to return. -- Alexandre Julliard julliard(a)winehq.org

1 0

Wine translations statistics
by Mikołaj Zalewski Sept. 25, 2006

Sept. 25, 2006

To check what needs to be translated I have played a bit with wrc --verify-translation and made some HTML from it's results. As this might interest other translators I've put the statistics at http://pf128.krakow.sdi.tpnet.pl/wine-transl/ . Mikolaj Zalewski

6 7

Re: wined3d: fix typo in ResourceReleased
by Stefan Dösinger Sept. 25, 2006

Sept. 25, 2006

Hi, > if (This->stateBlock != NULL ) { > if ((IWineD3DResource *)This->stateBlock->streamSource[streamNumber] == resource) { > TRACE("Vertex buffer released whlst bound to a state block > stream %d\n", streamNumber); > TRACE("Vertex buffer released while bound to a state block stream %d\n", streamNumber); > This->stateBlock->streamSource[streamNumber] = 0; > } > } This is not your code, but this is wrong, even if the msdn says otherwise. Once I had a hacky test for testing this stuff. What my test did was: 1) Create a Vertex buffer 2) check device refcount: increased 3) Bind to a stream 4) check the vb refcount: unchanged(still 1) 5) release the vb(release returns 0) 6) check the device refcount: decreased 7) GetStreamSource: returns old vertex buffer 8) Check device refcount: increased 9) check vb refcount: 1 It seems that the stream source is not uset if the buffer is released. And it seems that ms implements holding the reference to the device in VertexBuffer::AddRef if(oldref == 0) IDirect3DDevice9_AddRef(This->device) or something like that, simmilar to our release. CreateVertexBuffer seems to init the ref to 0 and call VertexBuffer::AddRef. To be sure I did tested the following too: 1) Create VB 2) Check device refcount: increased 3) Release vb. Device refcount decremented 4) AddRef the just destroyed vb: Device refcount increased I didn't submit the test because it doesn't contain anything really new, and the GetStreamSource which returns the released buffer works just by chance. Any ideas to that? I agreed with Vitaly that this isn't crucial behavior as any app depending on that would randomly break on windows. Or is there some COM magic behind this, which keeps objects from beeing destroyed? Stefan

1 0

Re: Governance revisited
by Ge van Geldorp Sept. 25, 2006

Sept. 25, 2006

> From: Steven Edwards <winehacker(a)gmail.com> > > Which is why we want to have the ambassadors project to help > new people in to wine. The thinking goes that if we have some > people to help hold the hands of new developers and the > developers that are defacto maintainers of a certain section > of code will respond to patches as they seem them, this will > free julliard from having to answer every single patch with a > reply. You can have ambassadors and subsystem maintainers all you want, but in the end it's still going to be Alexandre who decides if a patch goes in. That means the end-responsibility of informing developers why a patch was rejected needs to be with Alexandre. If an ambassador or subsystem maintainer already explained it, fine, no need to create double work for Alexandre, but if noone responded I'd still expect Alexandre to send a notification. Just for the record, my own policy on patch submission (and I really hope to get back to working on Wine and submitting patches Real Soon Now :-)) is to submit a patch once. If I get feedback I'll try to improve and resubmit, but if it goes the black hole route I'm not going to beg for an explanation. If the Wine community can't be bothered to provide feedback I can't be bothered to resubmit. After all, I've already scratched my itch, the bug is already fixed in my tree, it's the communities loss, not mine. Ge van Geldorp

2 1

Last update to git 5 days ago?
by Paul Vriens Sept. 25, 2006

Sept. 25, 2006

Hi, is Alexandre on a holiday again? Or is this to recuperate from WineConf? Cheers, Paul

1 0