If DGA is not available, Wine falls back to creating offscreen primary surface
and blitting all changes to the screen. It knows which part of the surface
might have changed by watching unlock calls.
However, as Jukka Heinonen pointed out in his message posted on 17.10.2001,
the update logic in
Frank Schruefer wrote:
(
REPOST, again: I was told that my massages need long time to appear because
I'm not subscribed as [EMAIL PROTECTED], ok, but my postings as
[EMAIL PROTECTED] (which I'm subscribed as) never come through.
Maybe that is because mozilla only allows configuration for one outgoi
Frank Schruefer wrote:
(
REPOST, again: I was told that my massages need long time to appear because
I'm not subscribed as [EMAIL PROTECTED], ok, but my postings as
[EMAIL PROTECTED] (which I'm subscribed as) never come through.
Maybe that is because mozilla only allows configuration for one outgoi
Hi:
The variable value is:
[EMAIL PROTECTED] root]# echo $LANG
en_US.UTF-8
Regards
-- Original Message ---
From: Hans Leidekker <[EMAIL PROTECTED]>
To: Mike Hearn <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], jds <[EMAIL PROTECTED]>
Sent: Tue, 20 Jan 2004 22:06:55 -0500
Subj
"Jon Griffiths" <[EMAIL PROTECTED]> wrote:
> Dmitry, this should fix the test failing on your Win2K box also. If
> it doesn't please let me know.
A failure I reported is fixed now. Thanks!
--
Dmitry.
(
REPOST, again: I was told that my massages need long time to appear because
I'm not subscribed as [EMAIL PROTECTED], ok, but my postings as
[EMAIL PROTECTED] (which I'm subscribed as) never come through.
Maybe that is because mozilla only allows configuration for one outgoing
mailserver which is
Eric Pouech wrote:
Any ideas?
as an ugly hack, does setting the dwEventCount in the WINE_MCIAVI struct
as volatile help ? (private_mciavi.h).
No, that didn't help, the one below does:
Mike
diff -u -r1.1.1.10 mciavi.c
--- dlls/winmm/mciavi/mciavi.c 10 Jan 2004 00:11:58 - 1.1.1.10
+++ d
"Alexandre Julliard" <[EMAIL PROTECTED]> wrote:
> Log message:
> Aric Stewart <[EMAIL PROTECTED]>
> Use X11 XIM callbacks to enable full IME support.
> Correct some timing issues with XIM input.
> Start to provide the framework for the MSIME messages.
> langid = PRIMARYLANGID(LANGIDFROMLCID(
Blake Leverett <[EMAIL PROTECTED]> writes:
> Index: dlls/wineps/ps.c
> ===
> RCS file: /home/wine/wine/dlls/wineps/ps.c,v
> retrieving revision 1.23
> diff -u -r1.23 ps.c
> --- dlls/wineps/ps.c 8 Dec 2003 21:40:27 - 1.23
>
Mike Hearn wrote:
Ah yes, exponentially scalable growth. Let's hope so. Graphs of cvs
commits/patch sizes would be neat. I might stick that on my (long) todo
list :)
Here is one, http://www.winehq.org/hypermail/wine-devel/2001/11/0149.html
(Wine source code size) its two years old but it's still n
Hi:
The variable value is:
[EMAIL PROTECTED] linux-2.6.1]# echo $LANG
en_US.UTF-8
Regards
-- Original Message ---
From: Hans Leidekker <[EMAIL PROTECTED]>
To: Mike Hearn <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], jds <[EMAIL PROTECTED]>
Sent: Tue, 20 Jan 2004 22:06:55 -0500
Changelog:
- implemented SHGetRealIDL()
Index: pidl.c
===
RCS file: /home/wine/wine/dlls/shell32/pidl.c,v
retrieving revision 1.96
diff -u -p -d -r1.96 pidl.c
--- pidl.c 18 Jan 2004 22:08:46 - 1.96
+++ pidl.c 20 Ja
On Tuesday 20 January 2004 11:02, Francois Gouget wrote:
> Arg. Spoke a bit too quick in my previous email. This patch introduces a
> new problem. When verifying the generated.c files I see a lot of diffs
Well, it merely uncovers two more cases of reference variable
misuse. Revised patch attached
On Tuesday 20 January 2004 15:28, Mike Hearn wrote:
> I've carbon copied this to wine-devel. This looks like some
> charset/toolchain issue, but I'm not sure how to diagnose it. This is on
> Fedora Core 1 yes? What is the output of
>
> echo $LANG
You're right. It's sed becoming locale aware in FC
Hi,
I've carbon copied this to wine-devel. This looks like some
charset/toolchain issue, but I'm not sure how to diagnose it. This is on
Fedora Core 1 yes? What is the output of
echo $LANG
at the command prompt? Maybe one of our charset experts (hi dmitry! :)
knows what's up.
thanks -mike
On T
On Tue, 2004-01-20 at 19:56, Jeremy White wrote:
> Further, note that I
> didn't say it would run 95% of all apps *perfectly*. That, I
> think, is too much.
Ah. The small print comes out ;)
> I think back to 23 months ago when Wine barely could run MS Office,
Was it really only two years ago? A
> "We are confident that Wine has matured to the point that CrossOver will
> run 95% of all Windows applications by the end of 2005."
>
> Uh, guys, are you sure that isn't over-optimistic? I mean, it seems that Wine is
> moving
> faster than ever before and that's great, but do you have any
> har
--- Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> No, I still think there is value in building the tests with different
> import libs to spot problems. We'll just need to work around the
> broken comctl32.
While we are at it can we work around the broken msvcrt problems in
mingw?
"../../../dlls
Mike McCormack a écrit :
Hi Eric,
After implementing the ICCVID codec, the intro AVI in Half-Life plays
nicely, however when it finishes, WinMM gets stuck in a loop while
cleaning up in MCIAVI_mciPlay.
I think it's trying to wait for the sound to finish, however I'm not
sure how to fix the pro
Hiya,
> We've also, we hope, set the stage for a major new Wine
> related initiative - we hope to encourage lots of ISVs
> to certify their apps against Wine.
Yes this is REALLY needed but.
> The rationale for this is pretty simple - apps won't run
> on Wine as well as they do on Windows
"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes:
> I think that we need to switch to using Wine import libraries for MinGW
> compiled tests. I sent a patch for that, but it was rejected. Alexandre,
> taking into account the stance of MinGW maintainers probably it's time
> to refuse to use (broken) M
On Tue, 20 Jan 2004 08:05:32 -0600, Jeremy Newman wrote:
> We've also, we hope, set the stage for a major new Wine related
> initiative - we hope to encourage lots of ISVs to certify their apps
> against Wine.
Cool! But.
"We are confident that Wine has matured to the point that CrossOver will
Dmitry Timoshkov wrote:
By pushing the limits on "clean room" development of the w32api, we
jeopardise not only the mingw project but also other projects - cygwin,
Watcom - that seek to provide tools mainly for ordinary developers (who
get no value from having DPA_Clone and friends exposed in the
Hi Eric,
After implementing the ICCVID codec, the intro AVI in Half-Life plays
nicely, however when it finishes, WinMM gets stuck in a loop while
cleaning up in MCIAVI_mciPlay.
I think it's trying to wait for the sound to finish, however I'm not
sure how to fix the problem. The patch below ma
"Jakob Eriksson" <[EMAIL PROTECTED]> wrote:
> It is all a matter of crosscompiling conformance tests with mingw.
I think that we need to switch to using Wine import libraries for MinGW
compiled tests. I sent a patch for that, but it was rejected. Alexandre,
taking into account the stance of MinGW
Hi,
> Im not sure if I understand you,
> Im using the current CVS version of oleaut32.
I think you'll find its the native dll thats failing. I'll be
resyncing again today though, so I'll check nothings changed to break
builtin.
Cheers,
Jon
=
"Don't wait for the seas to part, or messiahs to
On Tue, 20 Jan 2004, Hans Leidekker wrote:
[...]
> That code is mixing up the use of a variable holding a string
> and a variable holding a reference. Put otherwise it forget's
> to dereference a scalar ref (similar to a C pointer variable)
> before using it. Patch below fixes it.
Arg. Spoke a bit
On Tue, 20 Jan 2004, Hans Leidekker wrote:
> On Tuesday 20 January 2004 14:09, Francois Gouget wrote:
>
> > include/winuser.h: DWORD[CCHILDREN_TITLEBAR+1]: can't parse type
> > ('DWORD') ('CCHILDREN_TITLEBAR+1')
> > Can't use string ("4") as a SCALAR ref while "strict refs" in use at
> > tools/win
"Fabian Cenedese" <[EMAIL PROTECTED]> wrote:
> Ahmm... I don't have keyboard problems, just out of curiosity: Would it speed
> up wine starting if the keyboard was configured fixed and wine wouldn't have
> to test all possible layouts?
You could try it by leaving only single layout in the global
On Tuesday 20 January 2004 14:09, Francois Gouget wrote:
> include/winuser.h: DWORD[CCHILDREN_TITLEBAR+1]: can't parse type
> ('DWORD') ('CCHILDREN_TITLEBAR+1')
> Can't use string ("4") as a SCALAR ref while "strict refs" in use at
> tools/winapi/c_type.pm line 283.
That code is mixing up the use
"Hans Leidekker" <[EMAIL PROTECTED]> wrote:
> > Do they consider a "reverse engineering" running
> > 'dumpbin /exports comctl32.dll' ?
>
> Here's the answer I got from Danny Smith back in October last year:
>
> > The only ways you can determine the ordinal alias in absence of
> > documentation i
>From the desk of Jeremy White (who is at LinuxWorld ATM).
Hey folks,
We've just launched a major new initiative, the
CodeWeavers CrossOver Compatibility Center.
You can check it out at
http://www.codeweavers.com/site/compatibility/
but I think it's fair to describe it as the appdb
on steroids
When I run ./tools/winapi/winapi_test it chokes on the TITLEBARINFO
declaration in winuser.h:
typedef struct tagTITLEBARINFO {
DWORD cbSize;
RECT rcTitleBar;
DWORD rgstate[CCHILDREN_TITLEBAR+1];
} TITLEBARINFO, *PTITLEBARINFO, *LPTITLEBARINFO;
include/winuser.h: DWORD[CCHILDREN_TIT
On Tuesday 20 January 2004 10:19, Dmitry Timoshkov wrote:
> Do they consider a "reverse engineering" running
> 'dumpbin /exports comctl32.dll' ?
Here's the answer I got from Danny Smith back in October last year:
> The only ways you can determine the ordinal alias in absence of
> documentation i
>That shouldn't happen. Keyboard detection code always does a full round
>of comparisons with every keyboard table in x11drv.
Ahmm... I don't have keyboard problems, just out of curiosity: Would it speed
up wine starting if the keyboard was configured fixed and wine wouldn't have
to test all poss
"Hans Leidekker" <[EMAIL PROTECTED]> wrote:
> Yes, I know those are documented nowadays. MinGW has prototypes for
> those functions, no problem with that. It's the bit of information
> that says that DPA_Create (and previously the other functions) is
> exported as ordinal 328, and exported ordinal
On Monday 19 January 2004 20:46, Martin Fuchs wrote:
> You are searching for documentation of DPA_Create() and DPA_Search() ?
> Herer it is:
[MSDN links]
Yes, I know those are documented nowadays. MinGW has prototypes for
those functions, no problem with that. It's the bit of information
that sa
--- Jon Griffiths <[EMAIL PROTECTED]> a écrit :
> >Running the oleaut32 tests shows that vartype and vartest are
failing.
> >Has someone an idea about these ?
>
> Your (presumably early) version of oleaut32.dll doesn't support the
> VT_DECIMAL type. I'll update the tests shortly.
Im not sure if
38 matches
Mail list logo
