January 2005 - Wine-devel - list.winehq.org

Re: windows/winproc.c: Get rid of HEAP_strdupWtoA calls
by Dmitry Timoshkov 08 Jan '05

08 Jan '05

"Jacek Caban" <jack(a)itma.pwr.wroc.pl> wrote: > @@ -1010,9 +1009,15 @@ static INT WINPROC_MapMsg32WTo32A( HWND > case LB_DIR: > case LB_ADDFILE: > case EM_REPLACESEL: > - if(!*plparam) return 0; > - *plparam = (LPARAM)HEAP_strdupWtoA( GetProcessHeap(), 0, (LPCWSTR)*plparam ); > - return (*plparam ? 1 : -1); > + if(*plparam) { > + LPSTR buf; > + int len = WideCharToMultiByte(CP_ACP, 0, (LPWSTR)*plparam, -1, NULL, 0, 0, 0); > + buf = HeapAlloc(GetProcessHeap(), 0, len*sizeof(CHAR)); > + WideCharToMultiByte(CP_ACP, 0, (LPWSTR)*plparam, -1, buf, len, 0, 0); > + *plparam = (LPARAM)buf; > + return 1; > + } > + return 0; It would be helpful to keep the test in the case of a buffer allocation failure here and everywhere else (and perhaps add the missing tests). -- Dmitry.

1 0

Re: USER32: GetScrollBarInfo
by Alexandre Julliard 08 Jan '05

08 Jan '05

Vitaly Lipatov <lav(a)etersoft.ru> writes: > --- scroll.c 8 Dec 2004 18:06:15 -0000 1.3 > +++ dlls/user/scroll.c 4 Jan 2005 14:27:08 -0000 > @@ -27,7 +27,7 @@ > * the specification mentioned above. > * If you discover missing features, or bugs, please note them below. > * > - * TODO: > + * TODO: needs check follow realized functions: > * - GetScrollBarInfo > * - SBM_GETSCROLLBARINFO > * - SCROLLBARINFO > @@ -1424,10 +1461,12 @@ > case SBM_GETSCROLLINFO: > return SCROLL_GetScrollInfo(hwnd, SB_CTL, (SCROLLINFO *)lParam); > > + case SBM_GETSCROLLBARINFO: > + return GetScrollBarInfo(hwnd, SB_CTL, (SCROLLBARINFO *)lParam); You have to do that the other way around, GetScrollBarInfo should send a SBM_GETSCROLLBARINFO message, similar to what GetScrollInfo does. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: wine/ include/Makefile.in dlls/user/user32.spe ... (CVS compile fix)
by Mike McCormack 08 Jan '05

08 Jan '05

This patch adds GetScrollBarInfo to user32.spec, but adds no implementation... Here's a temporary fix for those wondering why the CVS won't compile until the rest of Vitaly's scrollbar patch is committed. Mike Alexandre Julliard wrote: > ChangeSet ID: 15265 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2005/01/07 11:15:30 > > Modified files: > include : Makefile.in > dlls/user : user32.spec misc.c > Added files: > include : winnls32.h > > Log message: > Diego Pettenò <flameeyes(a)users.berlios.de> > Added stub implementation for WINNLS* functions. > > Patch: http://cvs.winehq.org/patch.py?id=15265 > > Old revision New revision Changes Path > 1.151 1.152 +1 -0 wine/include/Makefile.in > 1.92 1.93 +4 -4 wine/dlls/user/user32.spec > 1.19 1.20 +34 -3 wine/dlls/user/misc.c > Added 1.1 +0 -0 wine/include/winnls32.h ? dlls/user/timer.c ? dlls/user/tests/child.c ? dlls/user/tests/child.ok ? dlls/user/tests/timer.c ? dlls/user/tests/timer.ok Index: dlls/user/painting.c =================================================================== RCS file: /home/wine/wine/dlls/user/painting.c,v retrieving revision 1.16 diff -u -r1.16 painting.c --- dlls/user/painting.c 4 Jan 2005 12:11:09 -0000 1.16 +++ dlls/user/painting.c 8 Jan 2005 02:53:48 -0000 @@ -570,3 +570,10 @@ } return ret; } + +BOOL WINAPI SetLayeredWindowAttributes(HWND hwnd, COLORREF crKey, + BYTE bAlpha, DWORD dwFlags) +{ + FIXME("%p %08lx %02x %08lx\n", hwnd, crKey, bAlpha, dwFlags); + return TRUE; +} Index: dlls/user/user32.spec =================================================================== RCS file: /home/wine/wine/dlls/user/user32.spec,v retrieving revision 1.93 diff -u -r1.93 user32.spec --- dlls/user/user32.spec 7 Jan 2005 17:15:30 -0000 1.93 +++ dlls/user/user32.spec 8 Jan 2005 02:53:49 -0000 @@ -294,7 +294,7 @@ @ stdcall GetPropA(long str) @ stdcall GetPropW(long wstr) @ stdcall GetQueueStatus(long) -@ stdcall GetScrollBarInfo(long long ptr) +#@ stdcall GetScrollBarInfo(long long ptr) @ stdcall GetScrollInfo(long long ptr) @ stdcall GetScrollPos(long long) @ stdcall GetScrollRange(long long ptr ptr) @@ -521,6 +521,7 @@ @ stdcall SetInternalWindowPos(long long ptr ptr) @ stdcall SetKeyboardState(ptr) @ stdcall SetLastErrorEx(long long) +@ stdcall SetLayeredWindowAttributes(long long long long) @ stdcall SetLogonNotifyWindow(long long) @ stdcall SetMenu(long long) @ stdcall SetMenuContextHelpId(long long) Index: dlls/user/tests/win.c =================================================================== RCS file: /home/wine/wine/dlls/user/tests/win.c,v retrieving revision 1.39 diff -u -r1.39 win.c --- dlls/user/tests/win.c 27 Dec 2004 17:26:37 -0000 1.39 +++ dlls/user/tests/win.c 8 Jan 2005 02:53:49 -0000 @@ -2114,6 +2114,82 @@ ok( !ret, "message %04x available\n", msg.message); } +static void test_child_window() +{ + WNDCLASSA cls,child_cls; + char className[] = "parentclass"; /* To make sure className >= 0x10000 */ + char winName[] = "parent window"; + char childclassName[] = "childclass"; /* To make sure className >= 0x10000 */ + char childwinName[] = "child window"; + HWND hWnd, hChild; + HINSTANCE hInstance = GetModuleHandleA( NULL ); + + cls.style = CS_HREDRAW | CS_VREDRAW | CS_GLOBALCLASS; + cls.lpfnWndProc = DefWindowProcA; + cls.cbClsExtra = 0; + cls.cbWndExtra = 0; + cls.hInstance = 0; + cls.hIcon = LoadIconA (0, (LPSTR)IDI_APPLICATION); + cls.hCursor = LoadCursorA (0, (LPSTR)IDC_ARROW); + cls.hbrBackground = GetStockObject (WHITE_BRUSH); + cls.lpszMenuName = 0; + cls.lpszClassName = className; + + ok (RegisterClassA (&cls), "unable to register class") ; + + hWnd = CreateWindowA (className, winName, + WS_OVERLAPPEDWINDOW , + CW_USEDEFAULT, CW_USEDEFAULT, 300, 300, 0, + 0, + hInstance, 0); + + ok(hWnd != 0, "Couldn't create parent window"); + + child_cls.style = CS_HREDRAW | CS_VREDRAW | CS_GLOBALCLASS; + child_cls.lpfnWndProc = DefWindowProcA; + child_cls.cbClsExtra = 0; + child_cls.cbWndExtra = 0; + child_cls.hInstance = 0; + child_cls.hIcon = LoadIconA (0, (LPSTR)IDI_APPLICATION); + child_cls.hCursor = LoadCursorA (0, (LPSTR)IDC_ARROW); + child_cls.hbrBackground = GetStockObject (GRAY_BRUSH); + child_cls.lpszMenuName = 0; + child_cls.lpszClassName = childclassName; + + ok (RegisterClassA (&child_cls) , "unable to register child class"); + + /* NOTE: WS_POPUP should override WS_CHILD */ + + hChild = CreateWindowExA ( + 0, childclassName, childwinName, + WS_POPUP | WS_CHILD | WS_CLIPCHILDREN, + 50, 50, 50, 100, hWnd, + 0, hInstance, 0); + + ok(hChild != 0, "Couldn't create child window"); + + ok(!SetActiveWindow(hChild), + "Can activate without parent window"); + + ok(GetAncestor(hChild, GA_PARENT) == GetDesktopWindow(), + "ancestor is not the desktop window"); + + ShowWindow (hWnd, SW_SHOW); + UpdateWindow (hWnd); + + ok(SetActiveWindow(hChild) != 0, + "Can't activate window with parent active"); + + ShowWindow (hChild, SW_SHOW); + UpdateWindow (hChild); + + ok(SetActiveWindow(hChild) != 0, + "Can't activate window with parent active"); + + DestroyWindow(hChild); + DestroyWindow(hWnd); +} + static void test_mouse_input(HWND hwnd) { RECT rc; @@ -2179,6 +2255,8 @@ START_TEST(win) { + test_child_window(); + pGetAncestor = (void *)GetProcAddress( GetModuleHandleA("user32.dll"), "GetAncestor" ); pGetWindowInfo = (void *)GetProcAddress( GetModuleHandleA("user32.dll"), "GetWindowInfo" );

1 0

Re: wineloader: call wineprefixcreate with explicit WINEPREFIX
by Tobias Burnus 07 Jan '05

07 Jan '05

Hello, Crestez Leonard wrote: > +if [ -z $WINEPREFIX ] > +then While my bash accepts this, Tru64 UNIX's POSIX shell does not. Please use "$WINEPREFIX" instead. Tobias

2 1

Re: MSVCRT: Re-implement *printf
by Juan Lang 07 Jan '05

07 Jan '05

Style point: (*pointer).whatever is written a bit more easily as pointer->whatever. That'd make your new patch a good bit more readable. --Juan __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

4 3

re: Announcing security hardened kernels for testing
by Mike Hearn 07 Jan '05

07 Jan '05

Hi, Thanks for the great info. I'll CC this to wine-devel as I think it's of general interest, I hope you don't mind. For context, PaX is a set of security patches for Linux which lock down the system in a similar manner to exec-shield and SELinux. I say similar manner, because PaX seems to go further than these systems do - in fact from what I've read it seems to be the 'gold standard' in security patches. I'll quote the whole email and reply inline. This thread started on ubuntu-devel after one Ubuntu developer said they were experimenting with PaX, and I asked what the differences were between it and exec- shield (with which the community seems to have more experience) and why it was chosen. So I was pointed towards this thread: http://lists.debian.org/debian-devel/2003/11/msg00206.html in which the PaX author and Ingo Molnar who did exec-shield discuss the differences. On Wed, 2005-01-05 at 13:37 +0100, pageexec(a)freemail.hu wrote: > Hello, > > just ran across this thread on the ubuntu-devel list and have > a few observations: > > 1. PaX cares about backwards compatibility as much as it cares about > security, the best compromise we could make is that one can mark > executables to be exempt from PaX enforcements (and you should > have known about this as we'd talked about PaX+wine last year...). OK. I don't remember this thread I'm afraid but I do recall that you can exempt particular programs from PaX, so if a distribution wanted to integrate that it'd have to mark Wine as exempt by default. Presumably if WineHQ/CodeWeavers were to ship binary packages we'd have to do the same to work on such a distribution. But it's just an ELF flag right? > 2. as of the 20041201 snapshot of wine, it needs to be exempt from > at least ASLR [1], because it still makes some invalid assumptions > about the address space: > > - the highest mapping in the address space may not be the stack, > nor is the highest mapping (be that the stack or something > else) supposed to extend to the end of the userland address > space. the end result of this assumption is that some piece > of code in the preloader enters an infinite loop requesting > (but never getting) anon mappings above TASK_SIZE (0xc0000000 > typically). excerpt from an strace: > > mmap2(0xbffe0000, 262144, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x77ec0000 > munmap(0x77ec0000, 262144) = 0 > mmap2(0xbffe0000, 131072, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0xbffe0000 > mmap2(0xc0000000, 131072, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x77ee0000 > munmap(0x77ee0000, 131072) = 0 > mmap2(0xc0000000, 65536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x77ef0000 > munmap(0x77ef0000, 65536) = 0 > > the last lines then repeat indefinitely as the kernel would > never give out the request address, even with MAP_FIXED. We do this because some Windows programs and DLLs cannot cope with getting pointers >2gig, so we need to ensure that the kernel does not give us mappings above this point. The only way to do this currently is to do an iterative reservation to map as much of this address space as possible which is what you're seeing here. > - the above mentioned infinite loop also highlighted another bad > assumption wine makes: mmap() without MAP_FIXED but with a non-0 > hint is under no obligation to observe the hint and give you a > mapping at that address, under PaX it doesn't do so explicitly. > excerpt from an strace: > > mmap2(0x81000000, 1034813440, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x3a420000 > munmap(0x3a420000, 1034813440) = 0 > mmap2(0x81000000, 517406720, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x81000000 > mmap2(0x9fd70000, 517406720, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x59190000 > munmap(0x59190000, 517406720) = 0 > mmap2(0x9fd70000, 258670592, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x9fd70000 > > as you can see, wine insists on an address until it gets it, > without using MAP_FIXED. We have no choice in the matter, I think we can't use MAP_FIXED as that'd risk blowing away any mappings already made above the 2gig boundary. Actually this code was originally written to support the 4G/4G VM patch that was put into Fedora for a while (it's gone now). > 3. there's at least /usr/lib/wine/ntdll.dll.so which is marked with > an executable PT_GNU_STACK program header, suggesting that it > needs an executable stack (or there's some build problem). Last time I looked documentation on exactly what triggers this flag is scarce or non-existant. I remember asking Ingo if inline assembly still generated it and the answer back then was no, but I have no idea why gcc has decided it's needed now. If you look at ntdll in the sources: http://source.winehq.org/source/dlls/ntdll/ It's fairly harmless, there is some assembly in there but I don't remember seeing any code which assumed an executable stack. > this > alone would make wine fail under a PaX kernel as PT_GNU_STACK is > completely ignored there (because it's the wrong solution for the > wrong problem), nor is it allowed to generate code at runtime > (this applies to apps on which PaX is enforced of course, one can > always disable these on a per-executable basis). I'm afraid Wine cannot operate in an environment that doesn't allow us to map pages as executable and fill them with generated code. This technique is: a) Used by some Windows programs b) Used by the Wine DLL loader c) Required to implement DCOM universal interface proxies So if PaX denies this as a matter of course then it will never work. Having read the thread with Ingo I must say I agree with him that runtime code generation is a legitimate technique and not a bug. > i also have memories from about a year ago that kernel32.so had > some executable code snippets (some thunking code?) in .data or > some other otherwise non-executable area, that of course wouldn't > (and didn't) work under PaX either. back then Alexandre Julliard > suggested that this wasn't easy to rewrite (by also making the > now static code text reloc free) - has this been done since then? I don't think so, but I don't remember this thread either. > i also have strace excerpts that show how wine wanted to create > writable and executable memory, suggesting that it still wants to > generate code at runtime and this is how it fails under PaX (which > prevents runtime code generation by default): > > mmap2(NULL, 1179648, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fee0000 > munmap(0x7fff0000, 65536) = 0 > mprotect(0x7fee0000, 65536, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EACCES (Permission denied) > munmap(0x7fee0000, 1114112) = 0 > write(2, "wine: failed to create the proce"..., 40wine: failed to create the process heap > ) = 40 > > on a sidenote, XP SP2 makes the default heap non-executable as > well, so if the above is the result of wanting to be compatible > with Windows, you may want to rethink it for the future. I'm not sure why it is, but yes I expect it's because some programs rely on it. Service Pack 2 may well make the default process heap NX but it also has a huge infrastructure in place to deal with backwards compatibility concerns, including a large database of badly behaved apps, user-accessible GUIs to disable the protections and I believe it also has code to catch NX faults (on hardware that supports that) and ask the user if they wish to disable the protections for that application. > 4. it would be nice if wine-preloader and wine-pthread had a configurable > base address, the current default makes them impossible to use > under the faster non-executable method of PaX/i386 (which halves > the userland address space, [2]). They have to be fixed otherwise the kernel may place them in the middle of a reserved area which would cause initialisation to fail. This cannot be changed. > so, right now wine can't run with a randomized address space, i have > yet to test if it can get away without generating code at runtime > and/or having writable/executable memory. It can't and I don't see any way to make it able to operate under such conditions in future. Is there a way to brand the binaries as excluded from PaX at build time without a special tool? If not would you be willing to submit a build system patch to detect the branding tool on PaX systems and use it on the relevant binaries automatically? thanks -mike

