James McKenzie wrote:
> True, but what happens IF the game stops working? Will a bug report
> with regression test be accepted or will it be rejected?
Are you kidding? Something tells me that you have no idea what you are talking
about.
> You can see there is a little fear if we stop testing
Tristan Schmelcher wrote:
> I think CBR_BLOCK is only for values of type HDDEDATA. The cbData
> value here is a DWORD (specifying a length). (DWORD)-1 seems to be the
> preferred way of checking this condition in the existing code, e.g.
> see dlls/user32/dde_client.c lines 637, 648, etc.
You are
Hi Mike,
--- a/dlls/msvcr70/msvcr70.spec
+++ b/dlls/msvcr70/msvcr70.spec
@@ -601,7 +601,7 @@
@ cdecl _wcslwr(wstr) msvcrt._wcslwr
@ stub _wcsncoll
@ cdecl _wcsnicmp(wstr wstr long) msvcrt._wcsnicmp
-@ stub _wcsnicoll
+@ cdecl _wcsnicoll(wstr wstr long) msvcrt._wcsnicmp
Typo?
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=7419
Your paranoid android.
On 12/2/10 10:43 AM, André Hentschel wrote:
Am 02.12.2010 16:11, schrieb James Mckenzie:
Should I just go out and find a copy of Windows98SE and VirtualBox to run this
on? Your reply makes it sound like the Wine program just does not care if
Windows9x functionality does not matter, it does.
Humm, Yup you are right. I was chatting with Ken Thomases earlier
today and he was talking about QTKit and how it is only Objective-C and
the next step beyond QuickTime. I had not realized that there where no
64 bit versions of the Quicktime framework.
I think we are stuck. Since we are usi
On 12/2/10 7:06 PM, Aric Stewart wrote:
> That was true of the first set of APIs i used. But I believe the
> ICMDecompressionSession APIs are available on 64-bit and not deprecated.
chips-computer:/System/Library/Frameworks/QuickTime.framework chip$ nm
-arch x86_64 QuickTime
nm: file: QuickTime d
That was true of the first set of APIs i used. But I believe the
ICMDecompressionSession APIs are available on 64-bit and not deprecated.
-aric
On 12/2/10 3:46 PM, C.W. Betts wrote:
The main problem when using the QuickTime C APIs is that the majority, if not
all of it, is deprecated and not
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=7412
Your paranoid android.
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=7411
Your paranoid android.
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=7410
Your paranoid android.
The main problem when using the QuickTime C APIs is that the majority, if not
all of it, is deprecated and not available on 64-bit code. I would suggest
using the Objective-C QTKit, but apparently Objective-C code is a no-no in Wine.
On Nov 29, 2010, at 10:31 AM, Aric Stewart wrote:
> ---
> conf
The only problem is that testbot does not allow me to set an environment
variable. All testbot knows are command line arguments.
Well, you can use 7zip and its SFX-capabilities to do a lot more with
testbot. I used this to invoke winhlp showing a specific helpfile :)
For your case, you might e
Austin English wrote:
>
>On Thu, Dec 2, 2010 at 8:00 PM, K.King wrote:
>> <<<
>> That's not useful. The whole point is that we don't want to spend the
>> effort required to keep the tests error-free on platforms that we don't
>> care about. That makes it easier to write tests for platforms that
>
On Thu, Dec 2, 2010 at 8:00 PM, K.King wrote:
> <<<
> That's not useful. The whole point is that we don't want to spend the
> effort required to keep the tests error-free on platforms that we don't
> care about. That makes it easier to write tests for platforms that
> actually matter, which is a m
<<<
That's not useful. The whole point is that we don't want to spend the
effort required to keep the tests error-free on platforms that we don't
care about. That makes it easier to write tests for platforms that
actually matter, which is a more productive use of everybody's time.
>>>
You may not
Am 02.12.2010 19:17, schrieb joerg-cyril.hoe...@t-systems.com:
> André Hentschel wrote:
>
>> I recently sent a patch to have a new debuglevel "2", but AJ wisely
>> pointed out we can simply set WINETEST_PLATFORM=wine on Windows
>> which has the same effect. So no need for such hacks :D
>
> I once
I think CBR_BLOCK is only for values of type HDDEDATA. The cbData
value here is a DWORD (specifying a length). (DWORD)-1 seems to be the
preferred way of checking this condition in the existing code, e.g.
see dlls/user32/dde_client.c lines 637, 648, etc.
I will re-send the patch in two parts.
On
On 12/2/10 2:23 PM, Alexandre Julliard wrote:
Jacek Caban writes:
Um, that was stupid from me. I've previously made NP_* function
failing, but it didn't work well, so I've changed it to DllMain. I
don't see a clean way to fix registration. We could set these
registries from mshtml.dll, but the
André Hentschel wrote:
>I recently sent a patch to have a new debuglevel "2", but AJ wisely
>pointed out we can simply set WINETEST_PLATFORM=wine on Windows
>which has the same effect. So no need for such hacks :D
I once submitted a similar command line patch: runtest --strict :-)
AJ is right.
Nikolay Sivov writes:
> @@ -270,7 +270,7 @@ static DWORD netconn_verify_cert(PCCERT_CONTEXT cert,
> HCERTSTORE store,
> else if (chain->TrustStatus.dwErrorStatus & ~supportedErrors)
> err = ERROR_INTERNET_SEC_INVALID_CERT;
> }
> -if (!err)
> +
Aric Stewart writes:
> @@ -191,6 +191,12 @@ BOOL PSDRV_SelectBuiltinFont(PSDRV_PDEVICE *physDev,
> HFONT hfont,
> if(!family)
> family = physDev->pi->Fonts;
>
> +if (!family)
> +{
> +ERR("Unable to get any font for printer\n");
> +return FALSE;
> +}
I
Am 02.12.2010 16:11, schrieb James Mckenzie:
> Should I just go out and find a copy of Windows98SE and VirtualBox to run
> this on? Your reply makes it sound like the Wine program just does not care
> if Windows9x functionality does not matter, it does.
Shutting down the test does not necessary
Am 02.12.2010 13:46, schrieb joerg-cyril.hoe...@t-systems.com:
> An independent idea is to run a special winetest.exe compiled with
> int broken(int condition) { return 0; }
I recently sent a patch to have a new debuglevel "2", but AJ wisely pointed out
we can simply set WINETEST_PLATFORM=wine on
Alexandre Julliard wrote:
>Sent: Dec 2, 2010 6:30 AM
>To: joerg-cyril.hoe...@t-systems.com
>Cc: wine-devel@winehq.org
>Subject: Re: Death to win9x?
>
> writes:
>
>> However, this only allows to run one test at a time, i.e. the big picture is
>> missing.
>> Therefore I'd suggest running winetest.e
My very tentative $.02:
If there are tests we care about on Win9x (for old apps), wouldn't it
be easier to move them to their own file/folder, and only run those
and only those on 9x?
If the regular tests are going to lose all their broken() calls and
become meaningless on 9x, we still will want t
writes:
> However, this only allows to run one test at a time, i.e. the big picture is
> missing.
> Therefore I'd suggest running winetest.exe on all testbot machines once a week
> or some such, e.g. only for releases.
That's not useful. The whole point is that we don't want to spend the
effort
Jacek Caban writes:
> Um, that was stupid from me. I've previously made NP_* function
> failing, but it didn't work well, so I've changed it to DllMain. I
> don't see a clean way to fix registration. We could set these
> registries from mshtml.dll, but then we lose the ability to easily
> unregis
On 12/2/10 12:49 PM, Alexandre Julliard wrote:
Jacek Caban writes:
I know that this patch is the most questionable. Gecko expects us to
give it a DLL named np*.dll, so we can't do it in mshtml. Also, this
plugin will be visible to other NPAPI-based browsers running in Wine
(that's a matter of
Dan Kegel wrote:
>Like you, I'm afraid that dropping the win9x tests will lead
>to regressions old older apps.
Greg Geldorp wrote:
>However, they [Win9x VMs] would be available for selection
>if you click "Show all VMs" button when submitting a job.
This sounds very desirable.
However, this only
Jacek Caban writes:
> I know that this patch is the most questionable. Gecko expects us to
> give it a DLL named np*.dll, so we can't do it in mshtml. Also, this
> plugin will be visible to other NPAPI-based browsers running in Wine
> (that's a matter of change in the next Gecko release), so it's
On Thu, Dec 2, 2010 at 5:39 AM, Andrew Bogott wrote:
> This gets Icon Path and Icon Index written out to .url files if they've been
> set previously.
>
>
>
>
I think you leak a reference to pPropStgRead here.
Nice patch set otherwise :-)
Damjan
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=7392
Your paranoid android.
On Wed, Dec 01, 2010 at 11:42:44PM +0100, Andreas Pflug wrote:
> Am 26.11.2010 13:39, schrieb Marcus Meissner:
> >On Fri, Nov 26, 2010 at 01:06:32PM +0100, Andreas Pflug wrote:
> >>I'm investigating running a commercial ERP system under Wine (only
> >>binary available). It mostly works, but creatin
Tristan Schmelcher wrote:
> +if (cbData != (DWORD)-1)
> +{
> +/* pData is not a pointer if cbData is -1, so we linearize the
> address
> + * here rather than in the calling code. */
> +pData = MapSL((SEGPTR)pData);
> +}
-1 here should be replaced by CBR_BLOCK
35 matches
Mail list logo
