Re: [PATCH] [WineDbg]: allow to specify which format to be used for integers in backtraces

[Dmitry Timoshkov]

Eric Pouech  wrote:

> 
> >> bt /x will do what you want.
> >> 
> >
> > How will it help with all those backtraces generated and sent by users
> > to bugzilla? Or those intermittent crashes which are very hard to reproduce?
> > Is there any reason to spend any time again if all required information
> > is already there in appropriate and ready to use/easy to understand format?
> >
> >   
> if it's information sent by user (in any form), you can always write a 
> small script to do the job
> (and also extend, message number, styles...)

Can I ask again, why to jump through the hoops if all required information
is already there in appropriate and ready to use/easy to understand format?

-- 
Dmitry.

New winetricks 20100316: new verbs steam, adobeair, 7zip, d3dxof, win7

[Dan Kegel]

Today's winetricks was brought to you by the letters W and S,
and the number 7.

Online as always at
 http://kegel.com/wine/winetricks
or
 http://winezeug.googlecode.com
(Bug reports to the issue tracker at the above URL, please.)

Changes:

Dan Kegel

Don't detect desktop environment, detect individual programs.
Make warnings more obvious on console.
flash: updated
gecko: updated
ie6: improved prerequisite checking
psdkwin7: requires native gdiplus for the moment, so make that a
prerequisite for now
psdkwin7: some important registry keys (kludge)
steam: added
win7: added

Austin English

Don't consider missing cabextract fatal, unless it's actually being used
Don't use cabextract directly, use the wrapper for all uses (issue 95)
Use a more sane path for C:. Patch from 'arielco'. Issue 96.
adobeair: add to winetrickstest, add missing decorations
dotnet20: Check for mscorlib.dll rather than l_intl.nls
icodec: remove, it's no longer online
mpc: Update

Andrew Nguyen

Suppress STDERR messages from which command
7zip: added
adobeair: added
d3dxof: added
msxml4/msxml6: add override before installing
vc2005trial: Use 7-zip to extract the UDF image rather than mounting
it (so we can avoid sudo/root)

Pavel Zinin
directx9: update to February 2010 version

Re: [PATCH 2/2] cmd: Adds shlwapi library to cmd.exe's Makefile.in

[Dan Kegel]

Each patch in a series must compile and pass all tests,
so if you need shlwapi for patch 1, then you have
to include it in patch 1 (and then you just have one
patch, not a series).

Re: winhttp/url.c: Fix of invalid behaviour of WinHttpCrackUrl

[Maciej Borsz]

Hi!
I added this test to testsuite and resubmitted patch.

Maciej

2010/3/16 Paul Vriens 

