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

Stable release builds with fixme output (Wine 20050310 debian sarge/testing)
by J. Grant 08 May '05

08 May '05

Hello, I typically launch applications using wine from the terminal, I get pages of these fixme debug messages. I wonder if there is a reason these fixme "harmless" messages are being displayed? IMHO stable releases should only output err messages, thus not displaying fixme or warnings. I wonder if this has been considered already? fixme:powermgnt:SetThreadExecutionState (0x2): stub, harmless. fixme:powermgnt:SetThreadExecutionState (0x2): stub, harmless. fixme:powermgnt:SetThreadExecutionState (0x2): stub, harmless. fixme:powermgnt:SetThreadExecutionState (0x2): stub, harmless. fixme:powermgnt:SetThreadExecutionState (0x2): stub, harmless. I am not on this list, please include my email address in any replies. Kind regards JG -- Homepage: http://jguk.org/ Blog: http://jguk.org/blog.rss Radio: http://jguk.org/#radio

3 3

Re: portability improvements for wineshelllink script
by Dan Kegel 08 May '05

08 May '05

Somebody wrote: > [Let's use bash features in wine shell scripts] Bad idea. Unless you have a *very* good reason, you should stick to Posix interfaces, which here means "get it to run under Bourne shell". Portability -- it's a good thing. By the way, if anyone out there is looking for a concise, illuminating guide to portable shell scripting, I highly recomment "Portable Shell Programming" by Bruce Blinn. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

1 0

[patch] fix delete key on certain european keyboards
by zhilla 07 May '05

07 May '05

reposting this here, looking for someone to fix a long standing wine bug. text [edited] again: well, this is just this: http://bugs.winehq.org/show_bug.cgi?id=2400 and should apply to today's cvs. i AM NOT the author! it IS kinda urgent, since a lot of european keyboards are affected... like hungarian, croatian, slovenian... all have "delete" key producing "<delete>," instead of "<delete>". this patch is just a "works here" workaround, see url for more details. i got response from some people, so i fixed comments, but what needs to be tuned, according to mr. Dmitry Timoshkov, is that it should use symbolic key(sym) names instead of hardcoded numbers. seems like a trivial task for a programmer (which i am not) so, anybody up to it? Changelog: * dlls/x11drv/keyboard.c Arpad Biro <biro_arpad(a)yahoo.com> (modified to current cvs by Marin Glibic <zhilla(a)spymac.com>) This fixes the problem is that when NumLock is active, both Del keys perform a "delete" action _and_ insert a comma (the decimal character). --- dlls/x11drv/keyboard.c.orig 2005-05-05 23:33:23.000000000 +0200 +++ dlls/x11drv/keyboard.c 2005-05-05 23:38:44.000000000 +0200 @@ -1067,11 +1067,14 @@ else XLookupString(e, NULL, 0, &keysym, NULL); - if ((keysym >= 0xFFAE) && (keysym <= 0xFFB9) && (keysym != 0xFFAF) - && (e->state & NumLockMask)) - /* Only the Keypad keys 0-9 and . send different keysyms - * depending on the NumLock state */ - return nonchar_key_vkey[keysym & 0xFF]; + if (e->state & NumLockMask) /* NumLock is active */ + { if (keysym == 0xFFAC) /* Numeric Del pressed */ + return keyc2vkey[0x3B]; /* comma */ + if ((keysym >= 0xFFAE) && (keysym <= 0xFFB9) && (keysym != 0xFFAF)) + /* Only the Keypad keys 0-9 and . send different keysyms + * depending on the NumLock state */ + return nonchar_key_vkey[keysym & 0xFF]; + } TRACE_(key)("e->keycode = %x\n", e->keycode);

1 0

Stack size allocations
by Robert Lunnon 07 May '05

07 May '05

I wish to propose two changes that I currently have in my Solaris patchkit. I'll use two separate e-mails here to avoid confusion. Both changes add environment variables controlling the way wine does things. The first patch addresses a problem I have found where Windows applications under wine exceed the allocated stack. By default wine allocates the same 1MB stack that windows does but wine has a different stack consumption that does windows, adding the wine translation layers, possibly OGL then X calls on top of this. The following patch allows an environment variable WINE_STACK to redefine the minimum stack to give applications and to add extra stack to that declared in the executables header to allow for additional stack consumption. Currently it works like this if WINE_STACK is not set the default semantics are used just like wine does today if WINE_STACK is set then wine allocates the maximum of the value given in the WINE_STACK env var or 1MB. 25% of the value specified in WINE_STACK is added to the value declared in the applications executable header to provide more headroom for wine/X calls. Please excuse the primitive debugging included for now, it'll have to be removed for primetime. Comments anyone ? Index: dlls/ntdll/thread.c =================================================================== RCS file: /home/wine/wine/dlls/ntdll/thread.c,v retrieving revision 1.26 diff -u -3 -p -r1.26 thread.c --- dlls/ntdll/thread.c 27 Apr 2005 08:18:20 -0000 1.26 +++ dlls/ntdll/thread.c 6 May 2005 21:21:30 -0000 @@ -25,7 +25,7 @@ #ifdef HAVE_SYS_MMAN_H #include <sys/mman.h> #endif - +#include <stdio.h> #include "ntstatus.h" #include "thread.h" #include "winternl.h" @@ -221,6 +221,9 @@ NTSTATUS WINAPI RtlCreateUserThread( HAN ULONG size; int request_pipe[2]; NTSTATUS status; + unsigned long stack_min=1024*1024; + unsigned long stack_overhead=0; + char stack_mul=0; if( ! is_current_process( process ) ) { @@ -273,23 +276,67 @@ NTSTATUS WINAPI RtlCreateUserThread( HAN MEM_SYSTEM, PAGE_EXECUTE_READWRITE ); info->pthread_info.teb_size = size; info->pthread_info.teb_sel = teb->teb_sel; - + + + /* Allocate the stack: + Allow the user to set an environment variable to specify the stack size + WINE_STACK, allow the user to use multiplier notation + eg K for kilobyts or M for Megabytes or M + example WINE_STCK=2048K or WINE_STACK=2M bithe specify 2 Megabytes + */ + + if(getenv("WINE_STACK")) { + sscanf(getenv("WINE_STACK")," %lu%c ",&stack_min,&stack_mul); + fprintf(stderr,"Got stack spec of %lu %c bytes from environment",stack_min,stack_mul); + } + + switch (stack_mul) { + case 'm': + case 'M': + stack_min=stack_min*1024*1024; + stack_overhead=stack_min/4; + break; + case 'b': + case 'B': + stack_overhead=stack_min/4; + break; + case 'k': + case 'K': + stack_min=stack_min*1024; + stack_overhead=stack_min/4; + break; + + default: + stack_min=1024*1024; + stack_overhead=0; + break; + } + + stack_min=max(stack_min,1024*1024); + fprintf(stderr,"Minimum Stack Set to %lu overhead allowance = %d\n",stack_min,stack_overhead); + /* Get the stack size recommendation from the program prefix (Executible header) + Because this is not "real windows" we have additional stack overheads particularly in xlib + where the user has specified a stack requirement (IE VIA WINE_STACK) add 25% of the minimum + stack over and above the value in the header to allow for this + */ if (!stack_reserve || !stack_commit) { IMAGE_NT_HEADERS *nt = RtlImageNtHeader( NtCurrentTeb()->Peb->ImageBaseAddress ); - if (!stack_reserve) stack_reserve = nt->OptionalHeader.SizeOfStackReserve; + if (!stack_reserve) stack_reserve = nt->OptionalHeader.SizeOfStackReserve+stack_overhead; if (!stack_commit) stack_commit = nt->OptionalHeader.SizeOfStackCommit; } if (stack_reserve < stack_commit) stack_reserve = stack_commit; stack_reserve = (stack_reserve + 0xffff) & ~0xffff; /* round to 64K boundary */ - if (stack_reserve < 1024 * 1024) stack_reserve = 1024 * 1024; /* Xlib needs a large stack */ + if (stack_reserve < stack_min) stack_reserve = stack_min; /* Xlib needs a large stack */ info->pthread_info.stack_base = NULL; info->pthread_info.stack_size = stack_reserve; info->pthread_info.entry = start_thread; info->entry_point = start; info->entry_arg = param; - + + fprintf(stderr,"Allocated thread at %lx Allocated stack of %lu Bytes\n",stack_commit,stack_reserve); + if (wine_pthread_create_thread( &info->pthread_info ) == -1) { status = STATUS_NO_MEMORY;

4 6

Re: Solaris Compatibility -dlls/wineps/driver.c
by Alexandre Julliard 07 May '05

07 May '05

Robert Lunnon <bobl(a)optushome.com.au> writes: > Notes about patch: > PAGESIZE is a risky name for a symbol since it an obvious candidate for use to > define the page size of the OSes VM pages and in fact does Collide under > Solaris We already have a #undef PAGESIZE to work around that problem. If it doesn't work you probably need to tweak the include files order. -- Alexandre Julliard julliard(a)winehq.org

2 1

Bug 2905
by Dustin Navea 07 May '05

07 May '05

Can someone take a look at the attached debug output and let me know what might be the problem? The game crashes under wine, regardless of the winver (could be an old wine version), and also under real Win2k, but not under real Win98.. I doubt there is much hope for getting this working, since it even crashes in Win2k, but since it's reported, I should go ahead and report it to you all anyways.

1 0

Re: Solaris compatibility - libs/wine/loader.c
by Alexandre Julliard 07 May '05

07 May '05

Robert Lunnon <bobl(a)optushome.com.au> writes: > Notes about patch: > Solaris requires RTLD_FIRST flag to dlopen calls to resolve multiple path > expansions properly This doesn't seem to be what RTLD_FIRST does. Could you explain a bit more exactly what the problem is? -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: portability improvements for wineshelllink script
by Francois Gouget 07 May '05

07 May '05

On Sat, 7 May 2005, Robert Lunnon wrote: [...] > # diff -u wineshelllink.old wineshelllink > --- wineshelllink.old mer mai 4 11:47:30 2005 > +++ wineshelllink mer mai 4 11:50:03 2005 > @@ -1,4 +1,4 @@ > -#!/bin/sh > +#!/bin/bash This is wrong. Some users may not have bash installed and the script should still work on their systems. So the fix is not to make the script fail to run on any system which does not have bash but to modify it so it works with any standard Bourne shell, including the Solaris one. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: the choice of a GNU generation

3 4

16 bit hwnd in SendmessageA/W
by Rein Klazes 07 May '05

07 May '05

Hi, Another case where I don't think I know enough of the finer details for a correct solution. MS Visual C++ 1.5 IDE - 16 bit win application - communicates its window handle to WINTEE32.EXE - win32 app - to handle the build process: >> E:\\MSVC\\BIN\\WINTEE32.EXE -h2a -vn 5e is the 16 bit window handle. Here it sends data to the IDE: >> 0035:Call user32.SendMessageA(ffff002a,0000004a,0008004a,77a3fe28) ret=77a51649 That does not work, SendMessageA does only expect full 32 bit win handles. Things work with this patch: ========================================================================== --- wine/dlls/user/message.c 2005-05-05 10:26:28.000000000 +0200 +++ mywine/dlls/user/message.c 2005-05-05 20:07:46.000000000 +0200 @@ -2388,6 +2388,13 @@ LRESULT WINAPI SendMessageTimeoutA( HWND return 1; } + /* if it is not a 32bit window handle */ + if( !IsWindow( hwnd)) { + /* try if it is a 16 bit handle */ + hwnd = WIN_Handle32( (HWND16) hwnd ); + info.hwnd = hwnd; + } + if (!(dest_tid = GetWindowThreadProcessId( hwnd, &dest_pid ))) return 0; if (USER_IsExitingThread( dest_tid )) return 0; ========================================================================== Is anything else needed, I wonder? Rein.

3 4

Re: Enummedia memleak fix
by Alexandre Julliard 07 May '05

07 May '05

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > Fixed 2 small memory leaks in enummedia (my fault, not used to while > loops..) > > Note that there are 2 ways to fix it: > while (--i) .. -> while (i--) .. > while (--i) .. -> while (--i >= 0) .. > > I chose the second, but I don't think it matters ;) In that case it matters a lot, since i is unsigned... -- Alexandre Julliard julliard(a)winehq.org

1 0