4 8

Re: winecfg fixes, now with actual patch
by Mike Hearn 07 Jan '05

07 Jan '05

Crestez and I talked about this patch on #winehackers, and there are a few things that need to be changed (let's ignore the formatting changes here): - There was code to avoid a crash when the desktop value read from the registry doesn't have an x in it for some reason (yes this does happen) but this patch deletes it - mode_to_label is for translated, UI strings, not for stuff to be put in the registry. It does say this in a comment but I can appreciate that it looks at first glance like pointlessly duplicated code. We should fix this, especially as right now winecfgs translation support is weak. But for now the replacement of a case statement with a mode_to_label call is incorrect. thanks -mike On Fri, 07 Jan 2005 16:44:11 +0200, Crestez Leonard wrote: > This patch makes a bunch of small winecfg fixes. Since most of them are > just a few lines in length I don't think it's worth splitting them. > > Sorry for forgetting the attachment. > > Changelog: > winecfg: fix add application (memory error) > winecfg: fix apply button lighting up in audio tab > winecfg: fix video tab(crash when checking desktop, apply button not > lighting up > winecfg: fix apply button in libraries tab, fix memory leak in > parse_override, remove horrible abuse of macros in set_dllmode

1 0

Re: [winegcc] Include .so files when calling winebuild
by Dimitrie O. Paun 07 Jan '05

