- Wine-Devel - list.winehq.org

Re: Screwed up textures in OpenGL apps
by David D. Hagood Nov. 25, 2002

Nov. 25, 2002

Dan Kegel wrote: > Please verify that booting with just one CPU active > doesn't fix the problem. e.g. at lilo prompt, do something like > linux nosmp > It could be that Wine doesn't support SMP yet. > > - Dan > > First thing I tried, and with no change, so I don't think it's a SMP issue. Furthermore, my other apps under Wine work fine, only the OpenGL ones die.

2 2

Visual Basic runtimes?
by Mike Hearn Nov. 25, 2002

Nov. 25, 2002

Hi, (btw, thanks to ove and alexandre for catching my patch booboo). Anyway, I'm trying to install Tipic IM (tipic.com) and once I figured out how to install .msi files in wine (hint: install ie6 then run msiexec /i foo.msi) I hit the lack of VB runtimes. It appears the MSI file assumes you already have msvbvm50 and msvbvm60 installed, but of course I don't. Tracking these down on the net wasn't too hard, but I'm wondering whether Wine could ship with them included or would it require a cleanroom implementation of these DLLs? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ

1 0

RE: [RFC] pthread emulation on FreeBSD (and Linux)
by Patrik Stridvall Nov. 25, 2002

Nov. 25, 2002

> On Sun, 24 Nov 2002, Patrik Stridvall wrote: > > > Anyway, to answer the first obvious question: > > Why didn't you just put it in scheduler/pthread.c? > > > > Well, the thing is it didn't work. It still generates the > > same link errors. However that is not very suprising since > > the pthread_ implementation is in ntdll.dll which is > > not linked with during the "-Bsymbolic -z defs" step. > > scheduler/pthread.c should be linked into libwine, which is > linked into > everything, at least this is the idea and was the case last time I > checked. It is not so in the current CVS of Wine: scheduler/pthread.c is linked with ntdll not with libwine. However libwine is not an appropriate place for the pthread implementation since the pthread implementation needs to call Windows API functions. libwine is a strictly Unix API library AFAICS. That why I made a new libwine_pthread library. > > This begs the question: > > Does the Linux implementation of pthread really work anyway? > > Works in WineX (though we needed some more hacks in it to > make it interact > well with the nvidia opengl drivers), and it'd surprise me if > it doesn't > still work in Wine, as the OpenGL deployed by most linux > distros wouldn't > work *at all* under Wine if it didn't, and people currently seem to be > working on Wine as if it did work. True. However, while I can't say I really understand how runtime linking work, I still feel that something is wrong. > > The thing is Linux (or rather the GNU C library) always links > > in pthread suppport. However since some of the symbols are > > on purpose defined as weak they can be overriden. This is > > what scheduler/pthread.c does on Linux. Or rather tryies to > > do. I'm not really sure if works any longer. > > It's not the weak symbols that allow overrides, weak symbols > only allow > the pthreads library to *not* be linked in (so your statement > about always > linking it in is untrue). Weak symbols work such that until > the library is > linked in, they are just null pointers, and glibc only calls > them if they > aren't null. Overriding symbols can only be done by linking > things in the > right order (link the wine overrides before the real pthread lib), and > since libwine is loaded before > opengl-linked-against-pthreads, the libwine > pthread implementation is used instead of the pthreads linked > in later, > and this don't need a special kind of symbol to work. OK. Thanks for the explaination. As I said not my area or expertise. > > Note that if I apply the attach patch and compiles on > > Linux it seems to work with "make test" as well. > > > > Anyway be pthreads on Linux working properly as it may, the big > > question is how do we support pthreads on both Linux and FreeBSD. > > I'd say link -lwine in before -lc_r, but then I don't know much about > FreeBSD. It is already done that what eventhough: 1. We current link with -lc not -lc_r, but maybe we should. 2. scheduler/pthread.c is as I said earlier in ntdll not libwine, so I can't see how linking can work and futhermore is doesn't for empirical evidence. > > FreeBSD since it AFAICS have no default overridable implementation > > seems to require that we have some sort of wine_pthread library to > > implement pthreads from scratch like outlined in the attached patch. > > The scheduler/pthread.c is basically the same thing, since it needs to > override every single pthread symbol used by apps, otherwise > the override > fails (or if it would be successful, it would still be incomplete). > > Stupid question: the reason for the missing symbols on FreeBSD isn't > because of the #ifdef __GLIBC__ in scheduler/pthread.c, is it? No, I would have to be VERY tired to make that mistake. :-) But since your premise scheduler/pthread.c in libwine is wrong that might be the answer. However it still doesn't explain why OpenGL seems to work on Linux. Perhaps it is because Linux have weak symbols or whatever concerning pthreads in libc and everything is OK because of this...

