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

Re: [wined3d] Converting Wined3d to use WGL instead of GLX

by James Liggett

On Fri, 2005-12-16 at 02:08 +0000, Aric Cyr wrote: > Aric Cyr <Aric.Cyr <at> gmail.com> writes: > > > > > I debugged it more last night and I found the offending call. If I comment > > out > > just that one (probably unneeded from what I can tell) function everything > > works > > great. > > Replying to myself again... > > Okay so I think this whole problem might turn out to be a compiler bug. I > reverted all changes to drawprim.c I made to track down this bug, then I tried a > something different. Since I was crashing in glDrawArrays() I was thinking that > the vertex array or normal array was not properly set for some reason. Out of > the 4 demos I test with, one of them is unaffected by my bug, and running with > WINEDEBUG=d3d_draw I can see that the glDrawArrays path is not taken. So that > narrowed the problem down to the glDrawArrays code path for me. In checking the > glVertexPointer function call I changed the VTRACE message from > > /* Note dwType == float3 or float4 == 2 or 3 */ > VTRACE(("glVertexPointer(%ld, GL_FLOAT, %ld, %p)\n", > sd->u.s.position.dwStride, > sd->u.s.position.dwType + 1, > sd->u.s.position.lpData)); > > to > > /* Note dwType == float3 or float4 == 2 or 3 */ > VTRACE(("glVertexPointer(%u, %u, %ld, %p)\n", > WINED3D_ATR_SIZE(position), > WINED3D_ATR_GLTYPE(position), > sd->u.s.position.dwStride, > sd->u.s.position.lpData)); > > After making this change everything started working... this is silly though > since VTRACE is just a macro around TRACE(). So either there is stack > corruption somewhere or the compiler is wonky. Since it is gcc-4.0.2 I'm > guessing the compiler is buggy (Ubuntu breezy's standard gcc is 4.0.2 now). > I'll try recompiling with gcc-3.3 later and see if the original code is working. > > Still interested in any comments though :) > > > Hi Aric, If you see stack corruption like this, you might want to try compiling with optimization turned off. put the -O0 (a capital letter O followed by a zero) flag in your CFLAGS when you run configure. I had a similar situation where gcc was using fuzzy math when working with structures, and turning off optimization helped. James

Dec. 16, 2005

Re: Create new mailing list wine-isv?

by James Liggett

> I really fear that this will end up with vendors loudly advertising linux support and > proudly putting linux stickers on their products where everything you find inside are just > the same windows .exe files and a readme stating that these will work fine with wine. > Which at least is not what I would like to see. I agree. :) > > The main thing the _developers_ should be pointed to(if they care about their product on > other platforms then windows) are some decent docs about platform-independent programming :p Yes, they should. I think developers think about abstracting their development around cross-platform toolkits like Gtk or QT But, then again, far too many developers don't now, and probably won't ever. So what then? > > Maybe it's just me but when reading all this I got the feeling that writing windows > applications(which work with wine) is just *the* way to go. > Why the hell are we running linux then? I agree here too. Maybe this is slightly off topic in this thread, but I still have some concerns about wine's ability to run apps. Right now, development of wine is centered around getting certain apps to work. Not to mention, I also think that Wine doesn't have a big enough developer base to really address that. Windows is a *gargantuan* piece of software. Over Wine's lifetime there have been about 800 contributors with about 40 active now. I really don't think that's enough to get Wine where it needs to go, especially if we want to market ourselves as a porting solution. > > Not that I generally disagree with what you wrote. Actually it's mostly totally fine.And > it's definitly a good thing when vendors care about their product running with wine or > companies migrating to linux trying to get their highly-specialized-app to work with wine. > But imho it _shouldn't_ be the long term solution. Yes, the site that Dan put together is pretty good. It's got lots of good info. But put yourself in the ISV's shoes. If I had some big commercial product I wanted to port, would I want to use a known unstable platform, that may or may not work, to do it with? Not that I mean to sound like a pessimist, but I'm really just calling it as I see it. No offense to anyone intended. :)

Dec. 16, 2005

Re: Create new mailing list wine-isv?

