Le vendredi 11 fÃvrier 2005 Ã 16:26 -0500, Tom a Ãcrit :
> Holly Bostick wrote:
> > Placing applications such as those in a position of prominence not
> > only gives users useful information and reassures them, but also
> > reveals that you have done something *hard* to both the knowledgeable
>
Hi,
Sorry for the sincerity, but I am finding bad idea this to mix the
translations.
My suggestion is to create a new archive for the variation (Ptg.rc or
Pt_pt.rc, etc).
Thanks for attention.
Alexandre Julliard escreveu:
ChangeSet ID: 16040
CVSROOT:/opt/cvs-commit
Module name:wine
Thank you Tom.
Changelog:
-Correct time zone for BRT and BRST.
-Better explained fixme.
Tom escreveu:
Marcelo Duarte wrote:
Uwe Bonnes escreveu:
"Marcelo" == Marcelo Duarte <[EMAIL PROTECTED]> writes:
Marcelo> Hi, In my system/language I see some messages:
Marcelo> fixme:ntdll:TIM
#1 doesn't work at all, is that right? Or does it work with hardware
accel sound?
Sound is OK when doing hardware acceleration but the game
is unplayable because it's running way slower than real time because
the loader and server are using 90+% of the CPU.
Hmm. This is very interesting; I may
Jeremy White wrote:
Could you recap this for me? Afaik, we have 4 cases:
1) Current CVS tip
2) With a hack to kill the yield in wait timeouts
3) With my experimental priority adjustor
4) Behavior last fall before I started messing around.
So, #4 worked well with NFS3, in both modes?
c
>
> Unfortunately, Myst appears to only work under Wine
> with rather old
> kernels. It works fine for me on RH7.3, kernel
> 2.4.18, as long as I back
> out that mmtime patch. But Myst fails to work on
> RH9, kernel 2.4.20, for
> reasons unrelated to the mmtime patch. However, it
> fails after
Ok, it looks like dsound is causing problems, or at
the very least least alsa.
I've put the time.c stuff into it's own critical
section, to no effect.
I've also been getting a 'dead lock' with the critical
section pdbi->mmap_crst, but it's not really a dead
lock because the holding thread is ze
On Sun, 2005-02-13 at 13:52, Rein Klazes wrote:
> On 12 Feb 2005 20:42:37 +0100, you wrote:
>
> > Nick Hornback <[EMAIL PROTECTED]> writes:
> >
> > > Alright, this is probably the last time I will bring
> > > it up before I realize that there is essentially no
> > > interest in fixing this, but t
On Sun, 13 Feb 2005 20:48:49 +0100, Joris Huizer <[EMAIL PROTECTED]> wrote:
> Maxime Bellengé wrote:
> > Hello,
> >
> > Has anybody managed to minimize a window in managed mode since this
> > patch ?
> > Maximizing and restoring a window works but minimizing does not work,
> > the window minimizes
Jeremy White wrote:
I'll just mention that, assuming you are referring to this patch:
http://cvs.winehq.org/patch.py?id=14198
it also causes a regression in Myst. Though I am not convinced the fault
is in the patch, rather than the patch exposing some other problem.
Would you mind trying my exper
Maxime Bellengé wrote:
Hello,
Has anybody managed to minimize a window in managed mode since this
patch ?
Maximizing and restoring a window works but minimizing does not work,
the window minimizes and then reopen itself immediately.
I doubt it is a problem with my window manager (metacity), howev
Maxime Bellengé wrote:
Hello,
Has anybody managed to minimize a window in managed mode since this
patch ?
Maximizing and restoring a window works but minimizing does not work,
the window minimizes and then reopen itself immediately.
I doubt it is a problem with my window manager (metacity), howev
I've found a wierd bug in keyboard handling. The problem is that wine
doesn't seem to correctly translate key board messages. The program
receives WM_KEYDOWN VK_NUMPAD2 and WM_KEYUP VK_DOWN(really bad).
I've traced the bug to dlls/x11drv/keyboard.c. Apparently
EVENT_event_to_vkey correctly convert
Hello,
Has anybody managed to minimize a window in managed mode since this
patch ?
Maximizing and restoring a window works but minimizing does not work,
the window minimizes and then reopen itself immediately.
I doubt it is a problem with my window manager (metacity), however I
tried all this af
Dimitrie O. Paun wrote:
On Sat, Jan 22, 2005 at 01:19:35PM -0800, Dan Dennison wrote:
So as a service to the Wine community I plan to document the process of
building libmfc as part of my master's project. Although the MFC is not the
focus of this project, porting of it is a requirement for the
On Sun, 13 Feb 2005 10:31:12 +0100, you wrote:
> With one inline asm-statement this function would smaler and faster.
You are underestimating what compilers can do.
Filling some Gigabytes with your patch
(gcc 3.4, optimization -O2):
real0m32.037s
user0m29.584s
sys 0m0.051s
Origina
On Sun, 13 Feb 2005 13:43:34 +0100, you wrote:
> Rein Klazes wrote:
>
> >Hi,
> >
> >FrameRgn paints a frame around a region, the frame should be painted on
> >the inside of the edges, not the outside as it does now.
> >
> >
> It's a shame that we're duplicating work all over again :-(
> http://
"Carlos Lozano" <[EMAIL PROTECTED]> wrote:
> The patch:
> http://www.winehq.org/hypermail/wine-cvs/2004/06/0104.html
>
> Log message:
> Dmitry Timoshkov <[EMAIL PROTECTED]>
> Do nothing in ShowWindow(SW_SHOW) if a window is already visible.
>
> Causes regression in the game "Braveheart". The
Hello,
The patch:
http://www.winehq.org/hypermail/wine-cvs/2004/06/0104.html
Log message:
Dmitry Timoshkov <[EMAIL PROTECTED]>
Do nothing in ShowWindow(SW_SHOW) if a window is already visible.
Causes regression in the game "Braveheart". The intro was
working before of the patch, now it free
On 12 Feb 2005 20:42:37 +0100, you wrote:
> Nick Hornback <[EMAIL PROTECTED]> writes:
>
> > Alright, this is probably the last time I will bring
> > it up before I realize that there is essentially no
> > interest in fixing this, but this has been bothering
> > me for quite some time now. A few o
Rein Klazes wrote:
Hi,
FrameRgn paints a frame around a region, the frame should be painted on
the inside of the edges, not the outside as it does now.
It's a shame that we're duplicating work all over again :-(
http://www.winehq.org/hypermail/wine-patches/2004/06/0250.html
Dietrich Teickner wrote:
With one inline asm-statement this function would smaler and faster.
Nobody is really going to notice the difference this brings, almost no
real code uses Rtl* functions (programs, not Windows dlls), and you're
making a maintence problem by adding assembly code which depe
With one inline asm-statement this function would smaler and faster.
And the comment for
* ulCount [I] Number of bytes to write
need change.
And one question,
How can I start ntdll_test.exe.so in wine ?
Dietrich
/*
* RtlFill
23 matches
Mail list logo
