Re: Alexandre Julliard : ntdll: Add a wrapper to call the thread entry point for broken apps.
On Mar 14, 2007, at 7:25 AM, Alexandre Julliard wrote:
Module: wine
Branch: master
Commit: 773febb04213cf014b007a83744a66544d6c
URL:http://source.winehq.org/git/wine.git/?
a=commit;h=773febb04213cf014b007a83744a66544d6c
Author: Alexandre Julliard [EMAIL PROTECTED]
Date: Wed Mar 14 12:28:38 2007 +0100
ntdll: Add a wrapper to call the thread entry point for broken apps.
---
dlls/ntdll/thread.c | 25 ++---
1 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/dlls/ntdll/thread.c b/dlls/ntdll/thread.c
index 9656331..d0871a1 100644
--- a/dlls/ntdll/thread.c
+++ b/dlls/ntdll/thread.c
@@ -349,6 +349,26 @@ static PUNHANDLED_EXCEPTION_FILTER
get_unhandled_exception_filter(void)
return unhandled_exception_filter;
}
+#ifdef __i386__
+/* wrapper for apps that don't declare the thread function
correctly */
+extern DWORD call_thread_entry_point( PRTL_THREAD_START_ROUTINE
entry, void *arg );
+__ASM_GLOBAL_FUNC(call_thread_entry_point,
+ pushl %ebp\n\t
+ movl %esp,%ebp\n\t
+ subl $4,%esp\n\t
+ pushl 12(%ebp)\n\t
+ movl 8(%ebp),%eax\n\t
+ call *%eax\n\t
+ leave\n\t
+ ret );
+#else
+static inline DWORD call_thread_entry_point
( PRTL_THREAD_START_ROUTINE entry, void *arg )
+{
+LPTHREAD_START_ROUTINE func = (LPTHREAD_START_ROUTINE)rtl_func;
Should the above have entry instead of rtl_func?
+return func( arg );
+}
+#endif
+
/
**
*
* call_thread_func
*
@@ -356,16 +376,15 @@ static PUNHANDLED_EXCEPTION_FILTER
get_unhandled_exception_filter(void)
*/
static void DECLSPEC_NORETURN call_thread_func
( PRTL_THREAD_START_ROUTINE rtl_func, void *arg )
{
-LPTHREAD_START_ROUTINE func = (LPTHREAD_START_ROUTINE)rtl_func;
DWORD exit_code;
BOOL last;
MODULE_DllThreadAttach( NULL );
if (TRACE_ON(relay))
-DPRINTF( %04x:Starting thread proc %p (arg=%p)\n,
GetCurrentThreadId(), func, arg );
+DPRINTF( %04x:Starting thread proc %p (arg=%p)\n,
GetCurrentThreadId(), rtl_func, arg );
-exit_code = func( arg );
+exit_code = call_thread_entry_point( rtl_func, arg );
/* send the exit code to the server */
SERVER_START_REQ( terminate_thread )
Re: Alexandre Julliard : ntdll: Add a wrapper to call the thread entry point for broken apps.
Ken Thomases [EMAIL PROTECTED] writes:
+#else
+static inline DWORD call_thread_entry_point (
PRTL_THREAD_START_ROUTINE entry, void *arg )
+{
+LPTHREAD_START_ROUTINE func = (LPTHREAD_START_ROUTINE)rtl_func;
Should the above have entry instead of rtl_func?
Yes of course, thanks for spotting this.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: Add very basic initial tests for d3drm
Vijay Kiran Kamuju [EMAIL PROTECTED] wrote:
+START_TEST(vector)
+{
+ init_function_pointers();
+
+ VectorTest();
+ QuaternionTest();
What happens if init_function_pointers() failed?
--
Dmitry.
Re: Add very basic initial tests for d3drm
Hi,
Fixed this one, and it requires d3drmdef.h patch earlier I sent.
Is the d3drmdef.h patch ok?
Will be sending the corrected version soon.
Thanks,
VJ
On 3/14/07, Dmitry Timoshkov [EMAIL PROTECTED] wrote:
Vijay Kiran Kamuju [EMAIL PROTECTED] wrote:
+START_TEST(vector)
+{
+ init_function_pointers();
+
+ VectorTest();
+ QuaternionTest();
What happens if init_function_pointers() failed?
--
Dmitry.
Need help with SymInitializeW
Hi All, Im trying to debug a crash in Everquest 2, (bug 7705) and am hoping someone here can help. The crash seems to be linked to the process calling SymInitializeW a second time (its called once at the start of the process, and works ok) On the second call to the function we see an error fixme:dbghelp:SymInitializeW what to do ?? By putting some tracing in here, I noticed that when the function is called the first time, the call to process_find_by_handle(hProcess) returns null, and once the SymInitializeW function calls EnumerateLoadedModules, process_find_by_handle returns a process id. In the second call, the process_find_by_handle(hProcess) returns the same process id as before, however, when the SymInitializeW function calls EnumerateLoadedModules, process_find_by_handle returns a different process id. Should SymInitializeW be called multiple times by a process? Is it possible that a problem has already occured, and this is called as a result? Or is it possible that SymInitializeW itself is the cause of the crash? Any ideas? Thanks Below is some trace I got when I put in some extra debug. First call: fixme:dbghelp:SymInitialize Calling SymInitializeW 0x(0x LC:\\Program Files\\Sony\\EverQuest II 1) fixme:dbghelp:process_find_by_handle Returning process handle (nil) fixme:dbghelp:process_find_by_handle Returning process handle 0x16c5d0 Second Call: fixme:dbghelp:SymInitialize Calling SymInitializeW 0x(0x (null) 1) fixme:dbghelp:process_find_by_handle Returning process handle 0x16c5d0 fixme:dbghelp:SymInitializeW what to do ?? fixme:dbghelp:process_find_by_handle Returning process handle 0x3a8f9a0
A SoC proposal for discussion: PE Packers
Hello all, I didn't find a webpage on the wiki about SoC'07. However, I would like to suggest a SoC proposal for your comments. It seems to me that there are many bugs floating in bugzilla that are related to PE packers. Because applications just crash due to being packed, this seems a requirement for Wine 1.0. For a SoC, it would be very interesting if one student takes the mission of fixing bugs related to PE packers such as: - Shrinker (#2608, #2619) - Neolite (seems ok see #4709) - Aspack (#6129) - Armadillo (#219) This would require to define the list of PE packers to support and which versions (as anti debugging tricks may differ depending of the version). Best, Julien
Re: comctl32: status bar test - Reorganization and Message Sequencing[2/2]
Alex Arazi [EMAIL PROTECTED] wrote: This is a two part patch. The first part is status_reorganization.patch which divides the test routine into function calls. The second part is status_messages.patch which adds message sequencing. Are you guys planning to monitor test.winehq.org and fix all the failures caused by new message tests? -- Dmitry.
Re: comctl32: status bar test - Reorganization and Message Sequencing[2/2]
On 3/14/07, Dmitry Timoshkov [EMAIL PROTECTED] wrote: Alex Arazi [EMAIL PROTECTED] wrote: This is a two part patch. The first part is status_reorganization.patch which divides the test routine into function calls. The second part is status_messages.patch which adds message sequencing. Are you guys planning to monitor test.winehq.org and fix all the failures caused by new message tests? -- Dmitry. That's a good question. The class the students are taking will be over by the end of next week. I've tried to help them get it right the first time by running their tests on several different Windows platforms and making sure the tests pass on all of them. BTW, are we evert going to put up a better fron page for test.winehq.org? It still says 403 Forbidden. - Lei
Re: comctl32: status bar test - Reorganization and MessageSequencing[2/2]
Lei Zhang [EMAIL PROTECTED] wrote: That's a good question. The class the students are taking will be over by the end of next week. I've tried to help them get it right the first time by running their tests on several different Windows platforms and making sure the tests pass on all of them. To my experience there are always windows configurations that cause the failures I haven't seen. Since I have written many user32 message tests I regularly go to test.winehq.org and try to fix the failures in my tests. BTW, are we evert going to put up a better fron page for test.winehq.org? It still says 403 Forbidden. Just go to directly to test.winehq.org/data. -- Dmitry.
Re: [advapi32/tests 1/2] Use GetModuleHandle and skip
On Tue, 13 Mar 2007, Paul Vriens wrote: [...] as advapi32 is already linked to, we can use GetModuleHandle. -if (!(module = LoadLibrary( advapi32.dll ))) return; +if (!(module = GetModuleHandleA( advapi32.dll ))) return; Well, since we're already linked to advapi32.dll, there's no need to check that GetModuleHandleA() does not return NULL. Plus if we were to check we should use skip(). -- Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/ May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels.
Re: [advapi32/tests 1/2] Use GetModuleHandle and skip
Francois Gouget wrote: On Tue, 13 Mar 2007, Paul Vriens wrote: [...] as advapi32 is already linked to, we can use GetModuleHandle. -if (!(module = LoadLibrary( advapi32.dll ))) return; +if (!(module = GetModuleHandleA( advapi32.dll ))) return; Well, since we're already linked to advapi32.dll, there's no need to check that GetModuleHandleA() does not return NULL. Plus if we were to check we should use skip(). I'll produce another patch to get rid of that (those) as this one is already applied. Cheers, Paul.
Re: Need help with SymInitializeW
Kapila De Silva a écrit : Hi All, Im trying to debug a crash in Everquest 2, (bug 7705) and am hoping someone here can help. I'll send a fix later on for the FIXME, but it's unlikely this is what's causing the crash So, you have to understand where the 0x as an address comes from. sometimes, +relay helps figuring that out, but YMMV A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: Need help with SymInitializeW
Eric Pouech wrote: Kapila De Silva a écrit : Hi All, Im trying to debug a crash in Everquest 2, (bug 7705) and am hoping someone here can help. I'll send a fix later on for the FIXME, but it's unlikely this is what's causing the crash So, you have to understand where the 0x as an address comes from. sometimes, +relay helps figuring that out, but YMMV A+ Hi, just wanted to report that Process Explorer also calls it with 0x when viewing the 'System Information': trace:dbghelp:SymInitializeW (0x (null) 0) trace:dbghelp:elf_load_file Processing elf file 'Lwine-kthread' at trace:dbghelp:elf_load_file Processing elf file 'L/usr/lib/qt-3.3/bin/wine-kthread' at trace:dbghelp:elf_load_file Processing elf file 'L/usr/kerberos/bin/wine-kthread' at trace:dbghelp:elf_load_file Processing elf file 'L/usr/local/bin/wine-kthread' at Could 0x mean something like system-wide? Cheers, Paul.
Re: Need help with SymInitializeW
Paul Vriens a écrit : Eric Pouech wrote: Kapila De Silva a écrit : Hi All, Im trying to debug a crash in Everquest 2, (bug 7705) and am hoping someone here can help. I'll send a fix later on for the FIXME, but it's unlikely this is what's causing the crash So, you have to understand where the 0x as an address comes from. sometimes, +relay helps figuring that out, but YMMV A+ Hi, just wanted to report that Process Explorer also calls it with 0x when viewing the 'System Information': trace:dbghelp:SymInitializeW (0x (null) 0) trace:dbghelp:elf_load_file Processing elf file 'Lwine-kthread' at trace:dbghelp:elf_load_file Processing elf file 'L/usr/lib/qt-3.3/bin/wine-kthread' at trace:dbghelp:elf_load_file Processing elf file 'L/usr/kerberos/bin/wine-kthread' at trace:dbghelp:elf_load_file Processing elf file 'L/usr/local/bin/wine-kthread' at Could 0x mean something like system-wide? Cheers, Paul. in that cas 0x is the default handle to the current process, and is never derefenced... include/winbase.h:#define GetCurrentProcess() ((HANDLE)0x) A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: Makefiles: Be less verbose when performing make rules by only printing the command being executed and the source and/or target file.
Robert Shearman a écrit : The old behaviour can be turned back on by setting the V environment variable to 1 (e.g. make V=1). a couple of more comments (mostly not yet converted rules): - the MAKEDEP rule in Make.rules.in isn't handled yet (suggestion [DEPEND] $SRC(DIR)) - most of exec rule in tools/*/Makefile.in miss the MAKERULE stuff - ditto in loader (and the version-stamp could be handled too) - in dlls/Makedlls.rules.in, all lib/def/.a stuff isn't handled is there any reason why the Linking... rule has a different format than the others ? now I wish we could also get rid of the message for recursive calls to make A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: Submitting winetricks to winehq tree?
On 3/14/07, Dan Kegel [EMAIL PROTECTED] wrote: I haven't been villified yet, so let me try harder. Should winetricks be committed to the winehq tree? It would be handy for people triaging Wine bugs to see if e.g. native dcom, odbc, or corefonts hide a bug. I've uploaded a new version to http://kegel.com/wine/winetricks Mainly it adds a -q option to make all the installers quiet, but it also includes lots of little improvements sent in by Detlef and Saulius. Here's the new usage message: Usage: winetricks [options] package [package] ... This script can help you prepare your system for Windows applications that mistakenly assume all users' systems have all the needed redistributable runtime libraries or fonts. Options: -q quiet. You must have already agreed to the EULAs. -v Verbose Packages: art2kmin Access 2000 runtime. License required! corefonts Install MS Times, Arial fonts dcom98 Install native DCOM, override the Wine implementation fakeie6Set registry to claim IE6sp1 is installed mdac27 Microsoft ODBC drivers, etc. mfc40 mono1.1mono 1.1.13-gtksharp-2.8.2 mono1.2mono 1.2.3.1-gtksharp-2.8.3 vbvm50 Visual Basic 5 runtime vbrun60Visual Basic 6 runtime vcrun6 vc6redist from VS6sp4, including mfc42 wsh51 Windows Scripting Host 5.1 I don't think winetricks should be a part of the Wine tree. It's a great developer tool, but it could potentially be abused by users to run with native libs like IE, DCOM, MSI, etc more so than they would otherwise. The fact that the script downloads and installs non-free software, especially from Microsoft, is a connection that we should not accept officially by committing it to the tree. All of that aside, it's a nice script that has been very useful for debugging, and I'm sure others find it equally useful. -- James Hawkins
Re: Submitting winetricks to winehq tree?
It looks a lot like a command-line version of what wine-doors aims to be, right? Only the installing software aspect, and not the dynamic aspect of repositories and such. On 3/14/07, Stefan Dösinger [EMAIL PROTECTED] wrote: Am Mittwoch 14 März 2007 20:01 schrieb Dan Kegel: I haven't been villified yet, so let me try harder. Should winetricks be committed to the winehq tree? It would be handy for people triaging Wine bugs to see if e.g. native dcom, odbc, or corefonts hide a bug. I haven't deeply looked at it yet(only the application list), but I am not sure what the answer is. For one part it is dangerous that people start using it to install native dcom and ignoring dcom bugs. Though considering the complexity of dcom, I don't think that anyone who does not know why he/she should not use native dcom would suddenly start fixing builtin dcom bugs. But it would reduce the number of regression testers and regression reporters because it would be much easier to switch to native dcom than to bisect and report a dcom regression. I think the other things like the vbo runtime, odbc drivers, ..., are out of scope for wine anyway, so no danger in that. Appart of dcom I'd say yes. With dcom I can't really answer this :-/ -- Cheers, Bryan
Re: comctl32: register all the controls in DllMain (fixes bug #7641)
Mikołaj Zalewski wrote: comctl32 version 5.82 (at least the one that comes with a fully patched Windows XP) and 6.0 register all the controls in DllMain. InitCommonControlsEx is just a dummy function. Could it be that 6.0 only registers those controls listed using window class dependencies in the manifest file? If what you say about 5.82 is true your patch is correct though ofcourse. Felix
Re: Submitting winetricks to winehq tree?
Hi, On 14.03.2007 20:01, Dan Kegel wrote: I haven't been villified yet, so let me try harder. Should winetricks be committed to the winehq tree? It would be handy for people triaging Wine bugs to see if e.g. native dcom, odbc, or corefonts hide a bug. Sorry if this has been answered before, but is winetricks a newer version of winetools? Regards, Carl-Daniel
Re: [2/3] kernel32: GlobalMemoryStatusEx: return the size of physicalmemory + swapsize in ullTotalPageFile/ullAvailPageFile
Fabian Bieler [EMAIL PROTECTED] wrote: -/* Project2k refuses to start if it sees less than 1Mb of free swap */ -if (lpmemex-ullTotalPageFile lpmemex-ullTotalPhys) -lpmemex-ullTotalPageFile = lpmemex-ullTotalPhys; -if (lpmemex-ullAvailPageFile lpmemex-ullAvailPhys) -lpmemex-ullAvailPageFile = lpmemex-ullAvailPhys; +/* Win98 returns only the swapsize in ullTotalPageFile/ullAvailPageFile, + WinXP returns the size of physical memory + swapsize; + mimic the behavior of XP: +*/ +lpmemex-ullTotalPageFile += lpmemex-ullTotalPhys; +lpmemex-ullAvailPageFile += lpmemex-ullAvailPhys; Why did you remove a comment about Project2k? It helps to understand what are the constrains of the API, and helps to avoid chasing the same bug once again. -- Dmitry.
Re: Submitting winetricks to winehq tree?
Carl-Daniel wrote: Sorry if this has been answered before, but is winetricks a newer version of winetools? No. Winetricks (http://www.kegel.com/wine/winetricks ) is a single 11KB shell script. It's a tiny command line tool that only knows how to install Microsoft redistributable libraries (and fonts), and set a registry key or two. For instance, if you're trying to install or run an application, but it fails with import_dll Library MSVBVM60.DLL not found, you can fix it with $ winetricks vbrun60 Or if you're trying to install an app, but it fails with Sorry, this application requires IE6, you can fix it without really installing IE6 by setting the right registry key. Winetricks makes this easy; just do $ winetricks fakeie6 etc. etc. Essentially, Winetricks just automates things one would normally have to look up in the Wine wiki, and it does it in the simplest possible way. Winetools ( http://www.von-thadden.de/Joachim/WineTools/ ) can do some of that, but it's really a different beast. It's a set of 150 or so files with a fancy GUI. Each of the files is a recipe for installing a particular Windows application. It is aimed at people who just want to run apps and not understand things. It is bad because, instead of working to improve Wine to make apps easy to install, it papers over the problems. And then there's Wine-Doors ( http://www.wine-doors.org ), which is like Winetools with delusions of grandeur. They seem to want to reinvent apt-get for no particular reason, and as far as I can tell, they intend to have a central server from which you can download copies of e.g. Photoshop with it. This doesn't seem legal, offhand, but I can't find their mailing list archive to see if anyone has asked them about this fine point. IMHO both Winetools and Wine Doors are mostly harmful, but they do have a real benefit for users. Winetricks is a bit like the non-harmful 1% of Winetools. If we don't provide something like Winetricks, more people might be driven to Winetools, and it'd be nice to prevent that. - Dan
Re: Submitting winetricks to winehq tree?
On 3/14/07, Dan Kegel [EMAIL PROTECTED] wrote: And then there's Wine-Doors ( http://www.wine-doors.org ), which is like Winetools with delusions of grandeur. They seem to want to reinvent apt-get for no particular reason, and as far as I can tell, they intend to have a central server from which you can download copies of e.g. Photoshop with it. This doesn't seem legal, offhand, but I can't find their mailing list archive to see if anyone has asked them about this fine point. I think the idea with the WineDoors deployment method is kind of like what CrossOver does with rpm bottles and rpm deployment. By using RPM or Alien to convert the bottles in to apt packages, an enterprise customer can push out a preconfigured bottle to hundreds or thousands of workstations using existing package management tools. Currently Wine has no enterprise support for this except buying CrossOver. Of course it seems WineDoors would still require the third party application to be installed but at least it would be automated. -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Help with debug
Hi, I have been debugging a problem today and am running low on batteries. I am hoping somebody can look at the attached snippet of log and point me in the right direction. From what I can tell, there is a DLL called snoopy.dll that does a whole bunch of allocs and reallocs and then tries to reference a NULL pointer which causes an unhandled exception. The code goes through a loop and does not always crash on the same iteration, but it always seems to crash at the same address. This code does not crash on Windows. Just getting lucky? Unfortunately I do not have the sources to this code, so it makes life a little more difficult. Any good ideas for my next step in debugging? Thanks, Phil 000e:Call ntdll.RtlAllocateHeap(4121,,0030) ret=7c3416b3 000e:trace:heap:RtlAllocateHeap (0x4121,0002,0030): returning 0x46927938 000e:Ret ntdll.RtlAllocateHeap() retval=46927938 ret=7c3416b3 000e:Call ntdll.RtlReAllocateHeap(4121,,4692a240,0238) ret=7c3527e9 000e:trace:heap:RtlReAllocateHeap (0x4121,0002,0x4692a240,0238): returning 0x46927970 000e:Ret ntdll.RtlReAllocateHeap() retval=46927970 ret=7c3527e9 000e:trace:seh:__regs_RtlRaiseException code=c005 flags=0 addr=0x1133572a 000e:trace:seh:__regs_RtlRaiseException info[0]= 000e:trace:seh:__regs_RtlRaiseException info[1]= 000e:trace:seh:__regs_RtlRaiseException eax=0001 ebx= ecx= edx= esi=456b68b8 edi=46929d50 000e:trace:seh:__regs_RtlRaiseException ebp=456b6880 esp=456b6598 cs=0073 ds=007b es=007b fs=003b gs=0033 flags=00010246 000e:Call ntdll.RtlEnterCriticalSection(4148f460) ret=41440765 000e:Ret ntdll.RtlEnterCriticalSection() retval= ret=41440765 000e:Call ntdll.RtlLeaveCriticalSection(4148f460) ret=414407a6 000e:Ret ntdll.RtlLeaveCriticalSection() retval= ret=414407a6 000e:trace:seh:EXC_CallHandler calling handler at 0x113f6cae code=c005 flags=0 ... Unhandled exception: page fault on read access to 0x in 32-bit code (0x1133572a). Backtrace: =1 0x1133572a in snoopy (+0x18572a) (0x456b6880) 2 0x11337e52 in snoopy (+0x187e52) (0x) 0x1133572a: movl 0x0(%ebx),%ecx Modules: Module Address Debug info Name (140 modules) PE 0x111b-1149b000 Export snoopy Threads: process tid prio (all id:s are in hex) 00160 00150 00140 00120 00100 000f0 000e0 == 000d0 000c0 000b0 000a0 00090
Re: Help with debug
On 3/15/07, Phil Lodwick [EMAIL PROTECTED] wrote: Hi, I have been debugging a problem today and am running low on batteries. I am hoping somebody can look at the attached snippet of log and point me in the right direction. From what I can tell, there is a DLL called snoopy.dll that does a whole bunch of allocs and reallocs and then tries to reference a NULL pointer which causes an unhandled exception. The code goes through a loop and does not always crash on the same iteration, but it always seems to crash at the same address. This code does not crash on Windows. Just getting lucky? Unfortunately I do not have the sources to this code, so it makes life a little more difficult. Any good ideas for my next step in debugging? Try do a +all trace and see what the thread was doing just before the crash. Failing that, you'll have to run it winedbg and disassemble around the crashed instruction and try decipher what it's doing. Thanks, Phil Good luck Damjan
Re: comctl32: register all the controls in DllMain (fixes bug #7641)
Could it be that 6.0 only registers those controls listed using window class dependencies in the manifest file? If what you say about 5.82 is true your patch is correct though ofcourse. I've checked both 5.82 and 6.0 (with a standard manifest) and both registers all the classes. I don't know if it's possible to list window classes dependancies in the manifest and how comctl 6.0 treats it. But as currenly we don't parse the manifest file we couldn't do anything with this. Mikolaj Zalewski