by Robert Shearman

Peter Beutner wrote: > IMHO all this stuff goes a bit too much into the wrong direction. > > I really fear that this will end up with vendors loudly advertising > linux support and proudly putting linux stickers on their products > where everything you find inside are just the same windows .exe files > and a readme stating that these will work fine with wine. > Which at least is not what I would like to see. Why? Wine is effectively just a different toolkit, like QT or GTK (albeit much larger) that give applications a Windows, KDE and Gnome look respectively. Take Notepad for example - with some slight modifications you could even modify the File Open dialog to only show the Unix namespace. Is there any reason that this application can't be a fully fledged part of the desktop? > The main thing the _developers_ should be pointed to(if they care > about their product on other platforms then windows) are some decent > docs about platform-independent programming :p Sure. While you're at it give them some docs about globalization practices and efficient CPU usage. These are all nice to have things, but you have to face it that if you're a developer at a software company with a deadline then these are the first things to be ignored. You also have to bear in mind that it is incredibly difficult to do platform idependent GUI programming, whilst still maintaining the Windows look. > Maybe it's just me but when reading all this I got the feeling that > writing windows applications(which work with wine) is just *the* way > to go. It is the cheapest way for companies and it gives good results for the users. What's wrong with that? > Not that I generally disagree with what you wrote. Actually it's > mostly totally fine.And it's definitly a good thing when vendors care > about their product running with wine or companies migrating to linux > trying to get their highly-specialized-app to work with wine. > But imho it _shouldn't_ be the long term solution. Wine is a very good way of testing the waters with a Linux market. If a significant part of the market share starts coming from Linux or other Unix operating systems then the company can start offering winelib extensions that integrate better with the environment in which they are running. However, you have to face facts that Linux is a hostile environment for commercial companies - constantly changing APIs, lack of regression testing by distributions, lots of variations meaning lots of testing needed and different standards on different distributions. Wine is a layer on top of that, which provides a degree of stability. -- Rob Shearman

Dec. 16, 2005

Re: Create new mailing list wine-isv?

by Dan Kegel

On 12/15/05, Peter Beutner <p.beutner(a)gmx.net> wrote: > it's definitly a good thing when vendors care about their product running with wine or > companies migrating to linux trying to get their highly-specialized-app to work with wine. > But imho it _shouldn't_ be the long term solution. We're in violent agreement. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

Dec. 16, 2005

Re: [wined3d] Converting Wined3d to use WGL instead of GLX

by Aric Cyr

Aric Cyr <Aric.Cyr <at> gmail.com> writes: > > I debugged it more last night and I found the offending call. If I comment > out > just that one (probably unneeded from what I can tell) function everything > works > great. Replying to myself again... Okay so I think this whole problem might turn out to be a compiler bug. I reverted all changes to drawprim.c I made to track down this bug, then I tried a something different. Since I was crashing in glDrawArrays() I was thinking that the vertex array or normal array was not properly set for some reason. Out of the 4 demos I test with, one of them is unaffected by my bug, and running with WINEDEBUG=d3d_draw I can see that the glDrawArrays path is not taken. So that narrowed the problem down to the glDrawArrays code path for me. In checking the glVertexPointer function call I changed the VTRACE message from /* Note dwType == float3 or float4 == 2 or 3 */ VTRACE(("glVertexPointer(%ld, GL_FLOAT, %ld, %p)\n", sd->u.s.position.dwStride, sd->u.s.position.dwType + 1, sd->u.s.position.lpData)); to /* Note dwType == float3 or float4 == 2 or 3 */ VTRACE(("glVertexPointer(%u, %u, %ld, %p)\n", WINED3D_ATR_SIZE(position), WINED3D_ATR_GLTYPE(position), sd->u.s.position.dwStride, sd->u.s.position.lpData)); After making this change everything started working... this is silly though since VTRACE is just a macro around TRACE(). So either there is stack corruption somewhere or the compiler is wonky. Since it is gcc-4.0.2 I'm guessing the compiler is buggy (Ubuntu breezy's standard gcc is 4.0.2 now). I'll try recompiling with gcc-3.3 later and see if the original code is working. Still interested in any comments though :)

