May 2003 - Wine-Devel - list.winehq.org

Re: Add wglGetExtensionsStringARB to opengl

by Lionel Ulmer

> Looks like it needs some extensions. Could you try again with your patch (mine is obviously wrong now that I looked a bit more as the ARB versions has a HDC parameter while the EXT one has not) but with returning the empty string ? Could you also try and just return the 'WGL_ARB_extensions_string' string :-) ? If this works, can you resubmit your patch by changing the 'static const char *WGL_extensions = "";' line to 'static const char *WGL_extensions = "WGL_ARB_extensions_string WGL_EXT_extensions_string";' And to have wglGetExtensionsStringARB returning what wglGetExtensionsStringEXT returns ? > I thought that, but it was working and I've not much experiences with > opengl. Well, the only way to be really sure would be to go on Windows and to call this function to see if it returns also 'plain' GL extensions. If no, we are in our rights to not return anything :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

May 3, 2003

How to add a new DLL?

by Gerhard W. Gruber

I was just trying to add a new dll to wine (w95in32.dll and w95inf16.dll). In order to achieve this I looked into some other dlls and copied the Makefile and Makefile.in. The I created the specfile for the dll and adjusted the Makefile. At least that was what I think I did, but it always complains that I have to run configure. So I adjusted configure as well and rerun it, but i stil get this error. Is there somewhere an explanation so I can look how I have to configure Makefile.in. The Makefile will be generated from this through configure, right? -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken)

May 3, 2003

Re: Add wglGetExtensionsStringARB to opengl

by Michael Schlüter

Hi Lionel, On Sat, 2003-05-03 at 22:44, Lionel Ulmer wrote: > > this patch adds wglGetExtensionsStringARB to the opengl.dll. I don't > > know if it really does all in the proper way. So somebody with more > > opengl experiences should take a look at the patch before including it. > > Well, I think the best way would be to do something like that : > > Index: dlls/opengl32/opengl32.spec > =================================================================== > RCS file: /home/wine/wine/dlls/opengl32/opengl32.spec,v > retrieving revision 1.19 > diff -u -r1.19 opengl32.spec > --- dlls/opengl32/opengl32.spec 20 Mar 2003 03:53:13 -0000 1.19 > +++ dlls/opengl32/opengl32.spec 3 May 2003 20:41:57 -0000 > @@ -6,6 +6,7 @@ > @ stdcall wglGetCurrentContext() > @ stdcall wglGetCurrentDC() > @ stdcall wglGetExtensionsStringEXT() > +@ stdcall wglGetExtensionsStringARB() wglGetExtensionsStringEXT > @ stdcall wglGetLayerPaletteEntries(long long long long ptr) > @ stdcall wglGetProcAddress(str) > @ stdcall wglMakeCurrent(long long) > > > Could you try if this works for you ? didn't work: trace:opengl:X11DRV_ChoosePixelFormat (0x403942a0,0x40dd1bd4) - size / version : 40 / 1 - dwFlags : PFD_DOUBLEBUFFER PFD_DRAW_TO_WINDOW PFD_SUPPORT_OPENGL - iPixelType : PFD_TYPE_RGBA - Color : 16 - Alpha : 0 - Accum : 0 - Depth : 16 - Stencil : 0 - Aux : 0 - iLayerType : PFD_MAIN_PLANE trace:opengl:X11DRV_ChoosePixelFormat Found visual : 0x3c0b8160 - returns 1 trace:opengl:X11DRV_SetPixelFormat (0x403942a0,1,0x40dd1bd4) trace:opengl:wglCreateContext (0x12c) trace:opengl:wglCreateContext creating context 0x40394338 (GL context creation delayed) trace:opengl:wglMakeCurrent (0x12c,0x40394338) trace:opengl:wglMakeCurrent created a delayed OpenGL context (0x3c0bd990) trace:opengl:wglMakeCurrent returning True trace:opengl:wine_glGetString (7939) trace:opengl:wglGetProcAddress (wglGetExtensionsStringARB) trace:opengl:wglGetProcAddress found function in 'standard' OpenGL functions (0x43e5cca8) trace:opengl:wglGetExtensionsStringEXT () returning "" trace:opengl:wglMakeCurrent ((nil),(nil)) trace:opengl:wglMakeCurrent returning True trace:opengl:wglDeleteContext ((nil)) warn:opengl:wglDeleteContext Error deleting context ! Looks like it needs some extensions. > Basically, your patch is wrong because you return OpenGL extensions whereas > this function should return WGL extensions (and as we do not support any for > now, we return an empty string). I thought that, but it was working and I've not much experiences with opengl. Bye, Michael

