July 2001 - Wine-Devel - list.winehq.org

The [Windows] section

by Bill Medland

Is the [Windows] section of the config still supposed to be in use or should Tweak.Layout be used instead? (I am looking at the [Windows].BorderWidth in particular) Bill

July 3, 2001

Re: Win16 problems

by eric pouech

> I could probably look into the OpenGL problem if that was the only > problem, but why are Win16 windows never drawn anyway? > (Unfortunately, I don't have sol.exe here, I tested with MS Word > Viewer 16-bit, but DOS apps like Monkey Island gets the same issues in my > tree) well; same issue here (without opengl support) however, it's not consistent across all apps winmine fails to draw, whereas freecell runs just fine A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

July 3, 2001

Re: Mixed mode CD's and volume label

by Andreas Mohr

On Tue, Jul 03, 2001 at 09:47:03AM -0500, David Hagood wrote: > I was trying to get Half-Life running under Wine last night, and ran > into a problem with getting the CD label under Wine. Since the HL CD is > a mixed mode data/audio disk (as are most game disks nowadays) Wine > complained with a > > We don't have a way of determining the label of a mixed mode CD - Linux > doesn't allow raw access ! Well, actually this message is dead wrong. Linux doesn't allow "normal" block device access, but there are certainly ioctls for special CD-ROM sector formats available. A lot of experimentation of mine didn't enable me to find out how the serial of a mixed-mode CD gets calculated, though. Reading the label of a mixed-mode CD is an entirely different matter, of course. Either you intend to hack on it a bit, or it'll definitely be on my ToDo list for the next weeks to come. > As an experiment, I disabled this check in misc/cdrom.c, and it worked > quite happily. Hmm, then this program didn't really have demanding requirements ;) > Now, if I could just work out why the OpenGL is flashing... Check out lhl.linuxgames.com AFAIK that might be the frequently mentioned DRI bug. -- Andreas Mohr

July 3, 2001

Mixed mode CD's and volume label

by David Hagood

I was trying to get Half-Life running under Wine last night, and ran into a problem with getting the CD label under Wine. Since the HL CD is a mixed mode data/audio disk (as are most game disks nowadays) Wine complained with a We don't have a way of determining the label of a mixed mode CD - Linux doesn't allow raw access ! However, Xcdroast was easily able to access the data. As an experiment, I disabled this check in misc/cdrom.c, and it worked quite happily. Perhaps this check is out of date. Perhaps it is my system setup: 2.4.6-pre7, Samsung CD-Writer/DVD reader on IDE, ide-scsi module loaded, Wine configured to use the /dev/scd0 link. Now, if I could just work out why the OpenGL is flashing...

July 3, 2001

Re: Window painting problem

by Malte Starostik

On Dienstag, 3. Juli 2001 14:35, Glenn Schrader wrote: > The problem appears to be in BeginPaint. There is a > test which checks to see if the window has the > CS_PARENTDC flag set. If so then then the update > region is discarded and the window is painted. > This has the side effect of making the whole > window repaint every time anything in the window > changes. > > According to the windows docs that i've looked at, > the CS_PARENTDC should just make the window paint > using its parent's device context. There isn't any > mention of also removing the invalid region clipping > so i'm pretty sure that what BeginPaint is doing > isn't right. As I posted a while back (http://www.integrita.com/cgi-local/lwgate.pl/WINE-DEVEL/archives/2001-06/da…) there are other problems with it and there are contradicting pieces of documentation :( -Malte

July 3, 2001

Re: Window painting problem

by r.maurizzi＠gvs.it

Glenn Schrader <gschrad(a)ll.mit.edu> wrote: > The symptom is that (in some cases) any change to a > window will cause the entire window to be repainted. > (...) > This doesn't happen on most applications. > In fact, the only one where i've seen this effect is > RoAClient (a really good MUD client). Even so, its > really annoying and makes the window flash so much > that the app is effectively useless. Just for info, Lotus Notes v 4.6x has the same problem. Ciao, Roberto.

July 3, 2001

Window painting problem

by Glenn Schrader

I've been tracking down a window painting problem and I think that I know whats happening but I'd like to get some opinions on the 'right' way to fix it. The symptom is that (in some cases) any change to a window will cause the entire window to be repainted. For instance, using the mouse to select a single character causes the whole window to update rather than just the small region which needs to be highlighted. This doesn't happen on most applications. In fact, the only one where i've seen this effect is RoAClient (a really good MUD client). Even so, its really annoying and makes the window flash so much that the app is effectively useless. The problem appears to be in BeginPaint. There is a test which checks to see if the window has the CS_PARENTDC flag set. If so then then the update region is discarded and the window is painted. This has the side effect of making the whole window repaint every time anything in the window changes. According to the windows docs that i've looked at, the CS_PARENTDC should just make the window paint using its parent's device context. There isn't any mention of also removing the invalid region clipping so i'm pretty sure that what BeginPaint is doing isn't right. In my hacking around, I disabled the branch of the test which removes the clipping region and things appear to work a lot better. The screen updating is definitely smoother. What I'm not sure of is whether this is good enough or whether the CS_PARENTDC case really should be slightly different. Normally the clipping region is offset relative to the window thats being drawn but with CS_PARENTDC should the offset be done relative to the parent window instead? Are there any other subtle things that CS_PARENTDC affects? Any insight would be appreciated... Thanks much, G. Schrader

July 3, 2001

Re: Win16 problems

by Gerard Patel

At 02:58 AM 03/07/2001 +0200, you wrote: >Is it just me, or does no Win16 GUI apps work in the current Wine CVS? If >Wine is compiled with --enable-opengl, then we get BadMatch errors in >X_CreateWindow (some kind of visual mismatch), If I disable the OpenGL >visual, then the windows are created and seem to exist, but they're never >drawn. > >Win32 apps work fine, of course. For me Win16 apps have not more problems than Win32 ones. Word viewer 16 bits has one regression with current Cvs vs say one month ago, a focus problem that is occuring only in managed mode. Other than that, it is starting and loading files, either on my old computer with Xfree 3.3 and on my newer one with Xfree 4 (compiled with --enable-opengl) I still run most of my test apps on the old computer, but none of them crashes and the new redrawing problems are less than what you say. IMO Wine behaviour depends more now on the specific X server and window manager. I use Kde on both computers, btw (1.1.1 and 2.1 respectively) Gerard

July 3, 2001

Win16 problems

by Ove Kaaven

Is it just me, or does no Win16 GUI apps work in the current Wine CVS? If Wine is compiled with --enable-opengl, then we get BadMatch errors in X_CreateWindow (some kind of visual mismatch), If I disable the OpenGL visual, then the windows are created and seem to exist, but they're never drawn. Win32 apps work fine, of course. I could probably look into the OpenGL problem if that was the only problem, but why are Win16 windows never drawn anyway? (Unfortunately, I don't have sol.exe here, I tested with MS Word Viewer 16-bit, but DOS apps like Monkey Island gets the same issues in my tree)

July 3, 2001

Re: dead lock

by Alexandre Julliard

eric pouech <eric.pouech(a)wanadoo.fr> writes: > let's assume fixing it is now on Alexandre's TODO list ;-) Yes, I'll fix it, thanks for the report. You'll have to wait a bit though, as I will be away most of the week. -- Alexandre Julliard julliard(a)winehq.com

July 3, 2001