- Wine-Devel - list.winehq.org

Wine -> WineHQ -> codeweavers
by Derzu May 8, 2005

May 8, 2005

Hi all, I saw at the www.winehq.org/ the banner (http://www.winehq.org/images/bannerads/cw-ad02.gif) that ponts to the www.codeweavers.com/ page. That banner has a little penguin opening a bottle of wine and after, the penguin appears very drunk, does any one knows who did that banner? I wanna the picture of the drunk penguin to set as mine wallpaper, but I wanna a big one. Any one can help me? Sorry if that mesage is not exatly a devel question. Thanks, Derzu ____________________________________________________Yahoo! Mail, cada vez melhor: agora com 1GB de espaço grátis! http://mail.yahoo.com.br

2 1

Re: [DInput] Fix 'peek' code for mouse (S3 problem)
by Stefan Dösinger May 8, 2005

May 8, 2005

Am Mittwoch, 4. Mai 2005 20:44 schrieb Lionel Ulmer: > This should fix the mouse issue in S3. > > Lionel > > Changelog: > - do not flush the buffer when the application only wants to peek the > number of elements in the queue > - trace the GetDeviceState values before they are reset No, saidly, it doesn't. I have attached a +dinput log again. Stefan

2 10

Re: ignore requested height for non-menubar ownerdraw popups
by Rein Klazes May 8, 2005

May 8, 2005

On Sun, 8 May 2005 11:14:52 +0200, you wrote: > This fixes bug 2764 (the scrolling issue seems to be resolved > already?). Verified this behaviour on WinXP and changed the comment to > reflect that. > > ChangeLog: > Ignore requested height for non-menubar ownerdraw popups too. > > Index: menu.c > =================================================================== > RCS file: /home/wine/wine/dlls/user/menu.c,v > retrieving revision 1.26 > diff -u -r1.26 menu.c > --- menu.c 19 Apr 2005 09:47:02 -0000 1.26 > +++ menu.c 8 May 2005 09:09:06 -0000 > @@ -887,17 +887,14 @@ > SendMessageW( hwndOwner, WM_MEASUREITEM, 0, (LPARAM)&mis ); > lpitem->rect.right += mis.itemWidth; > > - if (menuBar) > - { > - lpitem->rect.right += MENU_BAR_ITEMS_SPACE; > + /* under windows you are given a standard height for the > + menu and the height value is ignored. delphi 7 depends > + on this behaviour. */ > > + lpitem->rect.bottom += GetSystemMetrics(SM_CYMENU)-1; > That does not seem correct on the Win2k system that I am using for testing. Attached is the test that I am working on. It creates a non-menubar popup menu, fills it with a couple of items and traces the resulting item rectangles. It is all work in progress of course, not meant for submitting yet. Without your patch the rectangles get the height that is returned by the WM_MEASUREITEM handler both Win2k and Wine. With your patch the Wine behavior is broken. I have a real world application too, that is affected by this brokenness. Can you see if that is different on WinXP. If it is not, can you look what is different with your test and mine? Rein.

1 0

Stable release builds with fixme output (Wine 20050310 debian sarge/testing)
by J. Grant May 8, 2005

May 8, 2005

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 May 8, 2005

May 8, 2005

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 May 8, 2005

May 8, 2005

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 May 7, 2005

May 7, 2005

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 May 7, 2005

May 7, 2005

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 May 7, 2005

May 7, 2005

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 May 7, 2005

May 7, 2005

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