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

Assertion fails in riched20; relay debug segfaults
by Adrian Harvey May 9, 2005

May 9, 2005

The wine version of riched20 fails an assertion when starting StreamboxVCR $ wine .wine/drive_c/Program\ Files/StreamboxVcrSuite2/StreamBoxVCR1Beta31/vcr_31turbo.exe fixme:ole:CoRegisterMessageFilter stub fixme:ole:CoCreateInstance no classfactory created for CLSID {4955dd33- b159-11d0-8fcf-00aa006bcc59}, hres is 0x80040154 err:ole:ITypeInfo_fnInvoke did not find member id fffffdfa, flags 4! err:ole:ITypeInfo_fnInvoke did not find member id fffffdfb, flags 4! fixme:richedit:RichEditANSIWndProc WM_SETFONT: stub wine-pthread: run.c:522: ME_CalcRunExtent: Assertion `size.cx' failed. fixme:ole:ITypeInfo_fnRelease destroy child objects Along with a popup dialogue box from the visual C++ runtime library indicating abnormal program termination. The file run.c appears to be part of riched20, and indeed overriding the load order to native only for that DLL allows the program work. All reasonably standard debugging so far, and I went for some more logging to aid tracing the problem (or to log in bugzilla when it all gets too hard for my skill level ;-) ) $ WINEDEBUG="+relay" wine .wine/drive_c/Program\ Files/StreamboxVcrSuite2/StreamBoxVCR1Beta31/vcr_31turbo.exe 0009:Call kernel32.__wine_kernel_init() ret=55727d9e Segmentation fault Shortest relay trace I've ever had! But I'm not really sure where to go from here... Running GDB on it gives me no useful results. I have an AMD64 box running Fedora Core 3 and wine is the latest from CVS. I'm going to try some other tracing to look at the riched problem, but +relay crashing seems serious to me. Adrian

4 8

Quicken/CreateCompatibleBitmap issue revisited
by Carl Sopchak May 9, 2005

May 9, 2005

In the bug found at http://bugs.winehq.org/show_bug.cgi?id=2096 , I have described an issue that I am having with Quicken Deluxe 2000 when running under Wine. The symptom is that Quicken was crashing HARD when trying to print a partial page of checks on a laser printer. Now, I just get fixme's stating that CreateCompatibleBitmap is getting bad parameters. (In lieu of reading the following, you could probably just read the last few posts in bugzilla for this bug...) Long story short, with the help of some others (thanks guys!), it seems that CreateCompatibleBitmap is being called directly from Quicken, and that Quicken seems to be passing an address instead of a value for the height parameter. Now, I would normally just mark the bug as INVALID, and let it go. But, while looking into things, I read the MSDN page describing the function of CreateCompatibleBitmap, and it appears to me that there may be "issues" with Wine's implementation of CreateCompatibleBitmap. To quote my post attached to the bug: "I would have changed this bug entry's resolution to INVALID, except that (a) I wouldn't mind a more knowledgeable (of Wine, Win API, and C) person to verify my findings, and, more importantly, (b) it seems to me that Windows would be handling this scenario differently than Wine (or Intuit/Quicken would have some customer relations problems due to frequent crashes) - should Wine do something different when the parameters are out of whack? The only thing I can see on MSDN under CreateCompatibleBitmap is "Windows 95/98/Me: The created bitmap cannot exceed 16MB in size." "Which I guess brings up another point... dlls/gdi/bitmap.c's CreateCompatibleBitmap shows the aforementioned fixme message if the width or height exceeds 0x10000, and no bitmap is returned. This seems wrong to me on three counts: (1) MSDN states that if either width or height is zero, a 1x1 monochrome bitmap is returned (in my case the height was 0, but the width was "huge", so a 1x1 bitmap should be returned); (2) a 0x11000 by 0x2 bitmap is within the (more restrictive Win95) 16 MB limit and should be valid; and (3) Win NT/2000/XP do not seem to have any restriction on a bitmap's size (except physical and paged memory constraints), so at least in theory, any values for width and height are "valid". So, this begs the question, should Wine's CreateCompatibleBitmap be modified for any (or all?) of the reasons above? Thoughts? Comments? Carl

3 3

Bugs out of my league
by Dustin Navea May 8, 2005

May 8, 2005

Bug 2938: Seemed at first like this was due to the recent patch to get Mozilla/FF installers working, but after he reverted to the Feb release and the problem still existed, it must be something else.. Bug 2919: If I am reading the backtrace right, it looks like the installer is crashing in kernel32, but then again it does the same for the quicktime installer on the same cd, so could it be configuration related? Just need someone to take a look and comment here, and I'll take care of em, until I need a patch anyways lol. Dustin

1 0

Now hiring
by Dustin Navea May 8, 2005

May 8, 2005

Jeremy, guys, it seems we have run low on "official" janitors, I have talked with someone that seems to know what they are doing as far as the right way to bug report (he contribs to MPlayer), and he said he would be willing to help maintain bugzilla, but that he doesn't have a whole lot of time, the extra hand will be helpful. Could you add 'canconfirm' and 'editbugs' to inverseparadox(a)comcast.net? Does anyone have any objection to me posting a note on wine-users that we are accepting applications for dedicated bug maintainers (read: janitors lol)? I will handle "interviewing and hiring", and just send an email to Jeremy when we get people that know what they are doing and can really be of use.. I think 5 should be good for now.. Dustin

2 2

LockDIBSection problem
by Rein Klazes May 8, 2005

May 8, 2005

Hi, Here is another problem in BigJig a jigsaw puzzle game (free download at www.lenagames.com) The program calls BitBlt with destination an in memory DIB. Inside BitBlt, the destination bits are set to PAGE_NOACCESS: | 0009:Call kernel32.VirtualProtect(727f0000,00123324,00000001,77a5f7bc) ret=770032ba | 0009:Call ntdll.NtProtectVirtualMemory(ffffffff,77a5f69c,77a5f6a0,00000001,77a5f7bc) ret=77b6929e | trace:virtual:NtProtectVirtualMemory 0xffffffff 0x727f0000 00123324 00000001 | trace:virtual:VIRTUAL_SetProt 0x727f0000-0x72913fff c---- | View: 0x727f0000 - 0x72913fff (valloc) | 0x727f0000 - 0x72913fff c---- | 0009:Ret ntdll.NtProtectVirtualMemory() retval=00000000 ret=77b6929e This memory segment (727f0000,00123324) does not appear in the log anymore until it is written to disk: | 0009:Call kernel32.WriteFile(00000084,727f0000,00123324,77a5f360,00000000) ret=00408ac1 .. The call fails ( not in the log because I fixed it) with error STATUS_INVALID_USER_BUFFER and the program hangs. I managed to fixed it in two ways: 1. put a X11DRV_CoerceDIBSection( physDevDst, DIB_Status_InSync, FALSE ); at the end of X11DRV_BitBlt. This probably defeats the whole purpose of these protections so: 2. Add a "IsBadReadPtr( buffer, bytesToWrite)" in the top of WriteFile to force an exception and everything works. Would that be an acceptable fix? Rein.

2 2

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

May 8, 2005

On Sun, 8 May 2005 13:30:30 +0200, you wrote: > On 05/08/2005 12:25:18 PM, Rein Klazes wrote: > > That does not seem correct on the Win2k system that I am using for > > testing. > > Right. Windows sets itemHeight before and not after WM_MEASUREITEM. > Sorry for that. > > And it also seems not to be GetSystemMetrics(SM_CYMENU)-1 but a rather > strange magic value of 16. (with my test it looked 100% the same ... > sigh. I'll go to bed soon. ;) > > How about this patch? Much better. About the magic number: I looked at the value on Win2k and WinME with different resolutions ( desktop->properties->settings, click on advanced tab and change what windows calls "font size" but is really changing the DPI, dots-per-inch, which is also reported). DPI Win2k WinME ================== 96 16 13 120 20 16 I assume that you are using a DPI of 96, and XP and 2k behave the same way. The DPI you can retrieve with GetDeviceCaps( hdc, LOGPIXELSY). I would recommend using the Win2k values computed by: DPI/6. Rein.

2 2

wineconsole exits immediately (Wine 20050310 debian sarge/testing)
by J. Grant May 8, 2005

May 8, 2005

Hello, I was trying to run wcmd, it seems to have been renamed wineconsole. However, unfortunately it exits immediately before producing a DOS command prompt in my terminal like wcmd used to. I think this is a bug, (unless I missed something). $ wineconsole Invoking /usr/lib/wine/wine.bin wineconsole.exe ... Wine exited with a successful status $ I thought that maybe there was an argument I needed to pass, but there isn't a man page, or command line --help /? help unfortunately at present. $ wineconsole --help Invoking /usr/lib/wine/wine.bin wineconsole.exe --help ... err:wineconsole:WinMain Wrong command line options Wine exited with a successful status $ wineconsole /? Invoking /usr/lib/wine/wine.bin wineconsole.exe /? ... Wine exited with a successful status $ 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 7

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

Re: portability improvements for wineshelllink script
by Francois Gouget May 7, 2005

May 7, 2005

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

May 7, 2005

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

May 7, 2005

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

Re: winecfg: Match the new way to use unixfs
by Mike Hearn May 7, 2005

May 7, 2005

On Sat, 2005-05-07 at 09:46 +0200, Michael Jung wrote: > P.S.: What's the reason for disabling the i18n resources in > winecfg.rc? They're out of date and don't reflect the current English GUI. thanks -mike

1 0

Support for multiple threading models
by Robert Lunnon May 7, 2005

May 7, 2005

Some time ago, I wrote code to support native threads instead of lwp for SYSV operating systems, the way I wrote the code all available threading models were compiled into wine and the actual one to be used was selected by setting an environment variable. (Currently WINE_THREADMODE). On OSes that support multiple threading methods, IE Solaris and probably the BSDs this allows for easy development and testing of thread support. It also allows the simulation of no thread support (Not that that seems to be very useful). Originally when I wrote this Solaris 9 was having some problems with crashing in mutexes if native threads were used, but LWPs weren't perfect either, in particular lwps aren't necessarily safe to use with some libraries (There is a warning about this in the Man pages for the _lwp calls, For example. this caused problems with alarm/usleep calls used at the time in winmm). These days however in Solaris 10 the native thread code works quite well. Anyway the fallout was that non winmm code worked best using native threads on certain Solaris MUs and winmm dependent programs worked best using LWPs and having the Threading model selectable made sense. This is still the case for Solaris 8/9 users. I can still see situations where it would be advantageous to be able to select the threading model at runtime and I'd like to leave this support in (Solaris 9 for example). This possibility has received a luke warm reception before but I thought I'd re-raise the possibility now while I'm doing the putback from my latest patch kit. Just as a final point Solaris no longer supports _lwp_create calls, without this patch wine is unable to run on Solaris versions > Solaris 9 Bob Threading patch attached

1 0

Re: [resend] [patch] fix delete key on certain european keyboards
by Dmitry Timoshkov May 7, 2005

May 7, 2005

"zhilla" <zhilla(a)spymac.com> wrote: > ok, this is 3rd time, damn :) this time against wine cvs root, and with, > i hope, fixed comments. > - 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); If you could also use symbolic key(sym) names instead of hardcoded numbers the patch would have better chances to be accepted. -- Dmitry.

1 0

re: Winelib's role in converting Windows applications
by Daniel Kegel May 7, 2005

May 7, 2005

Ira Krakow (ikrakow_1999(a)yahoo.com) wrote: > At Wineconf, I had a number of conversations about > Winelib's role in converting Windows apps. The > consensus seems to be that the most efficient > conversion path is for much of the Windows app to stay > in Visual C++ (or whatever) and that only the modules > that specifically require native Linux calls should be > recompiled, via MinGW/Dev-C++ on the Windows side, and > Winemaker on the Linux side, into Winelib objects. > > For example, if the application requires PAM > authentication, or a Linux-based help system, these > modules would be separated out and encapsulated as > Winelib objects. I was thinking of using PAM > authentication as a good example, since it works for > any authentication scheme that the application > requires. There are two other reasons to use winelib: 1) if your code uses SEH (structured exception handling), you have a problem. This technique is patented by Borland, see http://www.google.com/search?q=patent+5628016 or maybe by Sun, see http://www.google.com/search?q=patent+6247169 so the official gnu gcc can't support it. You can apply an unoffical patch (see http://reactos.csh-consult.dk/index.php?page=gccseh, or you may be able to use winelib plus some clever macros (see http://www.winehq.org/hypermail/wine-devel/2005/05/0186.html) 2) if you want to reach non-x86 platforms (e.g. MacOSX/PPC, Solaris/Sparc) winelib is the only way to go until projects like Darwine integrate a CPU emulator. - Dan

1 0

Wine Wiki Status
by Dimitrie O. Paun May 6, 2005

May 6, 2005

A few things: 1. We've been attacked Wed by one or two idiots from Slashdot. They kept replacing the content of the front page with some silly Balmer images :) Not a big deal, since MoinMoin makes it a snap to revert to an older version. However, this episode forced me to at least require that you sign up before you can edit a page. This is probably a good idea anyway, I hope people agree. 2. I've placed the modifications to the code on the Wine CVS repository at SourceForge in the 'wiki' module. Please feel free to check it out and send in patches (sending them to wine-patches(a)winehq.org with a subject prefix of 'Wiki:' is fine, or directly to me if you prefer). 3. Mike is right, the namespacing stuff if not a good idea. I'll try to get rid of it, I'm going to try to rename the page, but first I have to enable the feature. If not, I'll just simply recreate them. As always, you comments, suggestions and complaints are most welcome. -- Dimi.

6 6