November 2007 - Wine-Devel - list.winehq.org

Question: How to link kernel32.dll.so to get loaded at a fixed address (0x7bf0000) each time in a Solaris environment

by Chris McKillroy

Hello everybody, I recently run into the following problem: I tried to use a DLL injection into a process started by a controller Process using an external code hooking dll (http://www.madshi.net/madCodeHookDescription.htm) to achieve some sort of datalink. In a windows environment the solution works stable and perfectly. (Controller Process NWNX4 as provided by nwnx4.org, child process nwn2server.exe, as provided by Obsidian - all legal and intended use). Under Solaris10 (wine version 0.9.49) the child process regularly crashed upon creation, respectivley when the dll was injected. After a lengthy debugging session it appeared that kernel32.dll.so always gets loaded to a varying address by the runtime linker, which seems to crash the whole procedure. I succeeded making a kernel32.dll.so which gets loaded to a constant address in Solaris by using the tool "crle" on Solarice, but I couldn't control the address - it appeared to be somewhat arbitrary which base address was chosen. The crash problem remained. I would like to try if the procedure would work if I could get a kernel32.dll.so which always gets loaded to the same address 0x7bf0000, as in standard windows. After a posting to the Solaris Linker mailing list we got an answer (http://mail.opensolaris.org/pipermail/tools-linking/2007-November/000945.ht…) which was designed to work with the SUN toolchain. My question now is: How would I have to change things (makefile or whatsever) to get kernel32.dll.so linked in a way to achive that it will be loaded to address 0x7bf0000each time under Solaris. Thanks Chris

Nov. 15, 2007

Re: taskmgr/perfpage.c simplification (RESEND)

by Alexandre Julliard

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > Another simplifcation I'd like to ping if you don't mind. > > ---------- Forwarded message ---------- > From: Gerald Pfeifer <gerald(a)pfeifer.com> > To: <wine-patches(a)winehq.org> > Date: Thu, 1 Nov 2007 16:14:28 +0100 (CET) > Subject: taskmgr/perfpage.c simplification > > CpuUsage and CpuKernelUsage are of type ULONG, so it does not make > sense checking whether they are less than 0. The checks should most likely done in PerfDataGetProcessorUsage before converting to ULONG. -- Alexandre Julliard julliard(a)winehq.org

Nov. 15, 2007

Re: Valgrind results for Nov 12 & 13

by Dmitry Timoshkov

"Dan Kegel" <dank(a)kegel.com> wrote: > On Nov 14, 2007 10:16 PM, Dmitry Timoshkov >> While looking at the valgrind reports above I noticed that a lot of >> warnings are triggered in NTDLL_queue_process_apc by the fact that >> not the whole apc_call_t union is initialized before passing it to >> the server. In contrast SERVER_START_REQ always initializes >> __server_request_info to 0 before the client starts to fill the fields. >> Probably that's the question to Alexandre whether we should memset(0) >> apc_call_t before filling it, or just ignore valgrind warnings. > > Oh, he'd undoubtedly prefer ignoring to memsetting. > But he would like it even better if we can > avoid sending unneeded bytes. Are the extra > bytes at the end (they ought to be)? If so, > whatever decides how many bytes to send could > be just a bit smarter. Since wineserver sequests are sent without an attempt to reduce the size of written data (and memset(0) is a part of SERVER_START_REQ macro) I'd assume that it's ok to do the same for server APC requests. Otherwise server calls need to be optimized as well. -- Dmitry.

Nov. 15, 2007

Re: Patch to make Wine prettier

by Alexander Nicolaysen Sørnes

On Sunday 11 November 2007 14:56:21 Fred . wrote: > Applications that run under Wine looks so legacy like Windows 95. > > This patch makes the software applications look a bit more modern and > prettier by changing the colors from the Windows 95-look to the > "Windows Classic"-look, the one in Windows ME/2000/2003. > > I have not yet tested the patch. Because I was unable to compile Wine > on my computer. > > The file should goto; > /wine/dlls/user32/resources/display.rc Great idea, but the patch does not change anything. Alexander N. Sørnes

Nov. 15, 2007

Re: Valgrind results for Nov 12 & 13

by Dan Kegel

On Nov 14, 2007 10:16 PM, Dmitry Timoshkov > While looking at the valgrind reports above I noticed that a lot of > warnings are triggered in NTDLL_queue_process_apc by the fact that > not the whole apc_call_t union is initialized before passing it to > the server. In contrast SERVER_START_REQ always initializes > __server_request_info to 0 before the client starts to fill the fields. > Probably that's the question to Alexandre whether we should memset(0) > apc_call_t before filling it, or just ignore valgrind warnings. Oh, he'd undoubtedly prefer ignoring to memsetting. But he would like it even better if we can avoid sending unneeded bytes. Are the extra bytes at the end (they ought to be)? If so, whatever decides how many bytes to send could be just a bit smarter. - Dan p.s. the mailing list archives seem to be not archiving new messages :-(

Nov. 15, 2007

Re: Valgrind results for Nov 12 & 13

by Dmitry Timoshkov

"Dan Kegel" <dank(a)kegel.com> wrote: > It seems that valgrind doesn't like Ubuntu 7.10; I had > to drop back to my Feisty system to generate good > valgrind stack dumps. And the tests didn't hang once! > > Results for the last two days are at > http://kegel.com/wine/valgrind/20071112/ > http://kegel.com/wine/valgrind/20071113/ While looking at the valgrind reports above I noticed that a lot of warnings are triggered in NTDLL_queue_process_apc by the fact that not the whole apc_call_t union is initialized before passing it to the server. In contrast SERVER_START_REQ always initializes __server_request_info to 0 before the client starts to fill the fields. Probably that's the question to Alexandre whether we should memset(0) apc_call_t before filling it, or just ignore valgrind warnings. -- Dmitry.

Nov. 15, 2007

Re: server: avoid sending uninitialized bytes in break_thread()

by Dan Kegel

On Nov 14, 2007 10:01 PM, Dan Kegel <dank(a)kegel.com> wrote: > In break_thread(), generate_debug_event() seems to > send the entire ExceptionInformation array regardless of how > many entries are used. The smart thing to do > would be to send only the used elements, but I > couldn't figure out how to do that. So here's > a quick fix that just zeroes that array before calling > generate_debug_event(). Is there a better way? [This time with patch.] (There's a similar problem on the client side, but there I think I see how to fix it right in send_debug_event().)

Nov. 15, 2007

server: avoid sending uninitialized bytes in break_thread()

by Dan Kegel

In break_thread(), generate_debug_event() seems to send the entire ExceptionInformation array regardless of how many entries are used. The smart thing to do would be to send only the used elements, but I couldn't figure out how to do that. So here's a quick fix that just zeroes that array before calling generate_debug_event(). Is there a better way? Found by running the Word Viewer 97 under valgrind: 000d: wait_debug_event() = 0 { pid=000a, tid=000b, wait=(nil), event={exception,{code=80000003,flags=0,rec=(nil),addr=0x40007f0,params={},first=1} } Syscall param writev(vector[1]) points to uninitialised byte(s) at 0x40007F2: (within /lib/ld-2.5.so) by 0x806AF20: call_req_handler (request.c:249) by 0x8056075: main_loop (fd.c:523) Address 0x451AAB8 is 24 bytes inside a block of size 88 alloc'd by 0x806A167: set_reply_data_size (request.c:200) by 0x80510A6: req_wait_debug_event (request.h:96) by 0x806AFC7: call_req_handler (request.c:286) by 0x8056075: main_loop (fd.c:523) BTW, here's how I ran word viewer under valgrind: wordview.sh: WINEDIR=$HOME/wine-git; VALGRIND_CMD="/usr/local/valgrind-3.2.3-wine/bin/valgrind --trace-children=yes --gen-suppressions=all --suppressions=$WINEDIR/tools/valgrind-suppressions --leak-check=full --num-callers=20 " WINE=$WINEDIR/wine wget http://downloads.pcworld.com/pub/new/business/word_processing/wordview.exe cp wordview.exe ~/.wine/drive_c/wvinstall.exe mv ~/.wine/dosdevices/z: ~/.wine/dosdevices/oldz cd ~/.wine/drive_c $VALGRIND_CMD $WINE wvinstall.exe /q cd ../.. mv ~/.wine/dosdevices/oldz ~/.wine/dosdevices/z:

Nov. 15, 2007

Re: server: Make timer id allocation algorithm conform to the Windows one

by Dmitry Timoshkov

"Uwe Bonnes" <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: > Dmitry> Hello, this patch should fix the problem reported in the bug > Dmitry> 10343. My test which calls SetTimer in an infinite loop shows > Dmitry> that XP starts to allocate timer ids at 0x7fff and goes > Dmitry> backwards to 0x101, then restarts from 0x7fff. > > Isn't this worth a test suite case? As explained in the referenced bug it's not very easy to test this behaviour. -- Dmitry.

Nov. 15, 2007

Re: AppDB down =(

by Alexander Nicolaysen Sørnes

On Wednesday 14 November 2007 23:22:00 Jeremy Newman wrote: > I restarted it. I still have no idea how it gets into this state. The > logs have not been much help. I think we have exposed a bug in mysql > itself, as we did not have these issues until we upgraded to ver 5. > > On Wed, 2007-11-14 at 14:42 -0600, John Klehm wrote: > > Erm yeah the appdb is down... too many connections...sad times. > > > > John Actually it was because of a patch I sent yesterday. The AppDB user tables are not exported so I missed a bug in my testing. I sent a fix earlier today, Chris will probably apply it in a few hours. Alexander N. Sørnes

Nov. 15, 2007