I wasn't able to find any documentation on how the detection works in /documentation. Something is lacking as ie6 setup runs fine if if a version is set and complains about not having a current windows version if not. It might be reading a key that doesn't exist by default, maybe //software//microsoft//windows nt//current version although I didn't capture the trace after I set [Version].
Chris
>
> From: Andreas Mohr <andi(a)rhlx01.fht-esslingen.de>
> Date: 2002/10/01 Tue AM 03:39:52 EDT
> To: Chris Morgan <cmorgan(a)alum.wpi.edu>
> CC: wine-devel(a)winehq.com
> Subject: Re: [Version] in ~/.wine/config
>
> On Mon, Sep 30, 2002 at 10:20:58PM -0500, Chris Morgan wrote:
> > Any reason why we don't default the windows version to something recent like
> > Win2K and let the user change this to an older version if necessary?
> As has been said some times before, this value is a *forced* value,
> which thus overrides Wine's version detection mechanism in case no value is
> forced.
> IOW: a bad thing to do per default.
>
> --
> The Declaration of Software Freedom:
> http://freedevelopers.net/freedomdec/index.php
>
>
>
Hi folks,
Some time ago I reported a drawing problem that appeared often
in the Common Control Spy. The reason it happens there, is that
that application has a listbox which lists messages, and notification
received/sent by the control. Well, this listbox scrolls
automatically (quite fast at that) as there are quite a few
messages/notifications sent, and if you obstruct it partially
with a dialog box that you drag around, you can easily replicate
the bug.
What happens is that a part of the dialog's caption is scrolled up,
and not erased. I've attached a snapshot of the problem -- please
take a look at it.
I was thinking about it, and I think I know what the problem is:
1. you drag the dialog box down
2. this invalidates a portion of the listbox (this invalidated
portion contains part of the old caption of the dialog)
3. for whatever reason, the listbox gets new items, and is
scrolled (using ScrollWindowEx), *before* it gets a
WM_ERASEBKGND/WM_PAINT message.
4. ScrollWindowEx scrolls the content of the window *including*
the invalidated area which contains the portion of the caption.
*5. ScollWindowEx fails to extend the "scroll" update the portion
of the update region (wndPtr->hrgnUpdate).
As you can see, the bug happens at step5. That is, if we scroll a
rectangle that intersects the update region, we have to "scroll"
the update window as well (in the portion that it intersects).
For example, say we have a simple update region: [0,50,100,100],
and we scroll the rectangle [0,0,100,60] by 30 units up,
we have to end up with an update region of [0,20,100,100].
I don't think that we do, right now.
Can anyone familiar with the code (dlls/x11drv/scroll.c) take
a look, and see what's going on?
--
Dimi.
Any reason why we don't default the windows version to something recent like
Win2K and let the user change this to an older version if necessary?
Chris
Hello All,
Unfortunately I need to stop most of my work on Wine. This is due to family
demands and also that it is not fun anymore.
I would recommend that Dimitrie Paun to take over the Common Controls. He has
done a great deal of work on them and deserves the honor.
I may continue to "lurk" on the lists but do not forsee any activity.
Good luck all, and thanks for the friendship.
Guy Albertelli <<galberte(a)neo.lrun.com>>
----- Original Message -----
From: "Eric POUECH" <Eric.Pouech(a)wanadoo.fr>
To: <wine-devel(a)winehq.com>
Sent: Monday, September 30, 2002 2:27 AM
Subject: Re: Add support for CCSelect sound
> >Objet : Add support for CCSelect sound
> Hi Guy,
>
> I wonder if a call to
> WCHAR name[] = { 'C','C','S','e','l','e','c','t','\\','.','c','u','r','r','e','n','t',0};
>
> PlaySound(name, 0, SND_ALIAS|SND_ASYNC);
> wouldn't do the trick (didn't check it, but it's very likely it's gonna work). I can't test it (I'm away from my home PC will all
my wine env)
> A+
I don't know. I merely reproduced the calls I saw in the relay trace (after removing all the MultiByteToWide junk).
I figured that doing similar calls should reproduce the same behavior (good or bad).
Guy
Hi,
I noticed recently that Wine was able to do anti-aliasing for font sizes >16
although my Gnome 2 looked nice with anti-aliasing of <16. I started to
look why Wine apps were only anti-aliased for >16, and I came across this:
--- dlls/x11drv/xrender.c.orig 2002-09-29 12:56:27.000000000 +0200
+++ dlls/x11drv/xrender.c 2002-09-29 12:56:56.000000000 +0200
@@ -322,7 +322,7 @@
assert(entry->nrealized == 0);
- if(antialias && abs(plfsz->lf.lfHeight * plfsz->xform.eM22) > 16) {
+ if(antialias && abs(plfsz->lf.lfHeight * plfsz->xform.eM22) > 8) {
pf.depth = 8;
pf.direct.alphaMask = 0xff;
} else {
When I changed this, my Notes was much nicer to work with. I presume there
is a reason why anti-aliasing was off, but I would reconsider that
decision. You can look for yourself on these 2 screenshots:
http://dag.wieers.com/Screenshot-2.pnghttp://dag.wieers.com/Screenshot-3.png
Especially look at the widgets.
Thanks for your feedback, (please Cc: because I'm not subscribed)
-- dag wieers, dag(a)wieers.com, http://dag.wieers.com/ --
«Any errors in spelling, tact or fact are transmission errors»
> Look reasonable?
No. Command tail is not null terminated so you
cannot use strlen. DOS exec function "load and exec"
is synchronous so you should return to caller only
after created process has finished. In addition
to hFile lead found by Ove Kaaven, you are leaking
handles in PROCESS_INFORMATION. Using fixed size
buffer for full command line without sanity checks
is a bad idea and will cause problems sooner or later.
And, finally, you are ignoring long command lines
from DOS program stored in CMDLINE environment
variable. (I have already exchanged private email with
Chris Morgan about this; DOS programs can be passed
command tails longer than 126 characters using CMDLINE
environment variable. Similarly, DOS programs may pass
long command lines to programs they execute.)
--
Jukka Heinonen <http://www.iki.fi/jhei/>