1 0

Off Topic: Off-list help needed with SGML Tools please
by Dustin Navea Nov. 25, 2002

Nov. 25, 2002

For some reason I cant get SGMLTools to compile properly, everything but jade compiles but when it goes to compile that, I get a bunch of errors. I could leave out jade but thats what Im needing to compile to build sgml docs... I have tested this with Slackware 8.1 default GCC and the prepackaged GCC 3.2.1 Source from Slackware-current and neither would compile it. I also tested that its not just Slackware's GCC... Redhat 8.0 would not compile it either with GCC 3.2.1... So if anyone can help me it would be most appreciated.. I still have a couple of other things to try (installing the latest slackware binutils, and trying out CVS sgmltools, if i can ever connect to the cvs server) :/ -Dustin

1 0

Exe, Com and PATH
by Sylvain Petreolle Nov. 25, 2002

Nov. 25, 2002

Wanting to run msdos debugger, I ran from c:\ : wine debug. the 2 debug that exists on my fake windows are c:\debug.com c:\windows\command\debug.exe My PATH variable is set as "Path" = "c:\\program\ files\\java\\j2re1.4.0_01\\bin;c:\\windows;c:\\windows\\command;c:\\windows\\system32;c:\\windows\\system;e:\\" Currently running wine debug from c:\ runs c:\windows\command\debug.exe,ignoring debug.com in the current directory. This is not the behaviour expected in real windows. These are 2 problems here : - Normally dos looks first in current directory => would load c:\debug.com. There is a problem with PATH here. - Putting 2 files with a .exe and .com with the same name in the same directory loads the .exe first, which shouldn't happen. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Fwd: Problem with network functions
by Sylvain Petreolle Nov. 24, 2002

Nov. 24, 2002

Does someone has a clue for this / has same issues ? I cant figure how to find what is causing the network errors I have. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Bug #416: Missing Exports in Winsocks
by Andrew John Hughes Nov. 24, 2002

Nov. 24, 2002

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This patch adds stubs for the functions listed in Bug #416, SetService{A,W} and GetTypeByName{A,W}. License: LGPL - - -- Andrew :-) Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE94VftSE/kMce1ABARAipUAJ0ew9mD8eqn+2HrS1Yk72lvy+h4QACfaIeV uPloEX9A/xk4ptC6l0Xl5Z4= =K3YG - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE94VggSE/kMce1ABARAleXAJ40B6etNGsPhlZdm7GoqCrvYpGwpACgiU/o 2chi+d/NOUGg3WhHjj31UwQ= =Za8w -----END PGP SIGNATURE-----

1 0

Re: Some additions to D3D
by Alexandre Julliard Nov. 24, 2002

Nov. 24, 2002

Lionel Ulmer <lionel.ulmer(a)free.fr> writes: > Note (for Alexandre): how would you prefer for us to track dependencies > between patches ? Submit each time a patch agains fresh CVS with all > previous patches sent (with an ever growing changelog) or do you prefer > (like here) a lot of patches dependant one on the others ? > If it's the latter, do we need to do 'letter tracking' as Dimi did ? In general separate patches are better; the exception is if they are fixes to a previous patch then it's better to resend all so I don't have to try to understand the broken version before reading the fix. And yes, in either case please find a way to clearly mark the sequence, don't rely on the submission order because mail doesn't always arrive in the correct order. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: _ fstati64
by Stefan Leichter Nov. 24, 2002

Nov. 24, 2002

Am Sonntag 24 November 2002 11:11 schrieben Sie: > ChangeLog > ------------- > converted implementation of _fstat to _fstati64 > implemented _fstat by calling _fstati64 > Hello Alexandre, this patch is relative to my patch _stati64 please apply the _stati64 patch before this one. The _stati64 patch went to the worng list by accident. Thanks Stefan

1 0

Screwed up textures in OpenGL apps
by David D. Hagood Nov. 24, 2002

Nov. 24, 2002

I'd asked this before, but received no response, so I'll ask it again. Does anybody have any suggestions on where to start debugging textures being wrong under OpenGL apps under Wine? Specifically, I am trying to get HalfLife-Blue Shift to run, but all the "static" textures (walls, floors, etc.) are screwed up. The "dynamic" textures on things like people are fine. Now, I USED to have Halflife running great, but then I upgraded my system to a SMP P3 system (I had been running a UMP P3) (the old system died.) All my native apps (Q3A, RTCW, gears, etc.) are just fine. Only Windows apps running under Wine are screwed up. Does anybody have a simple Windows OpenGL app I can use for testing? Or a direction to begin looking in? I do know this - forcing OpenGL to go to indirect rendering does NOT fix the textures - they are still just as screwed up, just a lot slower.

2 1