Re: [PATCH] shell32: do not crash wine control.exe nonexisting
Hi Marcus, On 06/06/12 10:17, Marcus Meissner wrote: Hi, wine control.exe joy crashed in this line, as it should be wine control.exe joy.cpl. The list is just not setup yet as we fail... Ciao, Marcus --- dlls/shell32/control.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/dlls/shell32/control.c b/dlls/shell32/control.c index cb080d5..b3eddb6 100644 --- a/dlls/shell32/control.c +++ b/dlls/shell32/control.c @@ -55,7 +55,7 @@ void Control_UnloadApplet(CPlApplet* applet) } if (applet-proc) applet-proc(applet-hWnd, CPL_EXIT, 0L, 0L); FreeLibrary(applet-hModule); -list_remove( applet-entry ); +if (applet-entry.next) list_remove( applet-entry ); HeapFree(GetProcessHeap(), 0, applet-cmd); HeapFree(GetProcessHeap(), 0, applet); } The way Wine standard list implementation works, it should not be NULL here. It seems that list_init call is missing where the CPlApplet is allocated. Cheers, Jacek
Re: [PATCH] shell32: do not crash wine control.exe nonexisting
On Wed, Jun 06, 2012 at 11:31:52AM +0200, Jacek Caban wrote: Hi Marcus, On 06/06/12 10:17, Marcus Meissner wrote: Hi, wine control.exe joy crashed in this line, as it should be wine control.exe joy.cpl. The list is just not setup yet as we fail... Ciao, Marcus --- dlls/shell32/control.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/dlls/shell32/control.c b/dlls/shell32/control.c index cb080d5..b3eddb6 100644 --- a/dlls/shell32/control.c +++ b/dlls/shell32/control.c @@ -55,7 +55,7 @@ void Control_UnloadApplet(CPlApplet* applet) } if (applet-proc) applet-proc(applet-hWnd, CPL_EXIT, 0L, 0L); FreeLibrary(applet-hModule); -list_remove( applet-entry ); +if (applet-entry.next) list_remove( applet-entry ); HeapFree(GetProcessHeap(), 0, applet-cmd); HeapFree(GetProcessHeap(), 0, applet); } The way Wine standard list implementation works, it should not be NULL here. It seems that list_init call is missing where the CPlApplet is allocated. The error handling that calls this leaves the Control_LoadApplet function before it is attached to the list head. list_add_head( panel-applets, applet-entry ); is not called before leaving the function. No other list_ functions are used by Control_LoadApplet. Not sure if this is right, or if there should be a entry init? Ciao, Marcus
Re: [PATCH] shell32: do not crash wine control.exe nonexisting
On 06/06/12 11:34, Marcus Meissner wrote: On Wed, Jun 06, 2012 at 11:31:52AM +0200, Jacek Caban wrote: Hi Marcus, On 06/06/12 10:17, Marcus Meissner wrote: Hi, wine control.exe joy crashed in this line, as it should be wine control.exe joy.cpl. The list is just not setup yet as we fail... Ciao, Marcus --- dlls/shell32/control.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/dlls/shell32/control.c b/dlls/shell32/control.c index cb080d5..b3eddb6 100644 --- a/dlls/shell32/control.c +++ b/dlls/shell32/control.c @@ -55,7 +55,7 @@ void Control_UnloadApplet(CPlApplet* applet) } if (applet-proc) applet-proc(applet-hWnd, CPL_EXIT, 0L, 0L); FreeLibrary(applet-hModule); -list_remove( applet-entry ); +if (applet-entry.next) list_remove( applet-entry ); HeapFree(GetProcessHeap(), 0, applet-cmd); HeapFree(GetProcessHeap(), 0, applet); } The way Wine standard list implementation works, it should not be NULL here. It seems that list_init call is missing where the CPlApplet is allocated. The error handling that calls this leaves the Control_LoadApplet function before it is attached to the list head. list_add_head( panel-applets, applet-entry ); is not called before leaving the function. No other list_ functions are used by Control_LoadApplet. Not sure if this is right, or if there should be a entry init? This usage of list is broken here as well. list_init should be called before list_add_head (so calling it early in initialization code will fix both problems). Cheers, Jacek
Re: [PATCH] shell32: do not crash wine control.exe nonexisting
Jacek Caban ja...@codeweavers.com writes: This usage of list is broken here as well. list_init should be called before list_add_head (so calling it early in initialization code will fix both problems). There's no reason to call list_init on list entries, it should only be called on the actual list. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH] shell32: do not crash wine control.exe nonexisting
On 06/06/12 11:52, Alexandre Julliard wrote: Jacek Caban ja...@codeweavers.com writes: This usage of list is broken here as well. list_init should be called before list_add_head (so calling it early in initialization code will fix both problems). There's no reason to call list_init on list entries, it should only be called on the actual list. Oh, right, sorry for misleading. I made wrong assumptions looking at the patch. Jacek
Re: [PATCH 3/5] d3drm: Handle texture associated with the materail when loading a mesh.
Christian Costa titan.co...@gmail.com writes: --- dlls/d3drm/meshbuilder.c | 37 + 1 files changed, 37 insertions(+), 0 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M d3drm.dll -T ../../.. -p d3drm_test.exe.so d3drm.c touch d3drm.ok d3drm.c:375: Test failed: No texture should be present wine: Unhandled page fault on write access to 0x00162708 at address 0x68353cb7 (thread 0009), starting debugger... -- Alexandre Julliard julli...@winehq.org
Re: [PATCH] shell32: do not crash wine control.exe nonexisting
On Wed, Jun 06, 2012 at 11:56:06AM +0200, Jacek Caban wrote: On 06/06/12 11:52, Alexandre Julliard wrote: Jacek Caban ja...@codeweavers.com writes: This usage of list is broken here as well. list_init should be called before list_add_head (so calling it early in initialization code will fix both problems). There's no reason to call list_init on list entries, it should only be called on the actual list. Oh, right, sorry for misleading. I made wrong assumptions looking at the patch. So, Alexandre, is my patch right or wrong? And if wrong, can you quickly fix it:) Ciao, Marcus
Re: Wine's support for reporting calling conventions
Hi Eric, Thanks for replying. I saw that in the DWARF spec and I was afraid that DWARF may not provide detailed Info. But I also read in the spec that the compilers use a DWARF extension feature to convey additional info such as calling convention for each routine. Is there a way to coax GCC to output that information? Maybe thru a target plugin? Thanks Roger On Jun 6, 2012, at 3:06 AM, Eric Pouech eric.pou...@orange.fr wrote: that's a limitation of dwarf format (IIRC, from the specs, you have either the default CC for your programming language/ABI, or a specific one without defining it further) FYII, the codeview format reports correctly this information note also that winedbg doesn't support calling functions in the debuggee, so this information is actually not used in winedbg A+ 2012/6/6, Roger Cruz roger_r_c...@yahoo.com: In dlls/dbghelp/dwarf.c, there is this snippet of code which appears to hard-code the calling convention to CALL_FAR_C. Does Wine not support reporting a function's calling convention correctly then? Is it a limitation of DWARF or just that it is not implemented? I can see that DWARF has a DW_AT_calling_convention field but when I examine a Wine DLL with objdump, it does not show this field in use. /* FIXME: assuming C source code */ sig_type = symt_new_function_signature(ctx-module, ret_type, CV_CALL_FAR_C); Thanks Roger -- -- Eric Pouech
Re: [PATCH] shell32: do not crash wine control.exe nonexisting
Marcus Meissner meiss...@suse.de writes: On Wed, Jun 06, 2012 at 11:56:06AM +0200, Jacek Caban wrote: On 06/06/12 11:52, Alexandre Julliard wrote: Jacek Caban ja...@codeweavers.com writes: This usage of list is broken here as well. list_init should be called before list_add_head (so calling it early in initialization code will fix both problems). There's no reason to call list_init on list entries, it should only be called on the actual list. Oh, right, sorry for misleading. I made wrong assumptions looking at the patch. So, Alexandre, is my patch right or wrong? And if wrong, can you quickly fix it:) The patch would work, but it's not very clean. It's better to avoid destroying objects that are not yet on the list. I have some more cleanups for that code that should address the issue. -- Alexandre Julliard julli...@winehq.org
Re: [2/2] user32: Add a test to demonstrate the z-order problem for a top level window with a region. Take 2.
Dmitry Timoshkov dmi...@baikal.ru writes: This version of the test tries harder to avoid races that could cause the test failures. It's not races, it's failing consistently here, even with your latest version. I don't think you can reliably test expose events processing from a Windows app. -- Alexandre Julliard julli...@winehq.org
Re: [2/2] user32: Add a test to demonstrate the z-order problem for a top level window with a region. Take 2.
Alexandre Julliard julli...@winehq.org wrote: This version of the test tries harder to avoid races that could cause the test failures. It's not races, it's failing consistently here, even with your latest version. I don't think you can reliably test expose events processing from a Windows app. It was mainly a showcase to demonsrate the problem to you, if it's not reliable enough, dropping it is ok, let's hope that the fix is ok this time. -- Dmitry.
Re: [PATCH 2/3] server: STATUS_MORE_PROCESSING_REQUIRED does not indicate that an async operation is complete (try 4).
Erich E. Hoover compho...@gmail.com writes: @@ -285,7 +285,9 @@ void async_set_result( struct object *obj, unsigned int status, unsigned int tot if (async-timeout) remove_timeout_user( async-timeout ); async-timeout = NULL; async-status = status; -if (async-data.cvalue) +if (status == STATUS_MORE_PROCESSING_REQUIRED) +async-status = STATUS_PENDING; +else if (async-data.cvalue) Why are you marking the async pending? That doesn't seem right, it's terminated at that point. -- Alexandre Julliard julli...@winehq.org
Re: urlmon: Use file content to verify MIME type reported by file protocol handler
On 06/06/12 13:58, Marvin wrote: 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=18815 Your paranoid android. === WXPPROSP3 (32 bit protocol) === protocol.c:1046: Test failed: unexpected call ReportResult protocol.c:1051: Test failed: hrResult = , expected: 80004004 protocol.c:2838: Test failed: Read failed: 0001 This is unrelated to my patch. Jacek
Re: urlmon: Use file content to verify MIME type reported by file protocol handler
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=18815 Your paranoid android. === WXPPROSP3 (32 bit protocol) === protocol.c:1046: Test failed: unexpected call ReportResult protocol.c:1051: Test failed: hrResult = , expected: 80004004 protocol.c:2838: Test failed: Read failed: 0001
Re: http://winetricks.googlecode.com/svn/trunk/src/install-gecko.sh also installs mono
It is not so much the technical details that are the problem. It is the LEGAL problems and potential legal problems that are at the root of my complaint. Telling me that I have the technical details wrong does not help. I have very carefully tried to move the discussion away from secondary technical points and onto the strategic issues that are not being addressed. Well, it didn't seem like you were interested in diving into specifics. I don't know the details of Microsoft's patents relating to .NET or any promises they've made regarding those patents. Even if I did, I'm probably not qualified to evaluate them. I simply assumed that because so many mainstream distros and open source projects seemed to think that use of Mono didn't pose a significant legal risk, it wasn't a problem to include it in Wine. If there's some specific action we could take to reduce our legal risk without impairing Wine's compatibility with Windows, we should probably do that and/or ask Mono to do it. However, it seems unlikely to me that there is something Wine could do in this area that Mono cannot, and I am not in a position to go looking for patents that might be relevant to our use case. This may be naive, but it seems obvious to me that the technical details are what ultimately determine the legal situation, and appearances have a much smaller effect. You also have to understand that this is a development mailing list, and it's full of programmers, not lawyers. So there's far more knowledge here of technical details (personally, I consider those details my responsibility) than legal strategy.
Re: windowscodecs: Add a stubbed out IWICMetadataBlockReader to TIFF decoder.
Looks good. Here are some notes in case you get around to implementing this before I do: I found it very surprising that no metadata handlers seem to implement IWICMetadataBlockReader, while many of them advertise that they can be found in other metadata formats. I'm guessing that metadata handlers return child IWICMetadataReader objects from the IWICMetadataReader interface, but I haven't tested this. It probably doesn't make sense to reimplement GetEnumerator for each decoder, and we should be able to make a common implementation based on the other methods. We should probably implement GetReaderByIndex based on CreateMetadataReaderFromContainer, which I'm guessing expects a copy of the image stream (using IWICStream because we can't use IStream::Clone) seeked to the beginning of some metadata, or a region of the image stream, maybe depending on the container format.
Re: http://winetricks.googlecode.com/svn/trunk/src/install-gecko.sh also installs mono
On Wed, Jun 6, 2012 at 3:36 PM, Vincent Povirk madewokh...@gmail.com wrote: It is not so much the technical details that are the problem. It is the LEGAL problems and potential legal problems that are at the root of my complaint. Telling me that I have the technical details wrong does not help. I have very carefully tried to move the discussion away from secondary technical points and onto the strategic issues that are not being addressed. Well, it didn't seem like you were interested in diving into specifics. I don't know the details of Microsoft's patents relating to .NET or any promises they've made regarding those patents. Even if I did, I'm probably not qualified to evaluate them. I simply assumed that because so many mainstream distros and open source projects seemed to think that use of Mono didn't pose a significant legal risk, it wasn't a problem to include it in Wine. If there's some specific action we could take to reduce our legal risk without impairing Wine's compatibility with Windows, we should probably do that and/or ask Mono to do it. However, it seems unlikely to me that there is something Wine could do in this area that Mono cannot, and I am not in a position to go looking for patents that might be relevant to our use case. This may be naive, but it seems obvious to me that the technical details are what ultimately determine the legal situation, and appearances have a much smaller effect. You also have to understand that this is a development mailing list, and it's full of programmers, not lawyers. So there's far more knowledge here of technical details (personally, I consider those details my responsibility) than legal strategy. The core of mono is safe. It is covered under ECMA-334 (C# language) and ECMA-335 (CLIR vm). The mono MS Compatibility Stack, which includes: - XML - ASP.NET - Windows.Forms - ADO.NET - Core cryptography - Transactions is a grey area now since the project is not part of Novell anymore. Novell and Microsoft had joint patent agreement, so there were no problems. So the question is, does wine-mono include the compatibility stack? - Matijn
Re: [PATCH 2/3] server: STATUS_MORE_PROCESSING_REQUIRED does not indicate that an async operation is complete (try 4).
On Wed, Jun 6, 2012 at 5:56 AM, Alexandre Julliard julli...@winehq.org wrote: Erich E. Hoover compho...@gmail.com writes: @@ -285,7 +285,9 @@ void async_set_result( struct object *obj, unsigned int status, unsigned int tot if (async-timeout) remove_timeout_user( async-timeout ); async-timeout = NULL; async-status = status; - if (async-data.cvalue) + if (status == STATUS_MORE_PROCESSING_REQUIRED) + async-status = STATUS_PENDING; + else if (async-data.cvalue) Why are you marking the async pending? That doesn't seem right, it's terminated at that point. That would be because I misread the MSDN article a little bit (either that or the one I just looked up is a different one from what I originally read). Would you like me to resubmit everything or just part 2 and 3? Erich Hoover ehoo...@mines.edu
Re: comctl: allow label edit only if treeview style allows editing
2012/6/4 Dan Kegel daniel.r.ke...@gmail.com: I had the same problem, and wrote a little script to skip the bad tests. It was written for buildbot, but can be run standalone. Try downloading http://winezeug.googlecode.com/svn/trunk/buildbot/dotests.sh and http://winezeug.googlecode.com/svn/trunk/buildbot/dotests_blacklist.txt then run sh dotests.sh goodtests That will skip all the tests known to hang or fail. (The list might be a bit out of date, but it's easy to add new tests to the blacklist.) Now that's much better! Thank you. I slightly modified the script and found that 5 tests from the good list fail with native comctl. Good indicator of areas that need more love :) -- Regards, Daniel
Re: [4/4] windowscodecs: Add WICIfdMetadataReader registration.
Marvin test...@testbot.winehq.org wrote: === WINEBUILD (build) === Patch failed to apply Because it depends on a not yet applied windowscodecs: Add metadata reader information to the registry. -- Dmitry.
Re: [4/4] windowscodecs: Add WICIfdMetadataReader registration.
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=18837 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
Re: [4/4] windowscodecs: Add WICIfdMetadataReader registration.
Dmitry Timoshkov dmi...@baikal.ru wrote: Marvin test...@testbot.winehq.org wrote: === WINEBUILD (build) === Patch failed to apply Because it depends on a not yet applied windowscodecs: Add metadata reader information to the registry. I should add, that the patch adds nothing new to the tests, it just moves around a couple of todo_wine here and there to reflect current state of IFD metadata reader tests under Wine, so it shouldn't change anything for Windows testbot runs. -- Dmitry.