Dec. 16, 2005

Re: ATI Opengl regression (DRI?)

by Aric Cyr

Raphael <fenix <at> club-internet.fr> writes: > > On Thursday 15 December 2005 19:55, Jesse Allen wrote: > > Hi, > > > > It seems that the patch git-1399edb0925966a802a6a39835025c22c22c18e1.patch > > found here > > http://www.winehq.org/pipermail/wine-cvs/2005-December/019731.html causes > > an opengl regression on my system. With the patch loading War3 causes X > > Error of failed request: GLXUnsupportedPrivateRequest > > Major opcode of failed request: 143 (GLX) > > Minor opcode of failed request: 17 (X_GLXVendorPrivateWithReply) > > Serial number of failed request: 429 > > Current serial number in output stream: 429 > > > > Which seems to stop the game loading thread and causes the game to use > > the fail-safe thread "Please insert disc", so the game wont load. > > Reversing the patch fixes the problem. > > > > I have a Radeon 9200 using DRI snapshots about 20051024. > > > > X Window System Version 6.8.99.901 (6.9.0 RC 1) (Minimal DRI build from > > X.org tr ee) > > Release Date: 18 October 2005 + cvs > > X Protocol Version 11, Revision 0, Release 6.8.99.901 > > Build Operating System: Linux 2.6.14-rc5 i686 [ELF] > > Current Operating System: Linux tesore 2.6.15-rc4-git1 #1 PREEMPT Fri Dec 2 > > 17:0 3:32 MST 2005 i686 > > Build Date: 28 October 2005 > > > > Is this a DRI problem? > > No, only that DRI don't implement GLX 1.3 > i just sent a patch to fix (ie. by-pass) this regression. You really don't need to use glXQueryServerString() and glXQueryClientString(). It would be better, easier (not strcmp) and more correct to just use glXQueryVersion(). glXQueryVersion will automatically report the version common to both the client and server (so in this case 1.2). Another thing I don't understand in your patch is why you have wine_glx_t and wine_glx defined at global scope. It looks like the only place in your patch they are used is in wgl.c, so why not define wine_glx_t in wgl.c and make wine_glx static? Sorry if I am missing something. (Also there is some DEPTH_BITS hack in internal_glGetIntegerv which I assume is unrelated to this GLX patch?) > i thought that DRI implemented GLX 1.3 specs but seems they use a too older x > code :( > http://cvs.sourceforge.net/viewcvs.py/dri/xc/xc/programs/Xserver/GL/glx/ Too old perhaps, but that what DRI (and hence ATI) are using. Both support most of the 1.3 features so there really isn't much of an issue. The problem is that we cannot assume 1.3 regardless of how old 1.2 is. The reason for the glx version is so that we can do the right thing in any case. Also glx 1.4 isn't an official standard. It is still a draft. There is an interesting recent thread about this at http://lists.freedesktop.org/archives/xorg/2005-November/011279.html Also seems like we should be relying on glXGetProcAddress() but need to be using glXGetProcAddressARB() since nVidia apparently doesn't export the former. Regards, Aric

Dec. 16, 2005

Re: DirectDraw over Direct3D

by Roderick Colenbrander

> --- Ursprüngliche Nachricht --- > Von: Molle Bestefich <molle.bestefich(a)gmail.com> > An: Jesse Allen <the3dfxdude(a)gmail.com> > Kopie: Roderick Colenbrander <thunderbird2k(a)gmx.net>, > wine-devel(a)winehq.org > Betreff: Re: DirectDraw over Direct3D > Datum: Thu, 15 Dec 2005 20:03:32 +0100 > > Jesse Allen wrote: > > > The current state of open source video drivers for Linux is as far as > > > I know that they only do basic 2D. For 3D you have to use > > > closed-source drivers, which is simply not an option for a lot of > > > people, be that because of stability, compatability or other issues. > > > > > > Which means that your patch only helps the select few that are using > > > closed-source video drivers, is that correct? > > > > > > For everybody else, your patch will mean a tremendous slowdown > > > instead, is that correct? > > > > I have 3D acceleration in open source using DRI. This patch will help > us too. > > I wonder who "us" is :-). What hardware do you have? > > I've got ATI and the fglrx driver works like fixing a wristclock with > a large brick works. Not good. So I'm on the open source wagon. I > imagine that lots of other people are using OS drivers too. Does > anyone have a good overview of how many of the more popular OS video > drivers actually implement enough 3D for the patch to be a Good Thing? > > The patch is fine and all, but if I'm right and there's a lot of > people using OS drivers that doesn't support the features needed (thus > making performance worse), this patch should be optional and not > replace the current working stuff.. > > .02 /£/$/¥ -- GMX DSL-Flatrate 1 Jahr kostenlos* + WLAN-Router ab 0,- Euro* Bis 31.12.2005 einsteigen! Infos unter: http://www.gmx.net/de/go/dsl