May 3, 2003

Re: Add wglGetExtensionsStringARB to opengl

by Lionel Ulmer

> this patch adds wglGetExtensionsStringARB to the opengl.dll. I don't > know if it really does all in the proper way. So somebody with more > opengl experiences should take a look at the patch before including it. Well, I think the best way would be to do something like that : Index: dlls/opengl32/opengl32.spec =================================================================== RCS file: /home/wine/wine/dlls/opengl32/opengl32.spec,v retrieving revision 1.19 diff -u -r1.19 opengl32.spec --- dlls/opengl32/opengl32.spec 20 Mar 2003 03:53:13 -0000 1.19 +++ dlls/opengl32/opengl32.spec 3 May 2003 20:41:57 -0000 @@ -6,6 +6,7 @@ @ stdcall wglGetCurrentContext() @ stdcall wglGetCurrentDC() @ stdcall wglGetExtensionsStringEXT() +@ stdcall wglGetExtensionsStringARB() wglGetExtensionsStringEXT @ stdcall wglGetLayerPaletteEntries(long long long long ptr) @ stdcall wglGetProcAddress(str) @ stdcall wglMakeCurrent(long long) Could you try if this works for you ? Basically, your patch is wrong because you return OpenGL extensions whereas this function should return WGL extensions (and as we do not support any for now, we return an empty string). Moreover, Wine already supported 'wglGetExtensionsStringEXT' (needed by some games), so I just told here that 'wglGetExtensionsStringARB' is a duplicate of the 'wglGetExtensionsStringEXT' function. Lionel -- Lionel Ulmer - http://www.bbrox.org/

May 3, 2003

Re: Solaris Update Patch 02052003

by Dimitrie O. Paun

On May 3, 2003 06:38 am, Robert Lunnon wrote: > No need to be rude... Ugly it might be but something like this is necessary I didn't mean to be offensive. I was just commenting on that particular piece of code, nothing personal. People can usually speak their mind on the net. But I should have been more diplomatic, my apologies. -- Dimi.

May 3, 2003

Re: wineHQ update

by Dimitrie O. Paun

On May 3, 2003 03:55 pm, erwin wolff wrote: > This patch modifies the WineHQ website at two pionts. It adds a webbased > forum who is donated by a company to the forums section and updates the > working state of borlands cc in the fun projects page according the news > issue 168. Few comments: -- Please send patches in the right format: http://winehq.org/?page=sending_patches -- I don't think I like yet another forum. It unnecessarily dilutes them. We have the newsgroup, wine-*, they should be enough. If anonymity is the only feature, people should open web-mail accounts, there are plenty around. -- Please funnel all Fun-related changes through me. I'll take care of updating the WineHQ site, otherwise changes submitted to WineHQ will most likely get lost on my next update. -- Dimi.

May 3, 2003

Re: Idea: Combine libSDL with the Wine project

by Lionel Ulmer

> Combine the SDL project with the Wine DirectX code. It is a great way to > catch up with the winex project and SDL has also network code to begin > working with the RASAPI32 DLL (used by various instant messengers). Well, this idea has been proposed at least 5 times now and the answer is always : what would be the gain for the Wine project ? Basically, it won't gain us any speed as SDL is layered upon exactly the same APIs Wine is (basically, X, XShm or DGA). So if SDL can do it, we can also do it an integrate it better in Wine. The only way SDL can be used in Wine is NOT related at all to DirectX but as a completely new display driver (as we have TTYDRV and X11DRV). Basically, to use SDL as a portable frame-buffer like device. Lionel -- Lionel Ulmer - http://www.bbrox.org/

May 3, 2003

Re: More checks when loading the driver

by Eric Pouech

> the error no longer exists. I guess some registry entry was corrupt and a > successfull run corrected it later. this also could happen with stack corruption > However I see a lot of check after DRIVER_FindFromHDrvr() in other parts of > the code... they are not checks, but rather discoveries of the actual capabilities of the driver A+ -- Eric Pouech

