December 2005 - Wine-devel - list.winehq.org

Re: gethostbyname(my_name) and IL2-Sturmovik
by Juan Lang 13 Dec '05

13 Dec '05

Hi David, > The string in str was "192.168.2.75" which is my Network IP-Adress. > With wine(under Linux), as far as I've tested it, exactly the same > code always generates "127.0.0.1". > Since Wine tries to simulate Windows as exactly as possible, > this is wrong. > So, in my opinion this Patch is necessary. :-) You're right that Wine doesn't behave correctly in this case. The trouble is your patch is rather ugly. First, the style isn't correct--no C++-style comments, please, and make the indenting consistent. Second, there's a leak in the code you wrote, the socket you open to do SIOCGIFCONF on is never closed. It would be cleaner, in my opinion, to use iphlpapi's GetAdaptersInfo, which already enumerates the public (non-loopback) interfaces available on the system. --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

RFC: D3D7 and WineD3D
by Stefan Dösinger 12 Dec '05

12 Dec '05

Hello, In the past weeks, I've worked on a re-write of the Direct3D7 implementation with WineD3D. Well, I've managed to get some games running, but I have also encountered a few problems. Before I continue with this, I'd like to ask for your opinions. I have uploaded a patch to http://doesi.gmxhome.de/d3d7.patch.bz2, it's a diff against Wine CVS from December, 11th 2005. It's not really meant to be used, but rather to have something to look at. I don't know how long I can keep the patch there, because I am limited in space. I've sent the patch to Oliver some days ago to upload it to his sourceforge website, it will be available there when he uploads it. So what's the point of this mail? While a D3D7->WineD3D wrapping can be done by wrapping D3D7 only and leave DirectDraw in ddraw.dll, it has a few ugly drawbacks: -> Device initalisation: In D3D7, the first step is to create a IDirectDraw Device, set up the device, create a surface and then create a Direct3D Device. When creating the WineD3DDevice in the last step, I have to do some ugly things to wrap the allready existing Surface to a newly created WineD3DSurface. The same applies in reverse order for the device removal. I also don't know what to do if a game changes the screen setup after D3DDevice creation. -> Surfaces: In D3D7 surfaces are children of IDirectDraw, while in WineD3D they are children of WineD3DDevice. Because the D3D7Device can be created and destroyed without modifying surfaces, I have to manage the surface's properties and memory areas for both DirectDraw and WineD3D. Overrides for the Lock() and Unlock() functions are used to access the WineD3D surface if it exists. I think that everything would be much cleaner if the DirectDraw functionality was also moved to WineD3D. My suggestion is the follwing. -> WineD3D would be initialised in the D3D7 way, using a new interface WineDDrawDevice. D3D8 and D3D9 could easily manage this in their create functions -> Surfaces are created with WineDDrawDevice, and they survive the release of WineD3DDevice. This makes surface creation easier for D3D7, and it's easy to adopt it for D3D9 and D3D8. -> The IWineD3DSurface interface gets additional functionality for DirectDraw operations. I'd suggest 3 versions of the 2D functions: One based on plain X11(for compatiblity) calls, one that uses DGA(speed without 3D acceleration), and one that uses OpenGL(For fast rendering without /dev/mem access). For DXVersion > 7 the OpenGL version is used, and for DX7 it can be decided when the primary surface is created. What's the drawback? First, it's much more work, and it's a really invasive change to WineD3D, which becomes more complex. Because of this I'd like to know your opinion before I spend a lot of time for this. Stefan

1 1

gethostbyname(my_name) and IL2-Sturmovik
by David Nolden 12 Dec '05

12 Dec '05

Ok, I've just checked doing the same thing under windows. The test(ripdaveno is the name of the Computer I tested on): { ... hostent* h = gethostbyname("ripdaveno"); char* str = inet_ntoa(*((in_addr*)h->h_addr_list[0])); ... } The string in str was "192.168.2.75" which is my Network IP-Adress. With wine(under Linux), as far as I've tested it, exactly the same code always generates "127.0.0.1". Since Wine tries to simulate Windows as exactly as possible, this is wrong. So, in my opinion this Patch is necessary. :-) greetings, David Nolden

1 0

gethostbyname(my_name) and IL2-Sturmovik
by David Nolden 12 Dec '05

12 Dec '05

I've just checked the registry-accesses. It only seems to take the own name from there(which it later uses to get the IP-Adress). It doesn't try to read anything in the area mentioned on the microsoft-site you sent me. greetings, David Nolden

1 0

Re: Robert Reif : winecfg: Added support for auto detecting all drivers by attempting to
by Eric Pouech 12 Dec '05

12 Dec '05

I do think all the recent changes to winecfg are going into the wrong direction. First of all, allowing the devices to be opened more than once without having the devices ready for that is a ready bad idea. Basically, windows drivers come in two flavors: - single instance (they can be loaded only once in memory) - multiple instance (they can be loaded several times in memory) For the second type, a specific init string (gotten from the registry, and usually dealing with the HZ resources involved) is passed to the driver. In the wine implementation, we don't get anything from the registry, we just let the device (from the unix interface it uses) return as many audio/midi... ports it finds. This is typically the behavior expected from single instance drivers. Among the issues we'll face here are dual open of the same unix resource (contention) for several instances, overwriting of internal data and structures (they are not prepared for that). Therefore, the multiple open patch has to be reverted. Secondly, I do think it's a bad idea to reconstruct in winecfg most the driver management. It's not done correctly (the DRV_INIT, DRV_ENABLE and DRV_LOAD messages are not correctly passed). If it works today, it's by chance as the configure message is never handled (we just put out a message box), but it doesn't access the internal structures. To do it, we need the DRV_ messages sent. Finally, I'm not sure that presenting all the drivers, and the ports available is really meaningful for most users. Some drivers return just potential entries (esound for example). Even with the caps, most users won't tell the difference between alsa and oss entries. Lately, the available drivers button is not really useful. We shouldn't present non available drivers to the users, and just let him/her choose among the available ones (or just to mark the ones which are not available). -- Eric Pouech