Dec. 16, 2005

Re: Create new mailing list wine-isv?

by Peter Beutner

Scott Ritchie schrieb: > On Tue, 2005-12-13 at 22:33 -0800, Dan Kegel wrote: > >>I used to hate the term ISV (Independent Software Vendor) since >>it sounded so acronymy compared to 'developer', but it's >>very commonly used in the industry to refer to outfits which >>are trying to write and sell off-the-shelf software -- and >>as monkey-boy said, Microsoft is where it is partly because >>it worked hard to attract and support those guys. >> >>So I've been thinking about how to attract more Windows ISVs >>to test, support, and promote their apps on Linux with Wine. >> > > DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS! IMHO all this stuff goes a bit too much into the wrong direction. I really fear that this will end up with vendors loudly advertising linux support and proudly putting linux stickers on their products where everything you find inside are just the same windows .exe files and a readme stating that these will work fine with wine. Which at least is not what I would like to see. The main thing the _developers_ should be pointed to(if they care about their product on other platforms then windows) are some decent docs about platform-independent programming :p Maybe it's just me but when reading all this I got the feeling that writing windows applications(which work with wine) is just *the* way to go. Why the hell are we running linux then? Not that I generally disagree with what you wrote. Actually it's mostly totally fine.And it's definitly a good thing when vendors care about their product running with wine or companies migrating to linux trying to get their highly-specialized-app to work with wine. But imho it _shouldn't_ be the long term solution. Peter > > I support this idea. > > -Scott Ritchie >

Dec. 16, 2005

Re: DirectDraw over Direct3D

by Peter Beutner

Molle Bestefich schrieb: > The patch is fine and all, but if I'm right and there's a lot of > people using OS drivers that doesn't support the features needed (thus > making performance worse), this patch should be optional and not > replace the current working stuff.. as far as I understood it this patch has no drawback for users without the needed OpenGL features. If your driver supports them, fine and things will speed up. Otherwise it's done the same way like before(with the same performance). > > .02 €/£/$/¥ > > > ------------------------------------------------------------------------ > >

Dec. 15, 2005

Re: CoCreateInstance not working without TLS libraries

by Cihan Altinay

Quoting Alexandre Julliard <julliard(a)winehq.org>: > Cihan Altinay <cihan(a)uq.edu.au> writes: > > > Hi, > > A very basic C++ program fails with > > > > err:ntdll:RtlpWaitForCriticalSection section 0x7f64c560 "x11drv_main.c: > > X11DRV_CritSection" wait timed out in thread 001c, blocked by 001e, > retrying (60 > > sec) > > > > when the Linux TLS libraries are not in the library path (it works fine > > otherwise). > > Non-TLS libraries in recent glibc versions are not compatible with > Wine. What are you trying to do that requires not using TLS? Thanks for the info. I am running a Xen[1] system which currently has to emulate unsupported lib/tls library calls. And that makes the system very slow. Therefore, the Xen maintainers strictly recommend moving the /lib/tls folder out of the way. Everything seems to work fine except wine apps that use OLE. Do you think the dependency of wine on TLS will stay in future versions? Thanks, Cihan [1] http://www.cl.cam.ac.uk/Research/SRG/netos/xen/

Dec. 15, 2005