Seems that most beer apps run ok on wine, judging by this thread:
http://www.tastybrew.com/forum/thread/120190
On 10/25/07, Reece Dunn <[EMAIL PROTECTED]> wrote:
> On 25/10/2007, James Hawkins wrote:
> > Hi,
> >
> > Changelog:
> > * Fix a test that now passes in Windows.
>
> Looking at the code, it looks as if they are now passing in Wine :).
>
I don't think you are looking at the code, nor does it seem yo
On 10/25/07, James Hawkins <[EMAIL PROTECTED]> wrote:
> > 1) runtest could take an option --skip-long-tests
> > which would skip all tests that had that option set, and
>
> I don't think that's fair to long tests, say msi:install. There will
> always be people that don't want to wait for the tests
Let's just say, for grins, that we applied a patch that made
heap corruption fatal under WINEDEBUG=warn+heap, e.g.
--- a/dlls/ntdll/heap.c
+++ b/dlls/ntdll/heap.c
@@ -909,6 +909,7 @@ static BOOL HEAP_ValidateInUseArena( con
WARN( "Heap %p: unaligned arena pointer %p\n",
subheap->heap,
On 10/25/07, Dan Kegel <[EMAIL PROTECTED]> wrote:
> James wrote:
> >Looking at the test data, all of the msi:install tests timeout. I
> >just ran the install tests in XP running under vmware on a 3ghz
> >machine. The tests took 9m41s. That completely blows away the 2min
> >timeout. There's noth
Am Freitag, 26. Oktober 2007 01:54:59 schrieb Reece Dunn:
> This is true. The tests should only check for valid Windows results.
>
> The problem is how to filter out the noise of the VMware bugs from
> actual failures in Windows for the Wine tests. This is so that we know
> which tests need fixing
On 26/10/2007, Francois Gouget <[EMAIL PROTECTED]> wrote:
>
> Would it be possible to gather this kind of information in winetest.exe?
> Maybe simply grab the name of the graphics card?
This would be useful.
Also, I suspect that it would be worth adding vmware in the test
cases. That is, somethin
On 25/10/2007, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> Am Donnerstag, 25. Oktober 2007 22:15:39 schrieb Reece Dunn:
> > Hi,
> >
> > Looking at the ddraw:d3d tests, they are failing consistently on many
> > Windows platforms:
> Is this a vmware system?
This is from the http://test.winehq.org/d
On 25/10/2007, Juan Lang <[EMAIL PROTECTED]> wrote:
> > Tests would also be useful here as well, so that there is not a regression.
>
> That's good general advice, but hard to implement without a serial
> device to test against, which our test systems won't have.
You could always skip the tests wh
On 25/10/2007, Juan Lang <[EMAIL PROTECTED]> wrote:
> > I was basing it on what you said in the commit - both the heading and
> > the comment in the patch.
>
> That's dangerous here. The details are small, but they matter:
Of course the details matter.
> > 1. This patch is applied to remove t
Am Freitag, 26. Oktober 2007 01:22:22 schrieb Reece Dunn:
> Also, I suspect that it would be worth adding vmware in the test
> cases. That is, something like:
>
>ok( ret == 129 /* Windows */ || ret == 133 /* VMware */, ... );
>
> This would mean that the tests that are consistently (and predict
On Fri, 26 Oct 2007, Stefan Dösinger wrote:
> Am Donnerstag, 25. Oktober 2007 22:15:39 schrieb Reece Dunn:
> > Hi,
> >
> > Looking at the ddraw:d3d tests, they are failing consistently on many
> > Windows platforms:
> Is this a vmware system?
At least two of them are (as indicated by their tags),
On Thu, 25 Oct 2007, James Hawkins wrote:
[...]
> Looking at the test data, all of the msi:install tests timeout. I
I believe that's because of this:
* msi:automation and msi:install both time out because of this message:
Service 'TestService' (TestService) could not be
installed. Ve
I noticed that oleaut32's typelib test failed on windows:
typelib.c:65:Loading type library
typelib.c:1208: Test failed: LoadTypeLibEx(wszName, REGKIND_NONE,
&typelib) returned 80029c4a, expected S_OK (0)
Is this because winetest.exe didn't include the files
dlls/oleaut32/tests/*.tlb?
Am Donnerstag, 25. Oktober 2007 22:15:39 schrieb Reece Dunn:
> Hi,
>
> Looking at the ddraw:d3d tests, they are failing consistently on many
> Windows platforms:
Is this a vmware system?
signature.asc
Description: This is a digitally signed message part.
James wrote:
>Looking at the test data, all of the msi:install tests timeout. I
>just ran the install tests in XP running under vmware on a 3ghz
>machine. The tests took 9m41s. That completely blows away the 2min
>timeout. There's nothing wrong with the tests, they just take a long
>time. I d
On Thu, 25 Oct 2007, Juan Lang wrote:
> > - if it did not run because the tested dll did not exist at all, then
> > it's not a test failure and thus the background should be green.
> >A typical case would be the crypt32 tests on Windows 98.
>
> Actually, that's a poor case. From the Dll inf
> Tests would also be useful here as well, so that there is not a regression.
That's good general advice, but hard to implement without a serial
device to test against, which our test systems won't have.
--Juan
On 25/10/2007, Juan Lang <[EMAIL PROTECTED]> wrote:
> Hi Tom,
>
> > Exchanged interpretation of XON and XOFF.
>
> It might help if you wrote the same explanation about their meanings
> being reversed in your email that you did in the patch: Alexandre's
> not likely to go check up on bugzilla.
Tes
On 25/10/2007, Juan Lang <[EMAIL PROTECTED]> wrote:
> > The test being removed is correct and valid.
>
> Are you certain? Remember that I wrote it ;)
:)
> > While a 100% pass rate is ideal, on Windows 2003 SP1 that test *is*
> > failing due to a bug.
>
> Again, are you sure? Or are you just say
> I was basing it on what you said in the commit - both the heading and
> the comment in the patch.
That's dangerous here. The details are small, but they matter:
> 1. This patch is applied to remove the test for this feature^Wbug
> in CertGetCertificateChain;
No, the feature/bug is in CertG
Hi Tom,
> Exchanged interpretation of XON and XOFF.
It might help if you wrote the same explanation about their meanings
being reversed in your email that you did in the patch: Alexandre's
not likely to go check up on bugzilla.
--Juan
> The test being removed is correct and valid.
Are you certain? Remember that I wrote it ;)
> While a 100% pass rate is ideal, on Windows 2003 SP1 that test *is*
> failing due to a bug.
Again, are you sure? Or are you just saying that because I said it is
in the commit? The definition of "bug
On 25/10/2007, James Hawkins wrote:
> Hi,
>
> Changelog:
> * Fix a test that now passes in Windows.
Looking at the code, it looks as if they are now passing in Wine :).
> dlls/user32/tests/dde.c | 13 ++---
> 1 files changed, 10 insertions(+), 3 deletions(-)
> +str = (LPSTR)DdeAcc
Juan Lang wrote:
> -/* Now check just the time */
> -flags = CERT_STORE_TIME_VALIDITY_FLAG;
> -parent = CertGetIssuerCertificateFromStore(store, child, NULL, &flags);
> -ok(parent != NULL, "CertGetIssuerCertificateFromStore failed: %08x\n",
> - GetLastError());
> -/* Oops:
Hi,
Looking at the ddraw:d3d tests, they are failing consistently on many
Windows platforms:
d3d.c:1039: Test failed: IDirect3DViewport_SetViewport returned 80070057
d3d.c:1050: Test failed: Vertex 2 differs. Got 129.00 127.00
1.00 1.00, expexted 133.00 123.00 1.00 1.0
Scott Ritchie wrote:
>
> What license is the gecko package under? Can I just bundle it with the
> Wine package and have it work out of the box?
>
It's tri-license: MPL, GPL and LGPL, so as far as I understand it, it
should be fine from license point of view (see
http://www.mozilla.org/MPL). I
Jacek Caban wrote:
> Hello,
>
> As you probably have noticed, downloading Gecko on first use confuses
> users. Now, with last week patches, there is an other way to do it,
> transparent for users. MSHTML code looks for cab file in $data_dir/gecko
> (that is usually /usr/share/wine/gecko). Alternat
"Juan Lang" <[EMAIL PROTECTED]> writes:
>> There's a lot of machinery needed on a box to rebuild wine, and
>> Windows boxes typically have no development tools whatsoever.
>
> Okay, but the toolchain to build winetest is relatively small, isn't
> it? Could we include that in the Windows version o
> There's a lot of machinery needed on a box to rebuild wine, and
> Windows boxes typically have no development tools whatsoever.
Okay, but the toolchain to build winetest is relatively small, isn't
it? Could we include that in the Windows version of the tests in
order to speed up our response to
On Thu, 2007-10-25 at 09:38 -0700, Juan Lang wrote:
> I suspect the biggest problem is keeping the winetest executable up to
> date on the systems. If the test system can't compile the tests, it
> can't easily perform a regression test. What's the biggest obstacle
> to that?
There's a lot of mac
Juan Lang wrote:
>> Just looking at the pretty colors may not make this very obvious, but
>> the state of the tests is APPALLING.
>>
>
> Agreed. I wonder how much of it has to do with not noticing that the
> tests have failed?
>
> I may just be transforming the problem from an easy one (we sh
On 10/25/07, Francois Gouget <[EMAIL PROTECTED]> wrote:
>
> Here are some things I noticed while using this site. Let me know if I
> it would help to make bug reports for these:
>
> * Some result entries are red with a dash in them and a blue border.
> See the Windows 98 results for http://test.wi
> - if it did not run because the tested dll did not exist at all, then
> it's not a test failure and thus the background should be green.
>A typical case would be the crypt32 tests on Windows 98.
Actually, that's a poor case. From the Dll info section of the Windows 98 test:
crypt32=5.1
> Just looking at the pretty colors may not make this very obvious, but
> the state of the tests is APPALLING.
Agreed. I wonder how much of it has to do with not noticing that the
tests have failed?
I may just be transforming the problem from an easy one (we shouldn't
be lazy about checking the
On 10/25/07, Francois Gouget <[EMAIL PROTECTED]> wrote:
>
> Here are some things I noticed while using this site. Let me know if I
> it would help to make bug reports for these:
>
> * Some result entries are red with a dash in them and a blue border.
> See the Windows 98 results for http://test.wi
Here are some things I noticed while using this site. Let me know if I
it would help to make bug reports for these:
* Some result entries are red with a dash in them and a blue border.
See the Windows 98 results for http://test.winehq.org/data/200710241000/
I assume these means that the tes
On Wed, 24 Oct 2007, Dan Kegel wrote:
[...]
> 24.018s winmm_test.exe.so wave.c
[...]
> Other than wininet's ftp test and maybe winmm's wave test,
> the overall time seems reasonable.
I believe winetest has a two minutes timeout for individual tests and
that seems reasonable to me. So then our goa
Looking at yesterday's test results is depressing:
http://test.winehq.org/data/200710241000/
Just looking at the pretty colors may not make this very obvious, but
the state of the tests is APPALLING.
Successes | Failures | Failure rate | Not Run
WinXP-1 |260| 53
Michael Stefaniuc wrote:
> Anatoly Lyutin wrote:
>
>> Dmitry Timoshkov wrote:
>>
>>> "Anatoly Lyutin" <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>> The whole Wine tree uses 8 spaces for a tab.
>>>
>>>
>>>
>> Hm. I thought that some modules use 4 space symbols instead of 1 tab
>> symb
Anatoly Lyutin wrote:
> Dmitry Timoshkov wrote:
>> "Anatoly Lyutin" <[EMAIL PROTECTED]> wrote:
>>
>>
>> The whole Wine tree uses 8 spaces for a tab.
>>
>>
> Hm. I thought that some modules use 4 space symbols instead of 1 tab
> symbol. Sorry if I am wrong.
I think you are confusing indentati
Dmitry Timoshkov wrote:
> "Anatoly Lyutin" <[EMAIL PROTECTED]> wrote:
>
>
> The whole Wine tree uses 8 spaces for a tab.
>
>
Hm. I thought that some modules use 4 space symbols instead of 1 tab
symbol. Sorry if I am wrong.
>
> A proper error handling IMO is to return an error to the caller i
"Anatoly Lyutin" <[EMAIL PROTECTED]> wrote:
>> Once you change your editor settings to use natural 8 spaces for a tab
>> you will
>> see how ugly the formatting in your new code is.
>>
> I am sorry. I forgot that in the start.c uses natural 8 spaces for a
> tab. Fixed.
The whole Wine tree uses
Dmitry Timoshkov wrote:
> "Anatoly Lyutin" <[EMAIL PROTECTED]> wrote:
>
>> -/**
>> +WINE_DEFAULT_DEBUG_CHANNEL(start);
>> +
>> +/*
>
> All these changes /** -> /* make the diff larger, and are not really
> necessary.
I have considered it in the new version.
>
>
>> Output given message to stdout wi
"Dan Kegel" <[EMAIL PROTECTED]> writes:
> Without this patch, winmm/tests/mixer.c appears to hang on one of my machines.
>
> I think the problem was capsA was uninitialized in:
> for (d=0;d
"Anatoly Lyutin" <[EMAIL PROTECTED]> wrote:
> -/**
> +WINE_DEFAULT_DEBUG_CHANNEL(start);
> +
> +/*
All these changes /** -> /* make the diff larger, and are not really
necessary.
> Output given message to stdout without formatting.
> */
> -static void output(const char *message)
> +static void
"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes:
> That means that if/once apps start to import shlwapi APIs by name they
> will not work in Wine. Also, do you mean that APIs for which entries
> -noname has been already removed need to be fixed to have -noname again?
With -noname the name should st
"Robert Shearman" <[EMAIL PROTECTED]> wrote:
[skipped]
> These are all exported by ordinal only up to Windows 2003 SP1 (w/ IE 6.0).
Probably. But they are exported by name in Vista, and in some other versions
of Windows (have a look at the referenced web page). The point is that once/if
applicat
Dmitry Timoshkov wrote:
> +1 stdcall ParseURLA(str ptr)
> +2 stdcall ParseURLW(wstr ptr)
> +12 stdcall SHCreateMemStream(ptr long)
> +168 stdcall ConnectToConnectionPoint(ptr ptr long ptr ptr ptr)
> +169 stdcall IUnknown_AtomicRelease(long)
> +172 stdcall IUnknown_GetWindow(ptr ptr)
> +174 std
"Alexandre Julliard" <[EMAIL PROTECTED]> wrote:
> "Dmitry Timoshkov" <[EMAIL PROTECTED]> writes:
>
>> I've removed -noname for entries that according to Geoff started to be
>> exported by name in some Windows versions. We have some such entries
>> already.
>
> If the function was newly added in
"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes:
> I've removed -noname for entries that according to Geoff started to be
> exported by name in some Windows versions. We have some such entries
> already.
If the function was newly added in that version then it's OK, but if
the function is available
> We of course have to create the directory, but I think it would be
> better if the dll that uses it did that.
Hm, so you suggest putting it into WINSPOOL_LoadSystemPrinters()? Cause this
looks like the only function who is definitely called during wine startup,
isn't it?
So we should include
"Alexandre Julliard" <[EMAIL PROTECTED]> wrote:
>> @@ -1,18 +1,18 @@
>> -1 stdcall -noname ParseURLA(str ptr)
>> -2 stdcall -noname ParseURLW(wstr ptr)
>> +1 stdcall ParseURLA(str ptr)
>> +2 stdcall ParseURLW(wstr ptr)
>
> That doesn't look right, why are you removing -noname on these and
Robert Shearman <[EMAIL PROTECTED]> writes:
> */
> -static void update_wm_states( Display *display, struct x11drv_win_data
> *data, BOOL force )
> +static void update_wm_states( Display *display, struct x11drv_win_data
> *data,
> + BOOL force, BOOL set_zorder, HWN
Dmitry Timoshkov <[EMAIL PROTECTED]> writes:
> @@ -1,18 +1,18 @@
> -1 stdcall -noname ParseURLA(str ptr)
> -2 stdcall -noname ParseURLW(wstr ptr)
> +1 stdcall ParseURLA(str ptr)
> +2 stdcall ParseURLW(wstr ptr)
That doesn't look right, why are you removing -noname on these and
many other
On Thursday October 25 2007 08:08, Fong, Man To wrote:
> > Dear Sir / Madam,
> >
> > We are developing a software which is running on Linux platform. The
> > software will retrieve the information from TETRA Connectivity Server
> > (TCS) which is running on Window 2003 server. The communication
> >
> Dear Sir / Madam,
>
> We are developing a software which is running on Linux platform. The
> software will retrieve the information from TETRA Connectivity Server
> (TCS) which is running on Window 2003 server. The communication
> protocol, pre-defined by TCS manufacturing, is DCOM. Since the
>
57 matches
Mail list logo
