December 2005 - Wine-Devel - list.winehq.org

Re: [NDR] Implement NdrClientCall2 and NdrServerCall2

by Detlef Riekenberg

Am Donnerstag, den 01.12.2005, 00:39 -0600 schrieb Robert Shearman: > [NDR] Implement NdrClientCall2 and NdrServerCall2 > [NDR] Fix handle support for stubless objects > [NDR] Fix Accessing Arguments in NdrClientCall2 Hi Rob. I tested your Patches with printui.dll and winspool.drv (from w2k) and got only "RPC_X_WRONG_STUB_VERSION" --- cut --- trace:rpc:NdrClientCall2 MIDL stub version = 0x5030117 fixme:rpc:NdrClientCall2 RPC_FC_BIND_GENERIC --- cut --- Then i commented out the RpcRaiseException() after the fixme and run: wine rundll32 printui.dll,PrintUIEntry /s The Server-Properties-Window opens and react on the Mouse, but the Fields are Empty or filled with Garbage. (same garbage as buildin winspool.drv with my patch for OpenPrinter) I attached an updated log to bug 3105 Thanks for your work on RPC. -- By By ... ... Detlef

Dec. 11, 2005

Re: Why Steam fails [VirtualAlloc]

by Rob Shearman

Ivan Gyurdiev wrote: > 3. Fedora default prelink flags are: > > # Options to pass to prelink > # -m Try to conserve virtual memory by allowing overlapping > # assigned virtual memory slots for libraries which > # never appear together in one binary > # -R Randomize virtual memory slot assignments for libraries. > # This makes it slightly harder for various buffer overflow > # attacks, since library addresses will be different on each > # host using -R. > PRELINK_OPTS=-mR > > I haven't changed those... should I? Remove the R option from above. That will cause you to have a VM layout with less gaps and more contiguous memory. If this still doesn't work, you will have to look at /proc/<pid>/maps to see why the address space is so fragmented. Rob

Dec. 11, 2005

Re: ntdll: Program could modify Dr* registers in segv_handler too.

by Peter Beutner

Vitaliy Margolen schrieb: > Sunday, December 11, 2005, 10:36:39 AM, Peter Beutner wrote: > >>Vitaliy Margolen schrieb: >> >>>Sunday, December 11, 2005, 9:07:06 AM, Peter Beutner wrote: >>> >>> >>>>Vitaliy Margolen schrieb: >>>> >>>> >>>>>ChangeLog: >>>>>ntdll: Program could modify Dr* registers in segv_handler too. >>>>> >>>> >>>>Doesn't every exception handler could modify these registers? >>>>So probably it would be better to put this check into RtlRaiseException? >>> >>>Nope can't. __regs_RtlRaiseException is common for all the platforms >>>(implemented in dlls/ntdll/exception.c). While Dr* registers are not >>>available on all the platforms. > > >>What about putting some >>#ifdef __i386__ >>... >>#endif >>around it? > > > That's what signal_*.c are for... The name suggests it's more about signal handling than a place to throw every arch dependent code in it ;) But that's not the point. I just thought it might not be the best solution to duplicate that check in every signal handler. Besides what about somebody changes the Dr* registers in an exception handler invoked by an exception raised by the application via RaiseException(i.e. not via a signal handler called by the kernel)? *Every* installed exception handler can change the registers in the CONTEXT structure, thats why I think it would be the easiest way to implement it in __regs_RtlRaiseException.

Dec. 11, 2005

Re: ntdll: Program could modify Dr* registers in segv_handler too.

by Vitaliy Margolen

Sunday, December 11, 2005, 10:36:39 AM, Peter Beutner wrote: > Vitaliy Margolen schrieb: >> Sunday, December 11, 2005, 9:07:06 AM, Peter Beutner wrote: >> >>>Vitaliy Margolen schrieb: >>> >>>>ChangeLog: >>>>ntdll: Program could modify Dr* registers in segv_handler too. >>>> >>> >>>Doesn't every exception handler could modify these registers? >>>So probably it would be better to put this check into RtlRaiseException? >> >> Nope can't. __regs_RtlRaiseException is common for all the platforms >> (implemented in dlls/ntdll/exception.c). While Dr* registers are not >> available on all the platforms. > What about putting some > #ifdef __i386__ > ... > #endif > around it? That's what signal_*.c are for...

Dec. 11, 2005

Re: ntdll: Program could modify Dr* registers in segv_handler too.

by Peter Beutner