07 Jan '05

On Wed, Jan 05, 2005 at 01:58:45PM +0100, Peter Berg Larsen wrote: > +void strarray_set(strarray* arr, int index, const char* str) > +{ > + if (index >= arr->maximum) > + { > + arr->maximum = index+10; > + arr->base = xrealloc(arr->base, sizeof(*(arr->base)) * arr->maximum); > + memset(&(arr->base[arr->size]),0,sizeof(*(arr->base)) * (arr->maximum - arr->size)); > + } > + arr->base[index] = str; > + if (arr->size <= index) > + arr->size = index+1; > +} Do we really need this strarray_set() function? Even if you do, it should _not_ shorten the array. -- Dimi.

2 3

tools/widl/write_msft.c warnings
by Gerald Pfeifer 07 Jan '05

07 Jan '05

The addition of tools/widl/write_msft.c added the following four warnings, basically doubling the number of warnings we are getting with GCC 3.4. write_msft.c:582: warning: `ctl2_alloc_importinfo' defined but not used write_msft.c:620: warning: `ctl2_alloc_importfile' defined but not used write_msft.c:918: warning: `ctl2_find_nth_reference' defined but not used write_msft.c:1382: warning: `set_help_file_name' defined but not used Would you mind looking into this? Gerald

1 0

Re: [AppDB] remove even more unused functions
by Tony Lambregts 07 Jan '05

07 Jan '05

Jonathan Ernst wrote: > This patch removes unused functions from include/util.php > > Changelog: > - remove unused functions in include/util.php > > Files changed: > - include/util.php I believe you got carried away... two of those functions are used by make_bugzilla_version_list(): openbugzilladb() and closebugzilladb() values() is used in qclass.php which is used in stdquery.php which is used by query_appbyvendor.php, pn_buttons.php, appversion,php and a few others. If those files are not used then we should remove them first.

1 0