2 6

Re: WIDL: Zero Initialize Server Parameters
by Robert Shearman 12 Dec '05

12 Dec '05

Robert Shearman wrote: > ChangeLog: > Zero initialize parameters in the generated code. Based on a patch by > Eric Kohl. Oops. Looks like this patch was already accepted and the patch I just sent was a merge conflict. Please ignore. -- Rob Shearman

1 0

Re: [NDR] Implement NdrClientCall2 and NdrServerCall2
by Detlef Riekenberg 12 Dec '05

12 Dec '05

Am Donnerstag, den 01.12.2005, 00:39 -0600 schrieb Robert Shearman: > [NDR] Implement NdrClientCall2 and NdrServerCall2 > [NDR] Fix handle support for stubless objects > [NDR] Fix Accessing Arguments in NdrClientCall2 Hi Rob. I tested your Patches with printui.dll and winspool.drv (from w2k) and got only "RPC_X_WRONG_STUB_VERSION" --- cut --- trace:rpc:NdrClientCall2 MIDL stub version = 0x5030117 fixme:rpc:NdrClientCall2 RPC_FC_BIND_GENERIC --- cut --- Then i commented out the RpcRaiseException() after the fixme and run: wine rundll32 printui.dll,PrintUIEntry /s The Server-Properties-Window opens and react on the Mouse, but the Fields are Empty or filled with Garbage. (same garbage as buildin winspool.drv with my patch for OpenPrinter) I attached an updated log to bug 3105 Thanks for your work on RPC. -- By By ... ... Detlef

2 1

Re: Alexandre Julliard : server: Added access rights mapping to synchronization objects.
by Robert Shearman 12 Dec '05

12 Dec '05

Alexandre Julliard wrote: >@@ -132,6 +133,15 @@ static int event_satisfied( struct objec > return 0; /* Not abandoned */ > } > >+static unsigned int event_map_access( struct object *obj, unsigned int access ) >+{ >+ if (access & GENERIC_READ) access |= STANDARD_RIGHTS_READ | SYNCHRONIZE | EVENT_QUERY_STATE; >+ if (access & GENERIC_WRITE) access |= STANDARD_RIGHTS_WRITE; >+ if (access & GENERIC_EXECUTE) access |= STANDARD_RIGHTS_EXECUTE; >+ if (access & GENERIC_ALL) access |= STANDARD_RIGHTS_ALL | EVENT_ALL_ACCESS; >+ return access & ~(GENERIC_READ | GENERIC_WRITE | GENERIC_EXECUTE | GENERIC_ALL); >+} >+ > static int event_signal( struct object *obj, unsigned int access ) > { > struct event *event = (struct event *)obj; > Why did you decide to rely on another function to map the access rights? It seems that none of the objects' mappings depend on any state in the object, so couldn't you have just put the access rights that GENERIC_READ, GENERIC_WRITE, GENERIC_EXECUTE and GENERIC_ALL map to somewhere associated with the object and have just one mapping function. -- Rob Shearman

2 3

gethostbyname(my_name) and IL2-Sturmovik
by David Nolden 12 Dec '05

12 Dec '05

Hi everybody. Currently, my favorite Game is "IL2-Sturmovik Forgotten Battles", especially it's online-mode. The Game itself is running nearly flawless and at good performance, but I encountered a network-problem which didn't allow the game to connect to any remote server, so I've analyzed and solved the problem. This is what the game does: 1. Create a Datagram-socket 2. Call gethostbyname(own_name) to find out the current IP-Adress 3. Bind the socket to that IP-Adress 4. Try connecting to the remote game using exactly that socket The Problem: gethostbyname(own_name) always returns 127.0.0.1. I've searched a bit on the internet, and this seems always to be the case, not just on my computer. The socket is then bound to the ip-adress 127.0.0.1, and to it's corresponding loopback-interface, so it's unusable. Any connection-request times out. I don't really know much about Networking itself, I just know how to use IP-Networking, but I think it's pretty boring(especially the way it all is implemented) so I don't even know what IPV6 is, and I don't know if my patch is compatible with it(although I think so). Also I don't know if returning 127.0.0.1 is in fact not a bug but desired, and the game is doing something wrong here. But if it is desired that gethostbyname(own_name) preferrably returns the public IP-Adress, then this code should solve the problem, although maybe a bit more checking should be done which IP-Adress should be chosen as the public one for cases with multiple non-loopback-interfaces. I submit this patch to the wine-devel-list so people who know more about all the network-handling can discuss about it, and decide whether it should be put to cvs, or whether there is a better Solution for this problem. The Code enumerates all available Interfaces through the kernel, and decides which one should be used in a very naive way. greetings, David Nolden (btw. my subscription to the list doesn't seem to be complete yet, I'm sending this anyway)

2 1

Re: crypt32: decode cleanups
by Alexandre Julliard 12 Dec '05

12 Dec '05

Juan Lang <juan_lang(a)yahoo.com> writes: > ChangeLog: > - implement a helper to decode sequences of like types > - use helper functions wherever applicable when decoding > - fix a few other small bugs This breaks the test: encode.c:790: Test failed: Expected OID Juan Lang, got NULL encode.c:790: Test failed: Expected OID Juan Lang, got NULL encode.c:790: Test failed: Expected OID Juan Lang, got NULL -- Alexandre Julliard julliard(a)winehq.org

1 0