- Wine-Devel - list.winehq.org

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

Readers' choices: 2004 Desktop Linux survey results in!
by Tom Wickline May 6, 2005

May 6, 2005

Hello All, Here is the results: http://www.desktoplinux.com/articles/AT2127420238.html Wine 34 % Crossover 16.3 % VMWare 13.7 % Win4Lin 6.9 % Other (please email us) 1 % None -- I don't run Windows apps under Linux 27.9 % http://www.desktoplinux.com/cgi-bin/survey/survey.cgi?view=archive&id=02152… What I find interesting is this part. Last year's poll results revealed that about 60 percent of the 3,946 readers polled had both currently used Windows applications under Linux and expected to do so in the future. Tom

2 1

test.winehq.org broken
by Stefan Leichter May 6, 2005

May 6, 2005

Hello, looks like adding the dll name to the output of the tests broke the script that creates the pages on test.winehq.org. Now all test are listed as failed output from winetest-200504301000-paul-mingw.exe crypt: 37 tests executed, 0 marked as todo, 0 failures. output from winetest-200505051000-paul-mingw.exe advapi32/crypt: 37 tests executed, 0 marked as todo, 0 failures. Can someone please fix the script building the summary page. Thanks Stefan

3 3