Vitaliy Margolen schrieb: > Sunday, December 11, 2005, 9:07:06 AM, Peter Beutner wrote: > >>Vitaliy Margolen schrieb: >> >>>ChangeLog: >>>ntdll: Program could modify Dr* registers in segv_handler too. >>> >> >>Doesn't every exception handler could modify these registers? >>So probably it would be better to put this check into RtlRaiseException? > > Nope can't. __regs_RtlRaiseException is common for all the platforms > (implemented in dlls/ntdll/exception.c). While Dr* registers are not > available on all the platforms. What about putting some #ifdef __i386__ ... #endif around it?

Dec. 11, 2005

Re: WinAPI testing inside a machine emulator

by Detlef Riekenberg

Am Freitag, den 25.11.2005, 01:11 +0200 schrieb Saulius Krasuckas: > > BTW, how do you all folks think -- is it reliable approach to test WinAPI > > inside a machine emulator, like a QEmu? IMHO, only using "Real Hardware" for Regression-Test give us much less Results. > "machine emulators cannot shoot 100% of original OS functioning". qemu is really new compared to vmware/virtualpc. I joined qemu-devel and started to report our/my problems with qemu. > > I saw some non-failing results once from Detlef qemulated box while on > > other boxes tests were failing. This was "kernel32:threads" on qemu/win98se -- By By ... ... Detlef

Dec. 11, 2005

Re: ntdll: Program could modify Dr* registers in segv_handler too.

by Vitaliy Margolen

Sunday, December 11, 2005, 9:07:06 AM, Peter Beutner wrote: > Vitaliy Margolen schrieb: >> ChangeLog: >> ntdll: Program could modify Dr* registers in segv_handler too. >> > Doesn't every exception handler could modify these registers? > So probably it would be better to put this check into RtlRaiseException? Nope can't. __regs_RtlRaiseException is common for all the platforms (implemented in dlls/ntdll/exception.c). While Dr* registers are not available on all the platforms. Vitaliy

Dec. 11, 2005

Re: Why Steam fails [VirtualAlloc]

by Ivan Gyurdiev

Mike Hearn wrote: > On Sat, 03 Dec 2005 20:39:01 -0600, Rob Shearman wrote: > >> I would suggest playing around with the prelink tool to put >> dynamic libraries in better positions in memory. >> > > Another thing to try is disabling execshield and VMA randomization: > > echo 0 >/proc/sys/kernel/exec-shield > echo 0 >/proc/sys/kernel/randomize_va_space > > That doesn't help - neither does overcommit as another poster suggested. It turns out that prelink was, in fact, broken, and not working at all. The cause was circular dependencies caused by libsafe (see Fedora Extras) which propagated down to the rest of the system (I have no idea how, but libsafe makes everything link to it somehow). Filed a bug. So, after getting rid of libsafe, prelinking, and rebooting, my memory consumption is down by 200MB or so... down from 40% to 20%. Not bad... And yet... Steam *still* manages to fail with 800 MB memory free somehow... Something's not right about that. Again it fails sometimes, not persistently. More info: 1. I used to kill Steam when it crashed, since it tried to write a 3G log file on disk... however, I hadn't noticed it had stopped doing that with recent upgrades (of steam). Now it quits after a while, and reports Windows Structured Exception: Could not write to virtual address 4 without appropriate access rights. (but the ENOMEM is still there, and I'm pretty sure that's making it fail). 2. I don't know if this is the expected result, but here's prelinking libwine: /usr/sbin/prelink: /usr/local/lib/libwine.so.1: Unknown stabs code 0x2e ...and all its dependencies under lib/wine fail. 3. Fedora default prelink flags are: # Options to pass to prelink # -m Try to conserve virtual memory by allowing overlapping # assigned virtual memory slots for libraries which # never appear together in one binary # -R Randomize virtual memory slot assignments for libraries. # This makes it slightly harder for various buffer overflow # attacks, since library addresses will be different on each # host using -R. PRELINK_OPTS=-mR I haven't changed those... should I?

Dec. 11, 2005

Re: ntdll: Program could modify Dr* registers in segv_handler too.

by Peter Beutner

Vitaliy Margolen schrieb: > ChangeLog: > ntdll: Program could modify Dr* registers in segv_handler too. > Doesn't every exception handler could modify these registers? So probably it would be better to put this check into RtlRaiseException?

Dec. 11, 2005

Re: Problems with winetest ?

by Paul Millar

Hi all, Unfortunately, the compilation broke (as usual, due to missing defs within MinGW) just before I was heading off for a week-long conference. With help from Stefan Leichter, the problem is now fixed. There's a new winetest.exe today and new ones should appear in the normal fashion. Cheers, Paul. On Saturday 10 Dec 2005 16:23, Paul Vriens wrote: > I haven't seen a new release of winetest on > http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/ since the 1st of > december. > > Anyone ? > > Paul.

Dec. 11, 2005