oses and it seems
> pretty
> stable.
> If there are no objections, I'll upload i486 and x86_64 packages and announce
> it
> in Slackaware related communities asking for reviews / regressions.
>
On the Ubuntu side this isn't going to happen until Maverick due to
changes i
.1.44 for testing purposes and it seems
> pretty
> stable.
> If there are no objections, I'll upload i486 and x86_64 packages and announce
> it
> in Slackaware related communities asking for reviews / regressions.
openSUSE Factory which will become openSUSE 11.3 contains this setup a
d i486 and x86_64 packages and announce it
in Slackaware related communities asking for reviews / regressions.
Bye
Simone
> On Sun, Jun 13, 2010 at 10:00 AM, James McKenzie
> wrote:
> >> How close are we to release? Maybe it'd be worth
> >> it to publicise the upcomi
ing new that is easy to fix for 1.2.
It's a little late for that. At this point we need to concentrate on
bugs that affect real applications, and preferably regressions.
--
Alexandre Julliard
julli...@winehq.org
Nikolay Sivov wrote:
> ... it would
> be nice to have valgrind tests logs as you did some months ago.
> I think it's possible to catch something new that is easy to fix for 1.2.
You're right. I'll try to find them time to fire that up again.
On 6/13/2010 18:53, Dan Kegel wrote:
How close are we to release?
Not closely related to a beta testing, but for quality it is - it would
be nice to have valgrind tests logs as you did some months ago.
I think it's possible to catch something new that is easy to fix for 1.2.
On Sun, Jun 13, 2010 at 10:00 AM, James McKenzie
wrote:
>> How close are we to release? Maybe it'd be worth
>> it to publicise the upcoming wine release by
>> flogging rc3 in various news sites and getting more people to
>> look for regressions.
>
> +1.
OK,
Edward Savage wrote:
On Mon, Jun 14, 2010 at 12:53 AM, Dan Kegel wrote:
How close are we to release? Maybe it'd be worth
it to publicise the upcoming wine release by
flogging rc3 in various news sites and getting more people to
look for regressions.
If it's still a coupl
Dan Kegel wrote:
How close are we to release? Maybe it'd be worth
it to publicise the upcoming wine release by
flogging rc3 in various news sites and getting more people to
look for regressions.
+1. I'm getting a fresh git and fixing/running and then submitting the
EM_FORMATRAN
On Mon, Jun 14, 2010 at 12:53 AM, Dan Kegel wrote:
> How close are we to release? Maybe it'd be worth
> it to publicise the upcoming wine release by
> flogging rc3 in various news sites and getting more people to
> look for regressions.
>
If it's still a couple of wee
How close are we to release? Maybe it'd be worth
it to publicise the upcoming wine release by
flogging rc3 in various news sites and getting more people to
look for regressions.
The thread about Wylda's statistics reminded me about
http://wiki.winehq.org/PlatinumRegressionHunt
We ment
On Sunday 23 August 2009 00:17:23 Austin English wrote:
> On Fri, Aug 21, 2009 at 11:17 PM, F Capela wrote:
> > I use Wine mostly to play World of Warcraft and I've had a regression in
> > World of Warcraft (when running fullscreen inside a virtual desktop and
> > using the opengl renderer) with pa
On Fri, Aug 21, 2009 at 11:17 PM, F Capela wrote:
> I use Wine mostly to play World of Warcraft and I've had a regression in
> World of Warcraft (when running fullscreen inside a virtual desktop and using
> the opengl renderer) with patches from the last two weeks:
>
> - Patch 12d1ff8ef6c34533a20
I use Wine mostly to play World of Warcraft and I've had a regression in World
of Warcraft (when running fullscreen inside a virtual desktop and using the
opengl renderer) with patches from the last two weeks:
- Patch 12d1ff8ef6c34533a20008f4cfeb73ee4c601a5d (winex11: Add handling of take
focus
Rein Klazes wrote:
> On Sat, 15 Aug 2009 10:46:19 -0700, you wrote:
>
>> 14 months seems to be more than reasonable to repair a regression. I'm
>> worried about having to forever maintain a separate installation of
>> Wine just to use this program. I'll be happy to test further if
>> someone is go
On Sat, 15 Aug 2009 10:46:19 -0700, you wrote:
>
>14 months seems to be more than reasonable to repair a regression. I'm
>worried about having to forever maintain a separate installation of
>Wine just to use this program. I'll be happy to test further if
>someone is going to work on this bug but r
t the
regression will cause new regressions - directly working on the big fix as
time permits is usually better.
There are surely some exceptions to this etc and I guess I left some easier
regressions I caused untouched because I simply lost track of them. Every
now and then they get randomly fix
I can't speak for the rest of developers, but for me bugs become a priority if:
* They are regressions caused by a patch that I wrote.
* They are in an area that I know well (gdiplus, windowscodecs,
explorer/appbar.c).
* CodeWeavers, my employer, decides that they should.
There are only
d, this is not really a regression, but rather a
>redesign which have caused the application to fail to install.
I would not weigh Perrys problem against mine(not that I think CSx are
low-profile apps), but rather say that regressions seems to be more ok when the
cause is a redesign, and not wh
Matt Perry wrote:
> When do regressions become high priority for developers?
> [SecureCRT broke with wine-0.9.54,
> http://bugs.winehq.org/show_bug.cgi?id=13583 ]
> 14 months seems to be more than reasonable to repair a regression.
That's a tough question.Note that Photoshop
When do regressions become high priority for developers? I ask because
I opened bug 13583 over 14 months ago, provided all the information
requested, as did other people, and nothing has happened. The program
worked with Wine 0.9.53 but has been broken since then.
I have continued to test the
Dan Kegel wrote:
> On Sun, Jan 11, 2009 at 11:12 AM, Jacek Caban wrote:
>
>>> Hmm, can we have a debug version of the gecko download
>>> so we can give more useful backtraces?
>>>
>> We already have it, it's on SourceForge. To use it you have to replace
>> existing Wine Gecko installatio
On Sun, Jan 11, 2009 at 11:04:32AM -0800, Dan Kegel wrote:
> I've been doing some random qa of popular apps lately, and
> think I've found some regressions caused by the gecko update:
> http://bugs.winehq.org/show_bug.cgi?id=16869 - Sketchup 7 crashes when
> bringing
On Sun, Jan 11, 2009 at 11:36 AM, Dan Kegel wrote:
> Thanks, I updated http://wiki.winehq.org/Gecko with that info.
> I see a more verbose log, but sadly, backtraces in
> xul crashes are still not symbolic.
WINEDEBUG=+gecko seems to turn on assertions in gecko.
Can you add a note about that in th
On Sun, Jan 11, 2009 at 11:12 AM, Jacek Caban wrote:
>> Hmm, can we have a debug version of the gecko download
>> so we can give more useful backtraces?
>
> We already have it, it's on SourceForge. To use it you have to replace
> existing Wine Gecko installation in c:\windows\gecko\0.9.0 or replac
Dan Kegel wrote:
> I've been doing some random qa of popular apps lately, and
> think I've found some regressions caused by the gecko update:
> http://bugs.winehq.org/show_bug.cgi?id=16869 - Sketchup 7 crashes when
> bringing up 3d Warehouse
> http://bugs.winehq.org/show
I've been doing some random qa of popular apps lately, and
think I've found some regressions caused by the gecko update:
http://bugs.winehq.org/show_bug.cgi?id=16869 - Sketchup 7 crashes when
bringing up 3d Warehouse
http://bugs.winehq.org/show_bug.cgi?id=16892 - Yahoo Messenger 8.1
cra
On Thu, May 15, 2008 at 3:33 AM, Dmitry Timoshkov
<[EMAIL PROTECTED]> wrote:
> The culprit is:
>
> 4046075462c00f4479f185d1c0514584ff851223 is first bad commit
> commit 4046075462c00f4479f185d1c0514584ff851223
> Author: Andrew Talbot <[EMAIL PROTECTED]>
> Date: Tue May 13 22:41:58 2008 +0100
>
>
"Dmitry Timoshkov" <[EMAIL PROTECTED]> wrote:
> "Dan Kegel" <[EMAIL PROTECTED]> wrote:
>
>> Hmm. I just tried running Photoshop CS2 trial and Photoshop 5.5 trial,
>> and both failed on current wine.
>>
>> CS2 complained "not enough DOS memory",
>> and 5.5 complained
>> lcms: Error #12288; Too m
"Dan Kegel" <[EMAIL PROTECTED]> wrote:
> Hmm. I just tried running Photoshop CS2 trial and Photoshop 5.5 trial,
> and both failed on current wine.
>
> CS2 complained "not enough DOS memory",
> and 5.5 complained
> lcms: Error #12288; Too many tags (2025813777)
>
> PS6 works, though.
This looks
Hmm. I just tried running Photoshop CS2 trial and Photoshop 5.5 trial,
and both failed on current wine.
CS2 complained "not enough DOS memory",
and 5.5 complained
lcms: Error #12288; Too many tags (2025813777)
PS6 works, though.
gt; > 13101 - not a regression
> > 13086 - not sure if it's always existed or a regression. I asked for
> > clarification.
> >
> > If anyone can identify regressions that haven't been bisected, shoot
> > me an e-mail. I've got plenty of CPU/time to kill.
&
test. I've requested it now.
>>> 13101 - not a regression
>>> 13086 - not sure if it's always existed or a regression. I asked for
>>> clarification.
>>>
>>> If anyone can identify regressions that haven't been bisected, shoot
>>>
unmovable schedule is also a mistake, imho;
you want to release when you feel you have something of solid value.
It should not be the case that a large block of conventional wisdom
has it that 0.9.58 is 'better' than 1.0.
Obvious and large blocks of regressions are a valid show stopper,
On Mon, May 12, 2008 at 9:48 PM, Marcel Partap <[EMAIL PROTECTED]> wrote:
> Attracting users by promising a major step forward - a finished x.0 release
> - that don't already come to wine by other means may backfire - a zillion
> useless bug reports, fed up newbies, many 'ruined' first-foss-contac
> but you might kill yourself as well. We need to do what you said, test
> Wine before releasing to the public. However, this is not possible
> given the aggressive release schedule of the project.
Why is that so? I still do not see any benefit in calling it wine 1.0 at this
time. What is th
easing to the public. However, this is not possible
> given the aggressive release schedule of the project. So, we have to
> fix what we can and leave the rest until later.
>
The purpose of the aggressive release schedule is exactly so that we
get more testing exposure and regression
Vitaliy Margolen wrote:
> Dan Kegel wrote:
>
>> I'm not sure what you're angry about.
>> None of us have that much control over exactly
>> which way wine develops. We all scratch our own itches,
>> and it improves at its own pace.
>> What more do you want?
>>
>
> Stability. For things to c
Am Sonntag, 11. Mai 2008 05:35:15 schrieb James McKenzie:
> I agree that a D3D expert needs to fix this problem, pronto. However,
> I'm not one of them and it looks like at least one of them proposed a
> fix in the issue.
Fyi, I am terribly busy at the moment with university work, I have a bunch o
Am Montag, 12. Mai 2008 14:29:40 schrieb Vitaliy Margolen:
> Stability. For things to continue working once they get fixed. Which means
> more developers have to "support" their changes - promptly address all
> issues that result from their changes. IMHO this is the way project should
> be moving f
James McKenzie schrieb:
> Vitaliy Margolen wrote:
>> James McKenzie wrote:
[...]
> Again, do we have enough time to test every combination of products in
> the short release to release schedule. I would say NO. However, this
> schedule is not of my doing. My saying "Release no software before
Dan Kegel wrote:
> I'm not sure what you're angry about.
> None of us have that much control over exactly
> which way wine develops. We all scratch our own itches,
> and it improves at its own pace.
> What more do you want?
Stability. For things to continue working once they get fixed. Which mean
Vitaliy wrote:
>> To get lots more people to try it and report bugs, so it can improve faster.
>This is questionable. I can point to several bug reports that have several
>dozen people reporting problems and that are still open for years. So just
>saying more bug reports results into better Wine is
Dmitry Timoshkov wrote:
> "Vitaliy Margolen" <[EMAIL PROTECTED]> wrote:
>
>> For most people yeah it will be a surprise. Until they hit first major
>> problem. Which will put them back into windows land. You see there are
>> much more people out there that use PCs as ... tools. Those tools
>> e
clarification.
>
> If anyone can identify regressions that haven't been bisected, shoot
> me an e-mail. I've got plenty of CPU/time to kill.
I'd appreciate it if you can do a regression testing for bug 12272? Game
blood 2 with demo. Between wine-0.9.44 and wine-0.9.45. Y
"Vitaliy Margolen" <[EMAIL PROTECTED]> wrote:
> For most people yeah it will be a surprise. Until they hit first major
> problem. Which will put them back into windows land. You see there are much
> more people out there that use PCs as ... tools. Those tools either work or
> they don't. Wine j
Vitaliy Margolen wrote:
> James McKenzie wrote:
>
>> There were several 'fixes' to this problem in the issue. And Stephan
>> continues to troubleshoot the problem. However, this is a VOLUNTEER
>> effort and most of us have 'real lives' to live. I would gladly work on
>> rich edit problems
Dan Kegel wrote:
> Marcel wrote:
>> i don't even see the point of a 1.0 release at this point in time.
>> This project has been a work in progress since 15 years.
>> Why the heck has it been decided to do a 'gold' release *now* anyways?
>
> To get lots more people to try it and report bugs, so it
Dan Kegel wrote:
> Marcel wrote:
>
>> i don't even see the point of a 1.0 release at this point in time.
>> This project has been a work in progress since 15 years.
>> Why the heck has it been decided to do a 'gold' release *now* anyways?
>>
>
> To get lots more people to try it and report
Marcel wrote:
> i don't even see the point of a 1.0 release at this point in time.
> This project has been a work in progress since 15 years.
> Why the heck has it been decided to do a 'gold' release *now* anyways?
To get lots more people to try it and report bugs, so it can improve faster.
And t
13120 - I'll run the test tomorrow if I can reproduce/no one has by then.
13110 - no one requested a regression test. I've requested it now.
13101 - not a regression
13086 - not sure if it's always existed or a regression. I asked for
clarification.
If anyone can identify regressio
On Sun, May 11, 2008 at 1:15 PM, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> "Zachary Goldberg" <[EMAIL PROTECTED]> writes:
>
>> I agree, and I'm of course not talking about reverting the entire
>> tree. Vitaliy has mentioned a few specific patches though (mostly in
>> d3d I think) which have
"Zachary Goldberg" <[EMAIL PROTECTED]> writes:
> I agree, and I'm of course not talking about reverting the entire
> tree. Vitaliy has mentioned a few specific patches though (mostly in
> d3d I think) which have caused some noise in the gaming realm.
If Vitaliy or anybody else think a patch must
. If we're _only_ concerned about those 4 listed
>> applications and those still work and the status of other regressions
>> isn't as important then we continue and leave in the regressions.
>
> The goal is to ship with as few bugs as possible, whether they are
> regr
y happened
> before
> the commitment to code freeze.
>
> But I think that testing and reverting any patches submitted during code
> freeze
> that cause d3d regressions and can't be fixed real quick is a good idea.
>
They have to be fixed. That's the point. And if it
testing and reverting any patches submitted during code freeze
that cause d3d regressions and can't be fixed real quick is a good idea.
Tom Wickline schrieb:
> Well its not only Games, if you install office 2007 NOTHING works with RC-1!
> You have to revert back to 0.9.59 for it to work the best it ever did, then
> it's all down hill from each release forward ..As it looks Wine
> 1.0 will be a huge POS..
i don't even see th
e working to make Wine 1.0 be the best at running applications that
> Wine has ever been? If so then reverting recent patches which break
> things is a good idea. If we're _only_ concerned about those 4 listed
> applications and those still work and the status of other regressions
>
Alexander Dorofeyev wrote:
> Vitaliy Margolen wrote:
>> James McKenzie wrote:
>>> Vitaliy Margolen wrote:
>>>> Several latest releases introduced lots and lots of regressions to a
>>>> point that no games run as-is. Considering that we are at the code
On Sun, May 11, 2008 at 10:58 AM, Alexander Dorofeyev <[EMAIL PROTECTED]> wrote:
> Vitaliy Margolen wrote:
>> James McKenzie wrote:
>>> Vitaliy Margolen wrote:
>>>> Several latest releases introduced lots and lots of regressions to a
>>>> point tha
Vitaliy Margolen wrote:
> James McKenzie wrote:
>> Vitaliy Margolen wrote:
>>> Several latest releases introduced lots and lots of regressions to a
>>> point that no games run as-is. Considering that we are at the code
>>> freeze, I'd like to see al
the improved DIB engine work will have a
few regressions, but that work still needs to be done for performance
reasons.
If something is not working for you, file a bug. That is the only way
to get the bugs fixed. Especially if something has regressed. Now is
the time to be testing and filing bu
at 9:07 PM, Vitaliy Margolen
<[EMAIL PROTECTED]> wrote:
> Several latest releases introduced lots and lots of regressions to a point
> that no games run as-is. Considering that we are at the code freeze, I'd
> like to see all patches that cause regressions, and all patches that
James McKenzie wrote:
> Vitaliy Margolen wrote:
>> James McKenzie wrote:
>>> Vitaliy Margolen wrote:
>>>> Several latest releases introduced lots and lots of regressions to a
>>>> point that no games run as-is. Considering that we are at the code
>
James McKenzie wrote:
> Vitaliy Margolen wrote:
>> Several latest releases introduced lots and lots of regressions to a
>> point that no games run as-is. Considering that we are at the code
>> freeze, I'd like to see all patches that cause regressions, and all
>
Vitaliy Margolen wrote:
> Several latest releases introduced lots and lots of regressions to a point
> that no games run as-is. Considering that we are at the code freeze, I'd
> like to see all patches that cause regressions, and all patches that depend
> on them starting fr
Several latest releases introduced lots and lots of regressions to a point
that no games run as-is. Considering that we are at the code freeze, I'd
like to see all patches that cause regressions, and all patches that depend
on them starting from wine-0.9.58 be reverted.
Also each patch to
//www.winehq.org/pipermail/wine-devel/2008-April/064999.html ).
> These seem like regressions that ought to be fixed
> before 1.0.
Worse still, after all of the work I've done on getting most tests
running there have been 3 new failures in make test:
setupapi/devinst.ok
devinst.c:831: T
On Sun, Apr 20, 2008 at 7:04 PM, Dan Kegel <[EMAIL PROTECTED]> wrote:
> There's been lots of progress in Wine lately; many
> important applications work better than ever.
> But the inevitable cost of such progress is that
> some applications are now broken and/or
> wine has odd problems.
Yes O
zed
( http://bugs.winehq.org/show_bug.cgi?id=12697 ),
and as of 0.9.60, the IME support seems to be
making wine apps run dog slow on at least one
of my machines
( http://www.winehq.org/pipermail/wine-devel/2008-April/064999.html ).
These seem like regressions that ought to be fixed
before 1.0.
So...
Dan Kegel wrote:
> On Sun, Mar 16, 2008 at 8:53 AM, Roderick Colenbrander
> <[EMAIL PROTECTED]> wrote:
>
>> Personally I don't trust appdb regressions much.
>
> We could work around some of the problems by only listing
> apps where the same reviewer gave it a l
On Sun, Mar 16, 2008 at 8:53 AM, Roderick Colenbrander
<[EMAIL PROTECTED]> wrote:
> Personally I don't trust appdb regressions much.
We could work around some of the problems by only listing
apps where the same reviewer gave it a lower rating in a
newer version of wine. That compe
On So, 2008-03-16 at 07:30 -0700, Dan Kegel wrote:
> want to use the appdb itself
> to see which apps have recently fallen in rating.
Nice Idea.
> Following past appdb practice, one would implement
> that by adding a new "Browse Regressions" menu
> item on the left,
I c
> Roderick Colenbrander <[EMAIL PROTECTED]> wrote:
> > A lot of users don't know how to rate apps properly and
> > even rate something as gold when half of its features
> > don't work. They even rate it gold when they have to copy
> > half a windows registry and tons of windows dlls.
>
> Agreed. W
Roderick Colenbrander <[EMAIL PROTECTED]> wrote:
> A lot of users don't know how to rate apps properly and
> even rate something as gold when half of its features
> don't work. They even rate it gold when they have to copy
> half a windows registry and tons of windows dlls.
Agreed. We need to sol
> The nice reports in recent wwn's showing changes in
> appdb ratings make me want to use the appdb itself
> to see which apps have recently fallen in rating.
>
> Following past appdb practice, one would implement
> that by adding a new "Browse Regressions" menu
The nice reports in recent wwn's showing changes in
appdb ratings make me want to use the appdb itself
to see which apps have recently fallen in rating.
Following past appdb practice, one would implement
that by adding a new "Browse Regressions" menu
item on the left, below Brow
"Dan Kegel" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi Alistair,
> I'm seeing some regressions in msxml3 in yesterday's git; see
> http://kegel.com/wine/valgrind/logs-2008-03-05/vg-msxml3_domdoc-diff.txt
> e.g.
> + Invalid read of
Hi Alistair,
I'm seeing some regressions in msxml3 in yesterday's git; see
http://kegel.com/wine/valgrind/logs-2008-03-05/vg-msxml3_domdoc-diff.txt
e.g.
+ Invalid read of size 4
+at HEAP_ValidateInUseArena (heap.c:925)
+by RtlFreeHeap (heap.c:1288)
+by SysFreeString (ol
"Austin English" <[EMAIL PROTECTED]> writes:
> In today's git, I've had a few regressions in make -k test:
>
> [EMAIL PROTECTED]:~/wine-git$ grep -i 'Test failed'
> wine-0.9.56-420-g22f146f.txt
> visual.c:1741: Test failed: double texbem
On Thu, Mar 6, 2008 at 3:36 AM, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> Am Donnerstag, 6. März 2008 05:08:56 schrieb Austin English:
>
> > visual.c:1741: Test failed: double texbem failed: Got color
> > 0x00ff00ff, expected 0x0000.
> Which GPU do you have?
>
01:00.0 VGA compatible contr
Am Donnerstag, 6. März 2008 05:08:56 schrieb Austin English:
> visual.c:1741: Test failed: double texbem failed: Got color
> 0x00ff00ff, expected 0x0000.
Which GPU do you have?
In today's git, I've had a few regressions in make -k test:
[EMAIL PROTECTED]:~/wine-git$ grep -i 'Test failed' wine-0.9.56-420-g22f146f.txt
visual.c:1741: Test failed: double texbem failed: Got color
0x00ff00ff, expected 0x0000.
systray.c:89: Test failed: ret 0x1 w
Hi Dan,
Dan Kegel schreef:
> http://kegel.com/wine/valgrind/logs-2007-12-17-summary.txt
> shows interesting things happened since Friday in riched20.
> See
> http://kegel.com/wine/valgrind/logs-2007-12-17/vg-riched20_editor-diff.txt
> for a whole heap of new errors. The only change since Friday
>
http://kegel.com/wine/valgrind/logs-2007-12-17-summary.txt
shows interesting things happened since Friday in riched20.
See
http://kegel.com/wine/valgrind/logs-2007-12-17/vg-riched20_editor-diff.txt
for a whole heap of new errors. The only change since Friday
was Maarten's,
http://www.winehq.org/p
Le mardi 14 novembre 2006 à 16:07 +0100, Mirek a écrit :
> :) No, in current git or cvs it is still not fixed, i tried it again
> before 10 minutes.
>
> Mirek
>
> Dmitry Timoshkov napsal(a):
> > "Mirek" <[EMAIL PROTECTED]> wrote:
> >
> >> Ok, i found patch which caused regression in 3DMark 2003
:) No, in current git or cvs it is still not fixed, i tried it again
before 10 minutes.
Mirek
Dmitry Timoshkov napsal(a):
"Mirek" <[EMAIL PROTECTED]> wrote:
Ok, i found patch which caused regression in 3DMark 2003, Flatout and
some other games and apps, it is this patch:
kernel32: Better wor
Hi,
My regression test shows same as you.
Dreamfall is broken because of this patch.
2006. november 14. 16.07 dátummal Mirek ezt írta:
> :) No, in current git or cvs it is still not fixed, i tried it again
>
> before 10 minutes.
>
> Mirek
>
> Dmitry Timoshkov napsal(a):
> > "Mirek" <[EMAIL PROTE
"Mirek" <[EMAIL PROTECTED]> wrote:
Ok, i found patch which caused regression in 3DMark 2003, Flatout and
some other games and apps, it is this patch:
kernel32: Better workaround for the lack of locale environment variables
on MacOS from Alexandre Julliard
It's already fixed in the current git
Ok, i found patch which caused regression in 3DMark 2003, Flatout and
some other games and apps, it is this patch:
kernel32: Better workaround for the lack of locale environment variables
on MacOS from Alexandre Julliard
Mirek
Jesse Allen napsal(a):
On 11/13/06, Mirek <[EMAIL PROTECTED]> wrot
On 11/13/06, Mirek <[EMAIL PROTECTED]> wrote:
Yes and no, some issues was because of drivers, but some wasnt, now i
have old working drivers back and there are still about 35% apps that
are working significant worst in wine 0.9.25, so it is not only problem
of new drivers.
Mirek
Please report
Yes and no, some issues was because of drivers, but some wasnt, now i
have old working drivers back and there are still about 35% apps that
are working significant worst in wine 0.9.25, so it is not only problem
of new drivers.
Mirek
Jesse Allen napsal(a):
On 11/13/06, Mirek <[EMAIL PROTECTE
On 11/13/06, Mirek <[EMAIL PROTECTED]> wrote:
Ok, some problems was caused by incompatibility betwen nVidia 9742
drivers and wine, now i have again perfect working 9625 drivers. Here is
updated list:
Then your bug number is 6637. Please continue the discussion about
this problem there.
http:/
Ok, some problems was caused by incompatibility betwen nVidia 9742
drivers and wine, now i have again perfect working 9625 drivers. Here is
updated list:
1. 3DMark 2003 - cant open setings menu - this has been fixed in last 2
days in CVS
2. 3DMark 2003 - with GLSL, almost all working test are
On 11/13/06, Mirek <[EMAIL PROTECTED]> wrote:
Hi, i am testing wine about every 3 days from current git. Warcraft 3
cant run for me if i am using option "-opengl", with direct3d (default)
it is working without any problems, but it is slower. If you want i can
do testing every second day (after so
For what it's worth, World of Warcraft is working well in opengl mode
except for certain hardware... For instance ATI X series seem to have
crashes however I'm not sure if this is widespread or just one or two
users. ON ATI 8500 series & higher cards opengl is working well but ONLY
if you add t
Hi, i am testing wine about every 3 days from current git. Warcraft 3
cant run for me if i am using option "-opengl", with direct3d (default)
it is working without any problems, but it is slower. If you want i can
do testing every second day (after some changes in CVS) and report
problems, but
On 11/12/06, Joseph Garvin <[EMAIL PROTECTED]> wrote:
Why would it be so difficult to have someone to pick a couple of common
apps, like winzip, word, and warcraft3, and make sure they still
function before every release?
Here's a common problem. I tested Warcraft 3 with 0.9.25 from compile,
not totally break. It's pretty obvious that there is no one
> checking to make sure common apps work before rolling the release
> tarballs. Granted, sometimes it's necessary for parts of wine to be
> totally restructured in order to do things correctly and avoiding
> regressions in th
not totally break. It's pretty obvious that there is no onechecking to make sure common apps work before rolling the releasetarballs. Granted, sometimes it's necessary for parts of wine to betotally restructured in order to do things correctly and avoiding
regressions in this case is un
1 - 100 of 130 matches
Mail list logo
