November 2002 - Wine-devel - list.winehq.org

Re: Screwed up textures in OpenGL apps
by David D. Hagood 26 Nov '02

26 Nov '02

Lionel Ulmer wrote: > Out of curiosity after the DoubleBuffered thread.... Does this fix your > problem too ? > > No, I was running DesktopDoubleBuffered = Y already.

1 0

Winelib Apps v0.1
by Dimitrie O. Paun 26 Nov '02

26 Nov '02

Folks, Version 0.1 of the Winelib Applications page is available here: http://www.dssd.ca/wine/Winelib-Apps-0.1.html The current version is always available at this address http://www.dssd.ca/wine/Winelib-Apps.html Your comments, and suggestions are highly appreciated. -- Dimi.

1 1

An opengl regression
by Duane Clark 25 Nov '02

25 Nov '02

The patch for dynamic loading of opengl, http://www.winehq.com/hypermail/wine-cvs/2002/11/0151.html has caused a (apparently minor) regression in the program earthquake http://www.navagent.com/products/earthquake/ That is a small app (250K download) with a spinning globe that shows current earthquakes; actually a pretty cool little app. The regression is that now when the oceans are turned on (via the settings dialog), the land gets flooded.

3 5

Compiling Win32 targets on Linux
by mwood＠gosympatico.ca 25 Nov '02

25 Nov '02

I'm not sure if this is directly related to Wine, but I would like to build win32 exectuables on a Linux machine, with gcc if this is possible. I use Slackware 7.x and 8.x and was wondering what I would need to install to accomplishh this. Mikko Woodroffe

2 1

Wintab.dll technical issues.
by Robert North 25 Nov '02

25 Nov '02

Firstly a quick note: I have opened a bug for implementation of wintab.dll (Bug No. 1160) Now the questions: 1: Writing stubs. I'll be taking up Patrik Stridvall's offer to write stubs for anyone new to wine development. One question about stubs: What's the wine policy on stub return values? Should a stub always return an error? Should/Can it return success? 2: Testing wintab.dll in Win98. wintab.dll is quite complex for what it does. Therefore the only practical way to implement it is to work on the functions and communication models that are used by the apps I want it to support. To do this, I need some tool that can log the function calls and parameters to the DLL, while wunning Win98.The logging must be able to let the programmer choose elements from data stuctures in parameters/retvals to log. Any ideas???? I've attempted to use apis32 and built a wintab.fnl file for wintab.dll. Unfortunately apis32 doen't allow the logging of the contents of data structs. I would also like to know experinces with Spy++. Wintab can send it's own custom messages, so I'm wondering how good Spy++ is at detecting custom messages? I've used it many times before, but only to examine standard windows messages. 3: Coding standards. I haven't found any coding standards associated with wine. This is particularly important, as I'll be writing new source files. Can someone point me to the standards? Hope you guys have the answers -Rob.

5 5

[RFC] pthread emulation on FreeBSD (and Linux)
by Patrik Stridvall 25 Nov '02

25 Nov '02

With the attached patch FreeBSD compiles again even if OpenGL (which need pthreads) is used. Since it is only stubs at present OpenGL can't really work, but Wine and the normal test runs fine ("make test"). 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. This begs the question: Does the Linux implementation of pthread really work anyway? 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. 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. 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. I'm not really very good on how runtime linking on Linux and FreeBSD. So, I would very much like comments from people more knowledgeable than I on that area. Comments? Suggestions? PS. Can somebody test if OpenGL:s pthread locking REALLY works properly on Linux?

3 2

Re: Screwed up textures in OpenGL apps
by David D. Hagood 25 Nov '02

25 Nov '02

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 25 Nov '02

25 Nov '02

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 25 Nov '02

25 Nov '02

> 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 25 Nov '02

25 Nov '02

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