Kirill K. Smirnov wrote:
WriteFile does not output unicode characters to console screen buffer, so if
ConsoleOutputCP is smth like 65001, this will fail.
The page http://msdn2.microsoft.com/en-us/library/ms687401.aspx contains
remedy by Microsoft how to deal with problem:
1) If device
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
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
protocol,
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
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, HWND
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
many other
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
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 by
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 that version then
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 still be
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 output(const
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;dcapsA.cDestinations;d++) {
That's just hiding the bug. If mixerGetDevCapsA failed we shouldn't go
on to
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 without formatting.
*/
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 8 spaces for
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 instead
of
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 indentation level with the
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
symbol. Sorry if I am wrong.
I
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
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 goal
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
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
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
- 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:
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
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 shouldn't
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
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
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 of the
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).
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
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
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: the
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 =
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 is
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
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
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 saying that
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.
Tests would
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 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 info
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 don't
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.
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?
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.
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), I'm not
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 predictably)
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 the test
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 when a
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
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, something
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 (so
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 nothing wrong
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, 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, and
Seems that most beer apps run ok on wine, judging by this thread:
http://www.tastybrew.com/forum/thread/120190
55 matches
Mail list logo