May 3, 2003

Window opnes on other desktop

by Gerhard W. Gruber

I just noticed this by accident. I closed Agent and it showed the dialog that it purges newsgroups. While it were at it I switched to another desktop and did some work and suddenly the Agent dialog popped up telling me that it now will purge the trash folder (which it does after it cleared the newsgroups). Shouldn't the wine app stay on the same desktop where I started it? I'm not sure if this is a bug or a feature, because when I start other apps in one desktop and switch to another before they open any window (i.e. Netscape takes some time) then the window will also be opened on the active desktop instead from where I launched it. -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken)

May 3, 2003

winsock and virtual interfaces

by Juan Lang

I'm planning to patch winsock (both ws2_32 and wsock32 varieties) so that virtual interfaces will be included in response to IP address/interface list queries. If you'd like different behavior, please speak up (though it's up to Alexandre anyway :) ) More detail: I'm patching wsock32 and winsock to use iphlpapi.dll to enumerate interfaces, get the route table, and that sort of thing. Less code duplication, and I'm trying to isolate the plaform-specific network code to fewer files. (If any of you saw my earlier call for help, the stack corruption was due to socket() mismatching.) Yet more detail: In writing iphlpapi.dll, I was curious about the code in wsock32 and winsock that tries to filter out virtual interface names (in WSAIOCTL_GetInterfaceName()). So, I tested a little bit with my Linux system, and it seems this code does not behave as desired: On my system, virtual interfaces don't show up in /proc/net/dev, so the filtering for them seems a little pointless. But if they did show up, the filtering seems counterproductive: Say you had three interfaces, lo, eth0, and eth0:0. You'd be told (by WSAIOCTL_GetInterfaceCount()) that you have three interfaces, but if you got the names of them, you'd only get two unique names. Furthermore, since the filtered name is what's used for getting the IP address, MAC address, and whatnot, in fact you'd end up with duplicate entries in responses to queries. I've attached my little test program; try it with and without virtual interfaces to see what I mean. I also tested how Win2K behaves with multiple IP addresses on an interface. In IP address tables, there's one entry per IP address, as expected. In GetAdaptersInfo, the IP address list has every configured address for the adapter, also I suppose as expected. So, in Win2K, an interface (uniquely identified by an index) can have 0..N IP addresses. I've attached some output from a test program on Win2K to illustrate. I don't emulate this behavior. Instead, I let an interface have 0 or 1 IP address, and treat virtual interfaces as unique interfaces, with their own index. This makes the code rather simpler. If anyone has a strong opinion otherwise, please speak up. (Patches coming this week. iphlpapi.dll is working, and wsock32 is using it to implement WsControl now. I want to change iphlpapi a little bit to make it more appropriate for netapi32 before I submit.) Thanks, --Juan __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com GetIpAddrTable returned 3 entries: GetIpAddrTable entry for adapter index 16777219: ip 192.168.1.2 mask 255.255.255.0 broadcast 1.0.0.0 reasm size 65535 GetIpAddrTable entry for adapter index 16777219: ip 10.0.0.1 mask 255.255.255.0 broadcast 1.0.0.0 reasm size 65535 GetIpAddrTable entry for adapter index 1: ip 127.0.0.1 mask 255.0.0.0 broadcast 1.0.0.0 reasm size 65535 GetIfEntry returned 2 entries: GetIfEntry for adapter index 16777219: name: description: Wireless-G Notebook Adapter Type: ethernet physical address: 00:06:25:3d:b5:58 GetIfEntry for adapter index 1: name: description: MS TCP Loopback interface Type: loopback physical address: See 1 adapters in IP_INTERFACE_INFO Adapter 16777219's name is \DEVICE\TCPIP_{66B081D9-F4E3-4FE8-85CC-0934F6134D44} GetAdaptersInfo output: Name: {66B081D9-F4E3-4FE8-85CC-0934F6134D44} Description: Wireless-G Notebook Adapter MAC addr: 00:06:25:3d:b5:58 Index: 16777219 Type: ethernet IP addresses: 10.0.0.1/255.255.255.0 192.168.1.2/255.255.255.0 Gateways: 192.168.1.1

May 3, 2003