> On 03/15/2010 10:56 PM, Maciej Borsz wrote:
>
>> Fix of invalid behaviour of WinHttpCrackUrl when in url is '@'.
>>
>> For example:
>> WinHttpCrackUrl(L"
>> http://example.net/path?var1=exam...@example.com&var2=x&var3=y
>> ", NULL,
>> NULL, sth)
>>
>> returned:
>> scheme(L"http") host(L"example.com &var2=x&var3=y")
>>
>> port(80) path(L"") extra(L"")
>>
>> instead of:
>> scheme(L"http") host(L"example.net ") port(80)
>>
>> path(L"/path/") extra(L"?var1=exam...@example.com
>> &var2=x&var3=y")
>>
>>
> Hi Maciej,
>
> Could you add a test for this to our testsuite?
>
> You could use winetestbot (https://winetestbot.geldorp.nl/index.pl) to
> verify the behavior on several Windows flavors if needed.
>
> --
> Cheers,
>
> Paul.
>

Re: [patch] DNS_SD bridge, v2

[C.W. Betts]

Excuse my ignorance, but what would happen if it didn't find the library 
dynamically?
On Mar 16, 2010, at 4:03 AM, Marcus Meissner wrote:

> On Mon, Mar 15, 2010 at 04:36:32AM -0600, C.W. Betts wrote:
>> The following is an updated patch that actually builds and links.
>> The patch does patch configure and config.h.in, both of which were generated 
>> with an older version of autoconf and autoheader.
> 
> You can and should leave out both configure and config.h.in from the diff, it 
> is
> regenerated by Alexandre.
> 
> 
> - You use "openal" in a configure.ac warning messages instead of dns_sd.
> 
> - how is non-presence of libdns_sd handled? It seems it will just fail
>  to build then.
> 
>  It should load the called functions dynamically.
> 
> Ciao, Marcus
> 
> 
> 

Re: On cygwin, these programs fails because they lack __wargv definition. So adding -mno-cygwin flag tell winegcc to link them with msvcrt instead of libc

[Alexandre Julliard]

GOUJON Alexandre  writes:

> I agree these programs don't need any msvcrt function.
> However, building on Windows calls mingw_unicode_hack (winegcc.c l.546)
>  551 create_file( main_stub, 0644,
>  552  "#include \n"
>  553  "extern int wmain(int,wchar_t**);\n"
>  554  "int main( int argc, char *argv[] )\n{\n"
>  555  "return wmain( argc, __wargv );\n}\n" );
>  556 return compile_to_object( opts, main_stub, NULL );
>
> So __wargv definition is needed (do we need the whole msvcrt library ?).
>
> As you don't want to link these with msvcrt, I'm wondering if we can
> use something like mbsrtowcs.

You can link with msvcrt on cygwin, if that works.

-- 
Alexandre Julliard
julli...@winehq.org

Re: On cygwin, these programs fails because they lack __wargv definition. So adding -mno-cygwin flag tell winegcc to link them with msvcrt instead of libc

[GOUJON Alexandre]

Le 03/15/10 14:11, Alexandre Julliard a écrit :

Alexandre Goujon  writes:

   

---
  programs/cmd/Makefile.in |2 +-
  programs/dxdiag/Makefile.in  |2 +-
  programs/explorer/Makefile.in|2 +-
  programs/extrac32/Makefile.in|2 +-
  programs/mshta/Makefile.in   |2 +-
  programs/reg/Makefile.in |2 +-
  programs/start/Makefile.in   |2 +-
  programs/svchost/Makefile.in |2 +-
  programs/termsv/Makefile.in  |2 +-
  programs/uninstaller/Makefile.in |2 +-
  programs/winebrowser/Makefile.in |2 +-
  programs/winedevice/Makefile.in  |2 +-
  programs/winepath/Makefile.in|2 +-
  13 files changed, 13 insertions(+), 13 deletions(-)
 

These apps don't link to msvcrt on purpose. If things are broken on
cygwin that needs to be handled in winegcc, you shouldn't have to touch
the makefiles.

   


I agree these programs don't need any msvcrt function.
However, building on Windows calls mingw_unicode_hack (winegcc.c l.546)
 551 create_file( main_stub, 0644,
 552  "#include \n"
 553  "extern int wmain(int,wchar_t**);\n"
 554  "int main( int argc, char *argv[] )\n{\n"
 555  "return wmain( argc, __wargv );\n}\n" );
 556 return compile_to_object( opts, main_stub, NULL );

So __wargv definition is needed (do we need the whole msvcrt library ?).

As you don't want to link these with msvcrt, I'm wondering if we can use 
something like mbsrtowcs.


Thanks

Re: [PATCH 04/16] [DbgHelp]: made the ELF mapping code easier to use

[Alexandre Julliard]

Eric Pouech  writes:

>> This breaks the non-ELF builds.
>>
>>   
> where does it break ? about image_no_map not being defined, or
> something else ?

For that patch it's IMAGE_NO_MAP, but it looked like there were other
breakages in subsequent patches. I'd recommend setting up a MingW
cross-compile to test it.

-- 
Alexandre Julliard
julli...@winehq.org

Re: [PATCH] [WineDbg]: allow to specify which format to be used for integers in backtraces

[Eric Pouech]

bt /x will do what you want.



How will it help with all those backtraces generated and sent by users
to bugzilla? Or those intermittent crashes which are very hard to reproduce?
Is there any reason to spend any time again if all required information
is already there in appropriate and ready to use/easy to understand format?

  
if it's information sent by user (in any form), you can always write a 
small script to do the job

(and also extend, message number, styles...)
A+

--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the 
ingenuity of a complete idiot." (Douglas Adams)

Re: DirectX 2D?

[Reece Dunn]

On 16 March 2010 19:00, Dan Kegel  wrote:
> I looked at the ie9 preview.
> You have to set the windows version to 7, but then it
> needs ie8 and "directx 2d" installed.

Does it work by faking an IE8 install (version, registry, etc.).

> I've added a win7 verb to winetricks, and would accept an ie8 verb patch
> if someone sent it,

I have some success with using the IE7 script. But I get:

  fixme:service:svcctl_CreateServiceW Dependencies not supported yet
  CreateService SUCCESS.
  err:rpc:I_RpcReceive we got fault packet with status 0x3e6
  CreateService: Failed to set Service description. Error: 0x3e6

on install, it does not want to connect to a web page (it is forever
stuck on showing "Connecting..."), and does not want to close:

  err:ntdll:NtQueryInformationToken Unhandled Token Information class 18!
  err:ntdll:NtQueryInformationToken Unhandled Token Information class 18!
  err:ntdll:NtQueryInformationToken Unhandled Token Information class 18!
  fixme:ole:NdrCorrelationInitialize (0x13dd7d8, 0x13dd3d8, 1024, 0x0): stub
  fixme:storage:PropertyStorage_WritePropertyToStream unsupported type: 72
  fixme:storage:PropertyStorage_WritePropertyToStream unsupported type: 72

It also produces a load of err and fixme traces on startup and while running.

> but I suspect DirectX 2D might be a tough
> nut to crack.

>From what I can tell, Microsoft only provide a Direct2D install for
Vista via a Windows Update; otherwise, you need Windows 7.

This means that Wine will need to provide its own implementation.

Also, the Firefox team have also been working on Direct2D/DirectWrite
support [1] [2], so that may also be useful.

NOTE: The Direct2D/DirectWrite APIs are built on top of the Direct3D
10 APIs (see, e.g. the Firefox patches and discussions on testing the
feature), so needs a decent(ish) implementation of D3D 10 first.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=527707
[2] http://www.basschouten.com/blog1.php

- Reece

Re: DirectX 2D?

[Henri Verbeet]

On 16 March 2010 20:49, Roderick Colenbrander  wrote:
> Direct2D support might not be that far away though and we MIGHT be
> able to use the native dll for now (depending on how it is
> implemented). The library is build on top of DXGI which is the toolkit
> on top of which Direct3D10/11 are build as well. It is responsible for
> things like communication with the kernel, buffer management,
> videocard/monitor enumeration and some 2D related tasks.
>
> I had a quick look at our DXGI code and I don't think it is complete
> enough (the surface and swapchain code is unimplemented) but it is not
> something which would take months to implement. Perhaps it would have
> been a useful gsoc project but it is hard to see results since I don't
> think there are standalone DXGI apps.
>
You probably shouldn't make claims like that when you don't know how
dxgi and the client libraries fit together :-\ What it comes down to
is that using the native D2D library is unlikely to work.

Re: DirectX 2D?

[Tom Wickline]

On Wed, Mar 17, 2010 at 3:00 AM, Dan Kegel  wrote:

> I looked at the ie9 preview.
> You have to set the windows version to 7, but then it
> needs ie8 and "directx 2d" installed.
>
> I've added a win7 verb to winetricks, and would accept an ie8 verb patch
> if someone sent it, but I suspect DirectX 2D might be a tough
> nut to crack.
>
>
>
IE 9 is also going to also need  DirectWrite support, third link below.

A couple of nice articles about Direct2D at blogs.msdn

http://blogs.msdn.com/directx/archive/2009/05/12/2d-drawing-apis-in-windows.aspx
http://blogs.msdn.com/directx/archive/2009/12/12/animated-2d-graphics-for-ui-games-and-demos.aspx
http://blogs.msdn.com/directx/archive/2009/11/18/internet-explorer-announces-to-use-directwrite-direct2d.aspx
and
http://blogs.msdn.com/directx/archive/tags/Direct2D/default.aspx

Tom

Re: [PATCH 04/16] [DbgHelp]: made the ELF mapping code easier to use

[Eric Pouech]

Alexandre Julliard a écrit :

Eric Pouech  writes:

  

- now exporting the file mapping facility to the debug info loader which need it
- allow to mark a section as to be kept (after debug info loading has been done)



This breaks the non-ELF builds.

  
where does it break ? about image_no_map not being defined, or something 
else ?

A+

--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the 
ingenuity of a complete idiot." (Douglas Adams)

Re: DirectX 2D?

[Roderick Colenbrander]

Direct2D support might not be that far away though and we MIGHT be
able to use the native dll for now (depending on how it is
implemented). The library is build on top of DXGI which is the toolkit
on top of which Direct3D10/11 are build as well. It is responsible for
things like communication with the kernel, buffer management,
videocard/monitor enumeration and some 2D related tasks.

I had a quick look at our DXGI code and I don't think it is complete
enough (the surface and swapchain code is unimplemented) but it is not
something which would take months to implement. Perhaps it would have
been a useful gsoc project but it is hard to see results since I don't
think there are standalone DXGI apps.

Roderick

On Tue, Mar 16, 2010 at 8:00 PM, Dan Kegel  wrote:
> I looked at the ie9 preview.
> You have to set the windows version to 7, but then it
> needs ie8 and "directx 2d" installed.
>
> I've added a win7 verb to winetricks, and would accept an ie8 verb patch
> if someone sent it, but I suspect DirectX 2D might be a tough
> nut to crack.
>
>
>

DirectX 2D?

[Dan Kegel]

I looked at the ie9 preview.
You have to set the windows version to 7, but then it
needs ie8 and "directx 2d" installed.

I've added a win7 verb to winetricks, and would accept an ie8 verb patch
if someone sent it, but I suspect DirectX 2D might be a tough
nut to crack.

Re: [PATCH] cmd: removed %CD% test.

[Yann Droneaud]

Le mardi 16 mars 2010 à 11:25 -0500, Austin English a écrit :
> On Tue, Mar 16, 2010 at 4:53 AM, Yann Droneaud  wrote:
> > %CD% seems not supported on Windows NT 4.
> >
> > The patch which introduce this test was based on MSDN documentation
> > and only tested on Windows XP
> 
> Instead of removing it, perhaps the cmd test framework needs to
> understand the broken() macro...
> 

As %CD% was added in a batch file (test_builtins.cmd) so it's easier to
remove it.

We can probably split test_builtins.cmd in smaller chunks, then use
those macro and then use todo(), broken(), etc.

They're some patches on test_builtins.cmd waiting, so I'm not gonna do
this first.

-- 
Yann Droneaud

Re: The shlwapi:istream tests and Microsoft Security Essentials

[Reece Dunn]

On 16 March 2010 16:36, Paul Vriens  wrote:
> On 03/16/2010 03:56 PM, Paul Vriens wrote:
>>
>> On 03/16/2010 03:20 PM, Reece Dunn wrote:
>>>
>>> On 16 March 2010 13:27, Paul Vriens wrote:

 Hi,

 I was wondering why I (out of all those boxes) had several failures for
 these tests on some of my XP and Vista boxes.
>>>
>>> I was wondering the same.
>>>
 Turns out that you get these failures when MSE is active. I just ran the
 tests on a clean XP-SP3 box (up-to-date) and no failures. Installing MSE
 (and downloading the latest signatures) is enough to show a multitude of
 test failures. Turning 'real time monitoring' off or excluding the test
 executable makes the tests succeed again.

 Most of the failures are of the E_ACCESSDENIED nature btw.
>>>
>>> This is interesting. I wonder if it is because MSE is locking the file
>>> so it can scan it for viruses, so when the next test gets run, the
>>> istream test cannot access that file and so gets an E_ACCESSDENIED
>>> back.
>>
>> I never had this issue with either "Microsoft Defender" or the Avast!
>> Home Edition virus scanner.
>>
>>>
 Does this make sense?
>>>
>>> Yes.
>>>
 If the test failures are valid, should I change the tests to cope
 with this?
>>>
>>> The test failures look valid in this case (MSE may be installed on a
>>> test system), so a change similar to
>>>
>>> http://source.winehq.org/git/wine.git/?a=commitdiff;h=1571337c0366b27e819851d7cdec4a7bc1ce7690
>>>
>>> should be done.
>>
>> The thing is that depending on the mode/flag the failures start at a
>> different place. I'll see if I can create something generic or whether
>> the flags indicate something (don't think so as several runs produces
>> different output).
>>
>
> The attached patch fixes the issue on my boxes. Looks like it's just a
> timing issue (MSE being slllwww I guess).

Looks good to me.

> I should maybe raise the timeout to something higher, it's only affecting a
> handful of boxes anyway?

If it works on your machine over 2-3 runs, it should be ok. We can
always increase the Sleep if needed. Raising it too high means that
you are more likely to get the wine test program failing the test
because it is taking too long.

- Reece

Re: The shlwapi:istream tests and Microsoft Security Essentials

[Paul Vriens]

On 03/16/2010 03:56 PM, Paul Vriens wrote:

On 03/16/2010 03:20 PM, Reece Dunn wrote:

On 16 March 2010 13:27, Paul Vriens wrote:

Hi,

I was wondering why I (out of all those boxes) had several failures for
these tests on some of my XP and Vista boxes.


I was wondering the same.


Turns out that you get these failures when MSE is active. I just ran the
tests on a clean XP-SP3 box (up-to-date) and no failures. Installing MSE
(and downloading the latest signatures) is enough to show a multitude of
test failures. Turning 'real time monitoring' off or excluding the test
executable makes the tests succeed again.

Most of the failures are of the E_ACCESSDENIED nature btw.


This is interesting. I wonder if it is because MSE is locking the file
so it can scan it for viruses, so when the next test gets run, the
istream test cannot access that file and so gets an E_ACCESSDENIED
back.


I never had this issue with either "Microsoft Defender" or the Avast!
Home Edition virus scanner.




Does this make sense?


Yes.


If the test failures are valid, should I change the tests to cope
with this?


The test failures look valid in this case (MSE may be installed on a
test system), so a change similar to
http://source.winehq.org/git/wine.git/?a=commitdiff;h=1571337c0366b27e819851d7cdec4a7bc1ce7690

should be done.


The thing is that depending on the mode/flag the failures start at a
different place. I'll see if I can create something generic or whether
the flags indicate something (don't think so as several runs produces
different output).



The attached patch fixes the issue on my boxes. Looks like it's just a 
timing issue (MSE being slllwww I guess).


I should maybe raise the timeout to something higher, it's only 
affecting a handful of boxes anyway?


--
Cheers,

Paul.
diff --git a/dlls/shlwapi/tests/istream.c b/dlls/shlwapi/tests/istream.c
index 9501cd8..d30132a 100644
--- a/dlls/shlwapi/tests/istream.c
+++ b/dlls/shlwapi/tests/istream.c
@@ -432,6 +432,11 @@ static void test_SHCreateStreamOnFileEx(DWORD mode, DWORD 
stgm)
 
 stream = NULL;
 ret = (*pSHCreateStreamOnFileEx)(test_file, mode, 0, FALSE, template, 
&stream);
+if (ret == HRESULT_FROM_WIN32(ERROR_ACCESS_DENIED)) {
+win_skip("Probably blocked by Anti-Virus/Spam software, trying 
again\n");
+Sleep(1000);
+ret = (*pSHCreateStreamOnFileEx)(test_file, mode, 0, FALSE, template, 
&stream);
+}
 ok( ret == HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND) ||
 ret == HRESULT_FROM_WIN32(ERROR_INVALID_PARAMETER),
 "SHCreateStreamOnFileEx: expected 
HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND) or "
@@ -491,6 +496,12 @@ static void test_SHCreateStreamOnFileEx(DWORD mode, DWORD 
stgm)
 
 stream = NULL;
 ret = (*pSHCreateStreamOnFileEx)(test_file, mode | STGM_CREATE | stgm, 0, 
FALSE, NULL, &stream);
+if (ret == HRESULT_FROM_WIN32(ERROR_ACCESS_DENIED)) {
+win_skip("Probably blocked by Anti-Virus/Spam software, trying 
again\n");
+Sleep(1000);
+ret = (*pSHCreateStreamOnFileEx)(test_file, mode | STGM_CREATE | stgm, 
0, FALSE, NULL, &stream);
+}
+
 ok(ret == S_OK, "SHCreateStreamOnFileEx: expected S_OK, got 0x%08x\n", 
ret);
 ok(stream != NULL, "SHCreateStreamOnFileEx: expected a valid IStream 
object, got NULL\n");
 
@@ -507,6 +518,11 @@ static void test_SHCreateStreamOnFileEx(DWORD mode, DWORD 
stgm)
 
 stream = NULL;
 ret = (*pSHCreateStreamOnFileEx)(test_file, mode | STGM_CREATE | stgm, 0, 
TRUE, NULL, &stream);
+if (ret == HRESULT_FROM_WIN32(ERROR_ACCESS_DENIED)) {
+win_skip("Probably blocked by Anti-Virus/Spam software, trying 
again\n");
+Sleep(1000);
+ret = (*pSHCreateStreamOnFileEx)(test_file, mode | STGM_CREATE | stgm, 
0, TRUE, NULL, &stream);
+}
 ok(ret == S_OK, "SHCreateStreamOnFileEx: expected S_OK, got 0x%08x\n", 
ret);
 ok(stream != NULL, "SHCreateStreamOnFileEx: expected a valid IStream 
object, got NULL\n");
 

Re: [PATCH] cmd: removed %CD% test.

[Austin English]

On Tue, Mar 16, 2010 at 4:53 AM, Yann Droneaud  wrote:
> %CD% seems not supported on Windows NT 4.
>
> The patch which introduce this test was based on MSDN documentation
> and only tested on Windows XP

Instead of removing it, perhaps the cmd test framework needs to
understand the broken() macro...

-- 
-Austin

Re: (try 3) wineaudiofile.acm: Initial commit

[Alexandre Julliard]

Aric Stewart  writes:

> Supported mp3 decoding on OSX Leopard systems.
> Expandable to Tiger and other formats fairly easily.

It looks like almost all of that code is duplicated from winemp3, so
there doesn't seem to be much reason to make it a separate dll.

-- 
Alexandre Julliard
julli...@winehq.org

Re: asserts in wine

[Dan McDonald]

On 03/07/2010 10:35 AM, Vitaliy Margolen wrote:
> On 03/07/2010 04:38 AM, Reece Dunn wrote:
>>   2/  dlls should be changed to a SetLastError or failure return code
>> (depending on the API) -- otherwise, the program triggering this will
>> be killed with no information as to what happened.
> This depends. If something catastrophic happened and returning to
> application will surely cause it's crash - then it's better assert inside
> Wine. You'll have much better traces and information about the source of the
> problem. But if an app just passed invalid parameters returning error would
> seem to be appropriate.
> 

If we're trying to mimic Windows behavior, isn't a BSOD more
appropriate? ;-)

Dan

Re: The shlwapi:istream tests and Microsoft Security Essentials

[Paul Vriens]

On 03/16/2010 03:20 PM, Reece Dunn wrote:

On 16 March 2010 13:27, Paul Vriens  wrote:

Hi,

I was wondering why I (out of all those boxes) had several failures for
these tests on some of my XP and Vista boxes.


I was wondering the same.


Turns out that you get these failures when MSE is active. I just ran the
tests on a clean XP-SP3 box (up-to-date) and no failures. Installing MSE
(and downloading the latest signatures) is enough to show a multitude of
test failures. Turning 'real time monitoring' off or excluding the test
executable makes the tests succeed again.

Most of the failures are of the E_ACCESSDENIED nature btw.


This is interesting. I wonder if it is because MSE is locking the file
so it can scan it for viruses, so when the next test gets run, the
istream test cannot access that file and so gets an E_ACCESSDENIED
back.


I never had this issue with either "Microsoft Defender" or the Avast! 
Home Edition virus scanner.





Does this make sense?


Yes.


If the test failures are valid, should I change the tests to cope with this?


The test failures look valid in this case (MSE may be installed on a
test system), so a change similar to
http://source.winehq.org/git/wine.git/?a=commitdiff;h=1571337c0366b27e819851d7cdec4a7bc1ce7690
should be done.


The thing is that depending on the mode/flag the failures start at a 
different place. I'll see if I can create something generic or whether 
the flags indicate something (don't think so as several runs produces 
different output).


--
Cheers,

Paul.

Re: The shlwapi:istream tests and Microsoft Security Essentials

[Reece Dunn]

On 16 March 2010 13:27, Paul Vriens  wrote:
> Hi,
>
> I was wondering why I (out of all those boxes) had several failures for
> these tests on some of my XP and Vista boxes.

I was wondering the same.

> Turns out that you get these failures when MSE is active. I just ran the
> tests on a clean XP-SP3 box (up-to-date) and no failures. Installing MSE
> (and downloading the latest signatures) is enough to show a multitude of
> test failures. Turning 'real time monitoring' off or excluding the test
> executable makes the tests succeed again.
>
> Most of the failures are of the E_ACCESSDENIED nature btw.

This is interesting. I wonder if it is because MSE is locking the file
so it can scan it for viruses, so when the next test gets run, the
istream test cannot access that file and so gets an E_ACCESSDENIED
back.

> Does this make sense?

Yes.

> If the test failures are valid, should I change the tests to cope with this?

The test failures look valid in this case (MSE may be installed on a
test system), so a change similar to
http://source.winehq.org/git/wine.git/?a=commitdiff;h=1571337c0366b27e819851d7cdec4a7bc1ce7690
should be done.

- Reece

Re: [PATCH 04/16] [DbgHelp]: made the ELF mapping code easier to use

[Alexandre Julliard]

Eric Pouech  writes:

> - now exporting the file mapping facility to the debug info loader which need 
> it
> - allow to mark a section as to be kept (after debug info loading has been 
> done)

This breaks the non-ELF builds.

-- 
Alexandre Julliard
julli...@winehq.org

The shlwapi:istream tests and Microsoft Security Essentials

[Paul Vriens]

Hi,

I was wondering why I (out of all those boxes) had several failures for 
these tests on some of my XP and Vista boxes.


Turns out that you get these failures when MSE is active. I just ran the 
tests on a clean XP-SP3 box (up-to-date) and no failures. Installing MSE 
(and downloading the latest signatures) is enough to show a multitude of 
test failures. Turning 'real time monitoring' off or excluding the test 
executable makes the tests succeed again.


Most of the failures are of the E_ACCESSDENIED nature btw.

Does this make sense?

If the test failures are valid, should I change the tests to cope with this?

--
Cheers,

Paul.

Re: [PATCH] [WineDbg]: allow to specify which format to be used for integers in backtraces

[Dmitry Timoshkov]

Eric Pouech  wrote:

> > Eric Pouech  wrote:
> >
> > > Gdb uses decimal notation by default for integers, so do we.
> >
> > GDB can use anything their developers think appropriate, my patch
> > to use hex was intended to match Wine's relay traces and win32
> > header constants. This patch will make finding matches impossible
> > again.

> bt /x will do what you want.

How will it help with all those backtraces generated and sent by users
to bugzilla? Or those intermittent crashes which are very hard to reproduce?
Is there any reason to spend any time again if all required information
is already there in appropriate and ready to use/easy to understand format?

-- 
Dmitry.

Re: [PATCH 01/10] ntdll: Fixup imports after CREATE_PROCESS_DEBUG_EVENT.

[Alexandre Julliard]

Henri Verbeet  writes:

> diff --git a/dlls/ntdll/loader.c b/dlls/ntdll/loader.c
> index 1723f18..fbdda00 100644
> --- a/dlls/ntdll/loader.c
> +++ b/dlls/ntdll/loader.c
> @@ -2533,10 +2533,14 @@ PIMAGE_NT_HEADERS WINAPI RtlImageNtHeader(HMODULE 
> hModule)
>   */
>  static NTSTATUS attach_process_dlls( void *wm )
>  {
> +LPCWSTR load_path;
>  NTSTATUS status;
>  
>  pthread_sigmask( SIG_UNBLOCK, &server_block_set, NULL );
>  
> +load_path = NtCurrentTeb()->Peb->ProcessParameters->DllPath.Buffer;
> +if ((status = fixup_imports( wm, load_path )) != STATUS_SUCCESS) return 
> status;
> +
>  RtlEnterCriticalSection( &loader_section );
>  if ((status = process_attach( wm, (LPVOID)1 )) != STATUS_SUCCESS)
>  {
> @@ -2622,7 +2626,6 @@ void WINAPI LdrInitializeThunk( void *kernel_start, 
> ULONG_PTR unknown2,
>  static const WCHAR globalflagW[] = 
> {'G','l','o','b','a','l','F','l','a','g',0};
>  NTSTATUS status;
>  WINE_MODREF *wm;
> -LPCWSTR load_path;
>  PEB *peb = NtCurrentTeb()->Peb;
>  IMAGE_NT_HEADERS *nt = RtlImageNtHeader( peb->ImageBaseAddress );
>  
> @@ -2652,8 +2655,6 @@ void WINAPI LdrInitializeThunk( void *kernel_start, 
> ULONG_PTR unknown2,
>  if ((status = server_init_process_done()) != STATUS_SUCCESS) goto error;
>  
>  actctx_init();
> -load_path = NtCurrentTeb()->Peb->ProcessParameters->DllPath.Buffer;
> -if ((status = fixup_imports( wm, load_path )) != STATUS_SUCCESS) goto 
> error;
>  if ((status = alloc_process_tls()) != STATUS_SUCCESS) goto error;
>  if ((status = alloc_thread_tls()) != STATUS_SUCCESS) goto error;
>  heap_set_debug_flags( GetProcessHeap() );

You can't change the order of operations, for instance tls setup has to
be done after import fixup. Also I expect this will break Safedisc code
injection, you should add tests for the non-debugged case too.

-- 
Alexandre Julliard
julli...@winehq.org

Re: [PATCH 1/3] kernel32/tests: Add test for 'all processors' flag on Vista and newer.

[Francois Gouget]

On Thu, 25 Feb 2010, joerg-cyril.hoe...@t-systems.com wrote:

> Charles Davis wrote:
> 
> >I have noticed a change in configure behavior, though.
> Me too.  On MacOS.
> Since 1.1.39, Makefiles are created at the rate of ~ 1 per sec.
> It was much faster in 1.1.38 and before, I estimate ~6 files per second.

I think the point is that now most makefiles can be built in parallel 
with parallel make. So then it really depends how many cores you have of 
course.

It does have weird side-effects. Like make distclean creating new 
makefiles and thus running 'make depend'!


-- 
Francois Gouget   http://fgouget.free.fr/
I haven't lost my mind, it's backed up on tape around here somewhere...

Re: [PATCH] cmd: removed %CD% test.

[Paul Vriens]

On 03/16/2010 10:53 AM, Yann Droneaud wrote:

%CD% seems not supported on Windows NT 4.

The patch which introduce this test was based on MSDN documentation
and only tested on Windows XP


Hi Yann,

Winetestbot (https://winetestbot.geldorp.nl/index.pl) provides you with 
several Windows flavors for testing purposes.


--
Cheers,

Paul.

Re: [patch] DNS_SD bridge, v2

[Marcus Meissner]

On Mon, Mar 15, 2010 at 04:36:32AM -0600, C.W. Betts wrote:
> The following is an updated patch that actually builds and links.
> The patch does patch configure and config.h.in, both of which were generated 
> with an older version of autoconf and autoheader.

You can and should leave out both configure and config.h.in from the diff, it is
regenerated by Alexandre.


- You use "openal" in a configure.ac warning messages instead of dns_sd.

- how is non-presence of libdns_sd handled? It seems it will just fail
  to build then.

  It should load the called functions dynamically.

Ciao, Marcus

Re: [PATCH] cmd: added some expansion tests. (try 2)

[Yann Droneaud]

Le lundi 15 mars 2010 à 19:48 +0100, Paul Vriens a écrit :
> On 03/09/2010 01:15 PM, Yann Droneaud wrote:
> > diff --git a/programs/cmd/tests/test_builtins.cmd 
> > b/programs/cmd/tests/test_builtins.cmd
> > index ed2b75b..e346ffa 100644
> > --- a/programs/cmd/tests/test_builtins.cmd
> > +++ b/programs/cmd/tests/test_builtins.cmd
> > @@ -23,6 +23,21 @@ cd dummydir
> >   echo %~dp0
> >   cd ..
> >   rmdir dummydir
> > +echo %CD%
> 
> Hi Yann,
> 
> This one doesn't work on NT4:
> 
> http://test.winehq.org/data/tests/cmd.exe:batch.html
> 

batch.c:235: running TEST_BUILTINS.CMD test...
batch.c:152: Test failed: unexpected char 0x45 position 0 in line 19
(got 'ECHO is off.', wanted '@pwd@')
batch: 13 tests executed (0 marked as todo, 1 failure), 0 skipped.

> Could you have a look ?
> 

%CD% seems not supported under Windows NT. Sadly, this wasn't mentioned
in any documentation I've found.

Let's remove this test.

Regards

-- 
Yann Droneaud

Re: [PATCH] [WineDbg]: allow to specify which format to be used for integers in backtraces

[Dmitry Timoshkov]

Eric Pouech  wrote:

> Gdb uses decimal notation by default for integers, so do we.

GDB can use anything their developers think appropriate, my patch
to use hex was intended to match Wine's relay traces and win32
header constants. This patch will make finding matches impossible
again.

-- 
Dmitry.

Re: winhttp/url.c: Fix of invalid behaviour of WinHttpCrackUrl

[Paul Vriens]

On 03/15/2010 10:56 PM, Maciej Borsz wrote:

Fix of invalid behaviour of WinHttpCrackUrl when in url is '@'.

For example:
WinHttpCrackUrl(L"http://example.net/path?var1=exam...@example.com&var2=x&var3=y
", NULL,
NULL, sth)

returned:
scheme(L"http") host(L"example.com &var2=x&var3=y")
port(80) path(L"") extra(L"")

instead of:
scheme(L"http") host(L"example.net ") port(80)
path(L"/path/") extra(L"?var1=exam...@example.com
&var2=x&var3=y")



Hi Maciej,

Could you add a test for this to our testsuite?

You could use winetestbot (https://winetestbot.geldorp.nl/index.pl) to 
verify the behavior on several Windows flavors if needed.


--
Cheers,

Paul.

Re: wined3d: Fix ATI2N pitch and offset calculations

[Stefan Dösinger]

Am 16.03.2010 um 01:36 schrieb REalm:

> Fix ATI2N calculations to match Windows.
> Not sure if this is the right way, but it's better than previous old try.
> Might also be possible making ATI2N non compressed surface? Or some special 
> flag?
> This also fixes bug 21519: Mass Effect 2 crashes after start.

> -{WINED3DFMT_ATI2N,  4,  4,  16},
> +{WINED3DFMT_ATI2N,  1,  1,  1},
This way is OK IMO, it's certainly better than adding a special flag for just 
this surface. What we may think about is migrating all surfaces to the block 
notation and using blocksize 1x1, bpp bytes per block for uncompressed 
surfaces. That's beyond the scope of this patch though.