Am Freitag, den 13.06.2008, 08:08 +0200 schrieb Pavel Troller:
> > > and when I compiled it without optimalization and with -g
> > > for debugging, it never crashed and worked perfectly under the debugger.
> > > I had to debug the optimized version, which is harder, because the
> > > generated
> >
> Pavel Troller wrote:
> >> OK, this was confusing. I was getting repeatable five minute
> >> builds, i.e. "make clean; reboot; time make -j3" (more or less :-)
> >> was reliably showing five minutes wall clock time.
> >>
> >> Then I did "make distclean; ./configure; make depend".
> >>
> >> After
Pavel Troller wrote:
>> OK, this was confusing. I was getting repeatable five minute
>> builds, i.e. "make clean; reboot; time make -j3" (more or less :-)
>> was reliably showing five minutes wall clock time.
>>
>> Then I did "make distclean; ./configure; make depend".
>>
>> After that, I got repe
> OK, this was confusing. I was getting repeatable five minute
> builds, i.e. "make clean; reboot; time make -j3" (more or less :-)
> was reliably showing five minutes wall clock time.
>
> Then I did "make distclean; ./configure; make depend".
>
> After that, I got repeatable nine minute builds,
On Thu, 2008-06-12 at 13:56 -0700, Scott Ritchie wrote:
> > I found it very handy to track down details on mswsock the other day.
> >
> > I suggest if it is to be removed instead dull it down by turning it in
> > to a list of dlls wine has and all available information in the form
> > of links for
OK, this was confusing. I was getting repeatable five minute
builds, i.e. "make clean; reboot; time make -j3" (more or less :-)
was reliably showing five minutes wall clock time.
Then I did "make distclean; ./configure; make depend".
After that, I got repeatable nine minute builds, i.e.
make cle
I'm not exactly sure where this removes the submitter column, but if
this is on the test results page, please keep it as it is, I find it
useful info, in multiple ways. One way is as a maintainer, being able
to sort through the results, and one is as a user, being able to see
which test results cam
Hello Wine Developers-
I am trying to compile a windows project on Linux using winemaker and
I'm stuck with a problem and was wondering if any of you have
encountered it before or have any suggestions.
In some of the compilation units in my project, I am using
std::ofstream that is defined in the
Scott Ritchie wrote:
> Edward Savage wrote:
>>> I propose we get rid of the page altogether, it's pretty much useless
>>> for figuring out how good Wine is. This is unfortunate, since it's
>>> often the first place people click.
>>>
>>> Thanks,
>>> Scott Ritchie
>>>
>>>
>>>
>> I found it very hand
http://www.linux.com/feature/138160
It puts the release date at June 20th, but otherwise seems accurate.
I was tickled by Jeremy's quote about my impact, but the real story is:
Wine's lucky that
a) Google happened to need Picasa on Linux, and the Picasa team was shorthanded
b) I raised my hand
Edward Savage wrote:
>> I propose we get rid of the page altogether, it's pretty much useless
>> for figuring out how good Wine is. This is unfortunate, since it's
>> often the first place people click.
>>
>> Thanks,
>> Scott Ritchie
>>
>>
>>
>
> I found it very handy to track down details on msw
> Two Preload calls in FindContext
I just sent 3 patches in an attempt to fix the bug. Please give them a try.
The tests work for me, and I'll test my other games for regressions. Please
also see if you see the ERR("Wine 1.0 safety path hit\n"); error message.
Stefan
PS: Does Outlook set the In-R
Jon Griffiths a écrit :
> Hi,
>
> Subject says it all.
>
>
+dbg_printf("%s", val_int ? "true" : "false");
what about the simpler:
+dbg_printf(val_int ? "true" : "false");
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate
Since Alexandre is now planning to do a 1.0.1 release,
I created a 1.0.1 target in bugzilla, and have targeted
a very few high priority and/or fixed-but-not-in-time bugs
to it.
Many of the bugs currently targeted for 1.2 are
not good candidates for targeting to 1.0.1 because
the bug is not yet well
On Thu, Jun 12, 2008 at 9:32 AM, Austin English <[EMAIL PROTECTED]> wrote:
> The bugs may be deferred, but if the bugs aren't reported, no one
> knows to fix them, albeit not likely until after 1.0.
If I recall correctly the criteria for target applications was that
they be freely accessible such
Austin English wrote:
>
>
>
>
Hi,
This patch is not correct. That last error actually came from the first of the
two GetServiceDisplayNameA's just before that and wasn't reset by NT4.
I'll sent a more correct one.
--
C
> It could be different - I can't tell for sure. This game doesn't
> produce any
> reasonable crash dump, just a message that it crashed (so not even
> winedbg's
> output). However the problems start with call to... Preload.
Vertexbuffer::PreLoad has nothing in common with Surface::PreLoad or
Textu
Stefan Dösinger wrote:
>> Two Preload calls in FindContext. And bug 13079:
>> http://bugs.winehq.org/show_bug.cgi?id=13079
> Ah, I think 13079 is an entirely different bug. Vertex buffers aren't
> involved in offscreen rendering readback, nor in render target selection.
> (Currently. D3D10 changes
Paul Vriens wrote:
> Austin English wrote:
>>
>>
>>
>>
> Hi,
>
> This patch is not correct. That last error actually came from the first
> of the two GetServiceDisplayNameA's just before that and wasn't reset by
> NT4.
>
>
> Two Preload calls in FindContext. And bug 13079:
> http://bugs.winehq.org/show_bug.cgi?id=13079
Ah, I think 13079 is an entirely different bug. Vertex buffers aren't
involved in offscreen rendering readback, nor in render target selection.
(Currently. D3D10 changes that)
On Thu, Jun 12, 2008 at 9:29 AM, Austin English <[EMAIL PROTECTED]> wrote:
>
+ok(GetLastError() == ERROR_SERVICE_DOES_NOT_EXIST ||
+ GetLastError() == ERROR_INSUFFICIENT_BUFFER /* NT 4 */,
+ "Expected ERROR_SERVICE_DOES_NOT_EXIST or
ERROR_INSUFFICIENT_BUFFER, got %d\n", GetLa
Stefan Dösinger wrote:
>> IMHO this is too little too late. There are at least 2 more calls to
>> Preload
>> that have exactly the same affect on some of my test games. It sure
>> would be
>> nice to "fix" at least one case which looks to be common for number of
>> games.
> I am aware of one. Where
On Thu, Jun 12, 2008 at 3:39 AM, Nikolay Sivov <[EMAIL PROTECTED]> wrote:
> Changelog:
>- Fixes GetCharacterPlacement with NULL lpResults argument (fix for bug
> 13094)
>
> ---
> dlls/gdi32/font.c | 34 --
> 1 files changed, 24 insertions(+), 10 deletions(-)
On Thu, Jun 12, 2008 at 9:32 AM, Austin English <[EMAIL PROTECTED]> wrote:
>
> The bugs may be deferred, but if the bugs aren't reported, no one
> knows to fix them, albeit not likely until after 1.0.
>
> Not reporting bugs is the software equivalent of people who don't vote
> and expect politician
On Thu, Jun 12, 2008 at 7:51 AM, Tom Wickline <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 12, 2008 at 8:01 AM, Zachary Goldberg <[EMAIL PROTECTED]> wrote:
>> On Thu, Jun 12, 2008 at 6:04 AM, Tom Wickline <[EMAIL PROTECTED]> wrote:
>>> On Wed, Jun 11, 2008 at 9:52 PM, Vitaliy Margolen
>>> <[EMAIL PROTE
On Thu, Jun 12, 2008 at 8:01 AM, Zachary Goldberg <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 12, 2008 at 6:04 AM, Tom Wickline <[EMAIL PROTECTED]> wrote:
>> On Wed, Jun 11, 2008 at 9:52 PM, Vitaliy Margolen
>> <[EMAIL PROTECTED]> wrote:
>>> Scott Ritchie wrote:
In any case, we should note why we
On Thu, Jun 12, 2008 at 6:04 AM, Tom Wickline <[EMAIL PROTECTED]> wrote:
> On Wed, Jun 11, 2008 at 9:52 PM, Vitaliy Margolen
> <[EMAIL PROTECTED]> wrote:
>> Scott Ritchie wrote:
>>> In any case, we should note why we're making a release in the first
>>> place, and make it very clear that we believe
On Thu, Jun 12, 2008 at 8:32 AM, Austin English <[EMAIL PROTECTED]> wrote:
> I respectfully suggest, therefore, that we move the Wine 1.0 release
> date to another date besides June 17.
Maybe this is a dumb idea, but could the Firefox developers be asked
to provide a link to the WINE release? "An
On Thu, Jun 12, 2008 at 5:04 AM, Tom Wickline <[EMAIL PROTECTED]> wrote:
> On Wed, Jun 11, 2008 at 9:52 PM, Vitaliy Margolen
> <[EMAIL PROTECTED]> wrote:
>> Scott Ritchie wrote:
>>> In any case, we should note why we're making a release in the first
>>> place, and make it very clear that we believe
-- Forwarded message --
From: Bamm <[EMAIL PROTECTED]>
Date: Thu, Jun 12, 2008 at 6:32 AM
Subject: [Wine] Wine 1.0 release date to clash with Firefox 3
To: [EMAIL PROTECTED]
According to http://wiki.winehq.org/WineReleasePlan the new release
date for Wine 1.0 is set to June 17.
> IMHO this is too little too late. There are at least 2 more calls to
> Preload
> that have exactly the same affect on some of my test games. It sure
> would be
> nice to "fix" at least one case which looks to be common for number of
> games.
I am aware of one. Where is the other one?
Dan Kegel wrote:
> The penultimate update?
>
>
>
> 1.0 bugs deferred to 1.0.1 since May 27th:
> +http://bugs.winehq.org/show_bug.cgi?id=12097";>12097
Wine 1.0 should not ship out-of-sync resource translations
This bug is
On Wed, Jun 11, 2008 at 9:52 PM, Vitaliy Margolen
<[EMAIL PROTECTED]> wrote:
> Scott Ritchie wrote:
>> In any case, we should note why we're making a release in the first
>> place, and make it very clear that we believe Wine 1.0 to be the best
>> version of Wine yet in all cases (ie, no regressions
On Wed, 11 Jun 2008, Mikołaj Zalewski wrote:
>
> >Does this work for you? When I apply the attached patch and run
> >
> >wine xcopy /?
> >
> >I get garbled German umlauts in the output (also tried with
> >SUBLANG_NEUTRAL) . Is it the same for you?
> >
> >
> Wine console applications output i
34 matches
Mail list logo
