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

[PATCH] winemaker fixes
by Martin Wilck 09 Sep '02

09 Sep '02

Hi, the patch below fixes a few things in winemaker. It seems to work with my app, but needs more testing, especially for MFC apps. Modified files: tools: winemaker documentation: winemaker.man Changelog: - adapt winemaker to the new way winebuild handles imports. - fix crashes due to winemaker-generated wrapper app closing libraries (is this one correct??) - Fix some minor bugs in the wrapper.c template. - change semantics of --nomfc option such that it overrides automatic setting of --mfc if stdafx.h or stdafx.cpp are found. (this may cause problems to some people. For me the old behaviour was a pain in the neck, because VC++ generates stdafx.h always, even for pure C projects). Feedback, please ! - Add --nodlls option to suppress auto-generated import list for simple apps. - Adapt man page. -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy Index: tools/winemaker =================================================================== RCS file: /home/wine/wine/tools/winemaker,v retrieving revision 1.39 diff -u -r1.39 winemaker --- tools/winemaker 14 Apr 2002 19:31:23 -0000 1.39 +++ tools/winemaker 22 May 2002 16:49:18 -0000 @@ -233,6 +233,14 @@ my $TF_MFC=4; ## +# User has specified --nomfc option for this target or globally +my $TF_NOMFC=8; + +## +# --nodlls option: Do not use standard DLL set +my $TF_NODLLS=16; + +## # Initialize a target: # - set the target type to TT_SETTINGS, i.e. no real target will # be generated. @@ -435,23 +443,37 @@ push @{@$target[$T_LIBRARY_PATH]},$option; } elsif ($option =~ /^-l/) { push @{@$target[$T_LIBRARIES]},"$'"; - } elsif (@$target[$T_TYPE] != $TT_DLL and $option =~ /^--wrap/) { - @$target[$T_FLAGS]|=$TF_WRAP; - } elsif (@$target[$T_TYPE] != $TT_DLL and $option =~ /^--nowrap/) { - @$target[$T_FLAGS]&=~$TF_WRAP; - } elsif ($option =~ /^--mfc/) { - @$target[$T_FLAGS]|=$TF_MFC; + } elsif ($option =~ /^--wrap/) { if (@$target[$T_TYPE] != $TT_DLL) { @$target[$T_FLAGS]|=$TF_WRAP; + } else { + print STDERR "warning: option --wrap is illegal for DLLs - ignoring"; + }; + } elsif ($option =~ /^--nowrap/) { + if (@$target[$T_TYPE] != $TT_DLL) { + @$target[$T_FLAGS]&=~$TF_WRAP; + } else { + print STDERR "warning: option --nowrap is illegal for DLLs - ignoring"; } + } elsif ($option =~ /^--mfc/) { + @$target[$T_FLAGS]|=$TF_MFC; + @$target[$T_FLAGS]&=~$TF_NOMFC; } elsif ($option =~ /^--nomfc/) { @$target[$T_FLAGS]&=~$TF_MFC; - @$target[$T_FLAGS]&=~($TF_MFC|$TF_WRAP); + @$target[$T_FLAGS]|=$TF_NOMFC; + } elsif ($option =~ /^--nodlls/) { + @$target[$T_FLAGS]|=$TF_NODLLS; } else { print STDERR "error: unknown option \"$option\"\n"; return 0; } } + if (@$target[$T_TYPE] != $TT_DLL && + @$target[$T_FLAGS] & $TF_MFC && + !(@$target[$T_FLAGS] & $TF_WRAP)) { + print STDERR "info: option --mfc requires --wrap"; + @$target[$T_FLAGS]|=$TF_WRAP; + } return 1; } @@ -541,7 +563,7 @@ } elsif ($dentry =~ /\.c$/i and $dentry !~ /\.spec\.c$/) { push @sources_c,"$dentry"; } elsif ($dentry =~ /\.(cpp|cxx)$/i) { - if ($dentry =~ /^stdafx.cpp$/i) { + if ($dentry =~ /^stdafx.cpp$/i && !(@$project_settings[$T_FLAGS] & $TF_NOMFC)) { push @sources_misc,"$dentry"; @$project_settings[$T_FLAGS]|=$TF_MFC; } else { @@ -551,7 +573,7 @@ push @sources_rc,"$dentry"; } elsif ($dentry =~ /\.(h|hxx|hpp|inl|rc2|dlg)$/i) { push @sources_misc,"$dentry"; - if ($dentry =~ /^stdafx.h$/i) { + if ($dentry =~ /^stdafx.h$/i && !(@$project_settings[$T_FLAGS] & $TF_NOMFC)) { @$project_settings[$T_FLAGS]|=$TF_MFC; } } elsif ($dentry =~ /\.dsp$/i) { @@ -774,10 +796,13 @@ push @exe_list,$target; } # This is the default link list of Visual Studio, except odbccp32 - # which we don't have in Wine. Also I add ntdll which seems - # necessary for Winelib. - my @std_dlls=qw(advapi32.dll comdlg32.dll gdi32.dll kernel32.dll ntdll.dll odbc32.dll ole32.dll oleaut32.dll shell32.dll user32.dll winspool.drv); - @$target[$T_DLLS]=\@std_dlls; + # which we don't have in Wine. + my @std_dlls=qw(advapi32.dll comdlg32.dll gdi32.dll kernel32.dll odbc32.dll ole32.dll oleaut32.dll shell32.dll user32.dll winspool.drv); + if (@$target[$T_FLAGS] & $TF_NODLLS == 0) { + @$target[$T_DLLS]=\@std_dlls; + } else { + $target[$T_DLLS]=[]; + } push @{@$project[$P_TARGETS]},$target; # Ask for target-specific options @@ -982,7 +1007,8 @@ @$wrapper[$T_TYPE]=@$target[$T_TYPE]; @$wrapper[$T_INIT]=get_default_init(@$target[$T_TYPE]); @$wrapper[$T_FLAGS]=$TF_WRAPPER | (@$target[$T_FLAGS] & $TF_MFC); - @$wrapper[$T_DLLS]=[ "kernel32.dll", "ntdll.dll", "user32.dll" ]; + @$wrapper[$T_DLLS]=[ "kernel32.dll", "user32.dll" ]; + push @{@$wrapper[$T_LIBRARIES]}, "dl"; push @{@$wrapper[$T_SOURCES_C]},"@$wrapper[$T_NAME]_wrapper.c"; my $index=bsearch(@$target[$T_SOURCES_C],"@$wrapper[$T_NAME]_wrapper.c"); @@ -1634,32 +1660,10 @@ $rcname =~ s+([^/\w])+\\$1+g; print FILEO "rsrc $rcname.res\n"; } - print FILEO "\n"; - my %dlls; - foreach $dll (@{$global_settings[$T_DLLS]}) { - if (!defined $dlls{$dll}) { - print FILEO "import $dll\n"; - $dlls{$dll}=1; - } - } - if (defined $project_settings) { - foreach $dll (@{@$project_settings[$T_DLLS]}) { - if (!defined $dlls{$dll}) { - print FILEO "import $dll\n"; - $dlls{$dll}=1; - } - } - } - foreach $dll (@{@$target[$T_DLLS]}) { - if (!defined $dlls{$dll}) { - print FILEO "import $dll\n"; - $dlls{$dll}=1; - } - } # Don't forget to export the 'Main' function for wrapped executables, # except for MFC ones! - if (@$target[$T_FLAGS] == $TF_WRAP) { + if ((@$target[$T_FLAGS]&($TF_WRAP|$TF_WRAPPER|$TF_MFC)) == $TF_WRAP) { if (@$target[$T_TYPE] == $TT_GUIEXE) { print FILEO "\n@ stdcall @$target[$T_INIT](long long ptr long) @$target[$T_INIT]\n"; } elsif (@$target[$T_TYPE] == $TT_CUIEXE) { @@ -1867,6 +1871,7 @@ generate_list("${canon}_LIBRARY_PATH",1,@$target[$T_LIBRARY_PATH]); generate_list("${canon}_LIBRARIES",1,@$target[$T_LIBRARIES]); generate_list("${canon}_DEPENDS",1,@$target[$T_DEPENDS]); + generate_list("${canon}_IMPORTS",1,@$target[$T_DLLS]); print FILEO "\n"; generate_list("${canon}_OBJS",1,["\$(${canon}_C_SRCS:.c=.o)","\$(${canon}_CXX_SRCS:.cpp=.o)","\$(EXTRA_OBJS)"]); print FILEO "\n\n\n"; @@ -1952,7 +1957,7 @@ print FILEO "\t-\$(STRIP) \$(STRIPFLAGS) \$\@\n"; print FILEO "\n"; print FILEO "\$(${canon}_SPEC_SRCS:.spec=.spec.c): \$(${canon}_SPEC_SRCS) \$(${canon}_SPEC_SRCS:.spec=.tmp.o) \$(${canon}_RC_SRCS:.rc=.res)\n"; - print FILEO "\t\$(LD_PATH) \$(WINEBUILD) -fPIC \$(${canon}_DLL_PATH) \$(WINE_DLL_PATH) -sym \$(${canon}_SPEC_SRCS:.spec=.tmp.o) -o \$\@ -spec \$(SRCDIR)/\$(${canon}_SPEC_SRCS)\n"; + print FILEO "\t\$(LD_PATH) \$(WINEBUILD) -fPIC \$(${canon}_DLL_PATH) \$(WINE_DLL_PATH) -sym \$(${canon}_SPEC_SRCS:.spec=.tmp.o) -o \$\@ -spec \$(SRCDIR)/\$(${canon}_SPEC_SRCS) \$(${canon}_IMPORTS:%=-l%)\n"; print FILEO "\n"; my $t_name=@$target[$T_NAME]; if (@$target[$T_TYPE]!=$TT_DLL) { @@ -2168,7 +2173,7 @@ print STDERR "Usage: winemaker [--nobanner] [--backup|--nobackup] [--nosource-fix]\n"; print STDERR " [--lower-none|--lower-all|--lower-uppercase]\n"; print STDERR " [--lower-include|--nolower-include]\n"; - print STDERR " [--guiexe|--windows|--cuiexe|--console|--dll]\n"; + print STDERR " [--guiexe|--windows|--cuiexe|--console|--dll|--nodlls]\n"; print STDERR " [--wrap|--nowrap] [--mfc|--nomfc]\n"; print STDERR " [-Dmacro[=defn]] [-Idir] [-Pdir] [-idll] [-Ldir] [-llibrary]\n"; print STDERR " [--interactive] [--single-target name]\n"; @@ -2181,9 +2186,6 @@ exit (2); } - -project_init(\@main_project,""); - while (@ARGV>0) { my $arg=shift @ARGV; # General options @@ -2244,11 +2246,13 @@ $opt_flags&=~$TF_WRAP; } elsif ($arg eq "--mfc") { $opt_flags|=$TF_MFC; - $opt_flags|=$TF_MFC|$TF_WRAP; $needs_mfc=1; } elsif ($arg eq "--nomfc") { - $opt_flags&=~($TF_MFC|$TF_WRAP); + $opt_flags&=~$TF_MFC; + $opt_flags|=$TF_NOMFC; $needs_mfc=0; + } elsif ($arg eq "--nodlls") { + $opt_flags|=$TF_NODLLS; # Catch errors } else { @@ -2263,6 +2267,11 @@ usage(); } } + + if ($opt_flags & $TF_MFC && $opt_target_type != $TT_DLL) { + print STDERR "info: option --mfc requires --wrap\n"; + $opt_flags |= $TF_WRAP; + }; } if (!defined $opt_work_dir) { @@ -2278,6 +2287,8 @@ print_banner(); } +project_init(\@main_project,""); + # Fix the file and directory names fix_file_and_directory_names("."); @@ -3094,6 +3105,8 @@ * This is either CUIEXE for a console based application or * GUIEXE for a regular windows application. */ +#define GUIEXE 0 +#define CUIEXE 1 #define APP_TYPE ##WINEMAKER_APP_TYPE## /** @@ -3138,11 +3151,11 @@ int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow) #else -int WINAPI Main(int argc, char** argv, char** envp) +int WINAPI main(int argc, char** argv, char** envp) #endif { void* appLibrary; - HINSTANCE hApp,hMFC,hMain; + HINSTANCE hApp = 0, hMFC = 0, hMain = 0; void* appMain; char* libName; int retcode; @@ -3212,7 +3225,7 @@ } /* Get the address of the application's entry point */ - appMain=(WinMainFunc*)GetProcAddress(hMain, appInit); + appMain=GetProcAddress(hMain, appInit); if (appMain==NULL) { char format[]="Could not get the address of %s (%d)"; char* msg; @@ -3232,11 +3245,6 @@ #endif /* Cleanup and done */ - FreeLibrary(hApp); - if (hMFC!=NULL) { - FreeLibrary(hMFC); - } - dlclose(appLibrary); free(libName); return retcode; Index: documentation/winemaker.man =================================================================== RCS file: /home/wine/wine/documentation/winemaker.man,v retrieving revision 1.5 diff -u -r1.5 winemaker.man --- documentation/winemaker.man 2 Oct 2001 17:47:34 -0000 1.5 +++ documentation/winemaker.man 22 May 2002 16:49:19 -0000 @@ -17,7 +17,7 @@ ] .br [ -.IR "--guiexe " "| " "--windows " "| " "--cuiexe " "| " "--console " "| " "--dll " +.IR "--guiexe " "| " "--windows " "| " "--cuiexe " "| " "--console " "| " "--dll " "| " "--nodlls " ] .br [ @@ -121,6 +121,14 @@ i.e. for which it does not know whether it is an executable or a library, it should assume it is a library. .TP +.I --nodlls +This option tells winemaker not to use the standard set of winelib libraries +for imports. That is, any DLL your code uses must be explicitly passed to +winemaker with -i options. +The standard set of libraries is: advapi32.dll, comdlg32.dll, gdi32.dll, +kernel32.dll, odbc32.dll, ole32.dll, oleaut32.dll, shell32.dll, user32.dll, +winspool.drv. +.TP .I --wrap Specifies that executable targets should be built as libraries and a small executable wrapper generated for them. This technique is sometimes required @@ -137,7 +145,9 @@ generates wrappers for these targets that are executables. .TP .I --nomfc -Specifies that targets are not MFC-based. This is the default. +Specifies that targets are not MFC-based. This option disables use of MFC libraries +even if winemaker encounters files "stdafx.cpp" or "stdafx.h" that would cause it +to enable MFC automatically if neither --nomfc nor --mfc was specified. .TP .I -Dmacro[=defn] Adds the specified macro definition to the global list of macro definitions. @@ -149,8 +159,7 @@ Appends the specified directory to the global library path. .TP .I -idll -Adds the Winelib library to the global list of Winelib libraries to import -in the spec file. +Adds the Winelib library to the global list of Winelib libraries to import. .TP .I -llibrary Adds the specified library to the global list of libraries to link with.

2 5

Translation wine documentation to other languages
by Andriy Palamarchuk 01 Aug '02

01 Aug '02

Sorry for crossposting initial message to both lists. I think the topic may be interesting for both - users and developers. Any volunteers to help to translate the documentation to languages other than English? This is very big job, so there can be more than one person, working on the same language. Among responses to my call for volunteers I got response from Pedro Restrepo suggesting his help in Wine localization. See his message below. Damian Wojslaw requested information on the same topic on wine-users. --- Pedro Restrepo <pedrores(a)tutopia.com> wrote: > Hi Andiry, > > First, thank you and thanks to all people working on > Wine. I am using > Wine to run Lotus Notes Client on Linux. At the > moment, we are testing > it. > > I want to help on Wine project. I propose you one > new work: Wine > translation to spanish (documentation, installer, > web site info, etc). I > think in this work because I think this project is > necessary for all > people who need transition tools from Windows to > Linux and there are > many people in this situation in SouthAmerica (I am > from Colombia and I > am tired of the big payments for software in our > poor nations). Currently Wine does not have official documentation in other languages. Some winelib applications are localized to other languages. Documents with highest priority for translation: * README file * Wine User Guide * user-oriented pages on Winehq Plus, we'll need to keep translations in sync with original documentation. Comments, ideas, suggestions? Andriy __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

2 1

MS' hidden API
by Zhang Shu 09 Jul '02

09 Jul '02

Dear wine developers, I have one question on the development of wine. Long(one or two years) ago I've heard that Microsoft got some hidden APIs in their products of various windows, and they use these APIs in their own applications. I wonder if this is still a problem on their recent product like windows XP. If it is, I guess wine will not be able to run such MS applications which uses hidden APIs. Is this right? And, is wine designed(or its goal is) to run all applications(including MS product and non-MS product) that runs on windows? Please forgive me if this problem has appeared in the past. I just joined this list a couple of days ago. Thank you. Regards, -- Zhang Shu

10 10

wine can't find regedit.exe.so when it is not on the path
by Andriy Palamarchuk 20 Jun '02

20 Jun '02

wineinstall fails because wine can't find regedit.exe.so. Obviously, the wine source directory does not exist in path of just created config file. After the wineistall failure .wine directory with config file are created. I get the same errors when I try to run regedit manually, even with using full path: $ /prj/wine/programs/regedit/regedit Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: Could not stat /cdrom (No such file or directory), ignoring drive D: Warning: could not find wine config [Drive x] entry for current working directory /mnt/buf/prj/wine; starting in windows directory. Warning: /prj/wine/programs/regedit/regedit.exe.so not accessible from a configured DOS drive Warning: /prj/wine/programs/regedit/regedit.exe.so not accessible from a configured DOS drive /prj/wine/miscemu/wine: cannot find '/prj/wine/programs/regedit/regedit.exe.so' $ file /prj/wine/programs/regedit/regedit.exe.so /prj/wine/programs/regedit/regedit.exe.so: ELF 32-bit LSB shared object, Intel 80386, version 1, not stripped $ ls -l programs/regedit/regedit lrwxrwxrwx 1 apalamar apalamar 23 May 30 06:53 programs/regedit/regedit -> ../../tools/winewrapper Andriy __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

4 5

Re: Winehq: Bugzilla responsibilities page
by Andreas Mohr 06 Jun '02

06 Jun '02

On Wed, May 29, 2002 at 12:06:22PM -0700, Andriy Palamarchuk wrote: > Changelog: > Added bugzilla responsibilities page. Hi, hmm, I'm not 100% sure about this. - why did you remove bug tracking link ? - "Talking Back" probably isn't very descriptive. I'd add something like "... (bugs etc.)" - that's Albe*r*telli - Application owners play *an* important role in the bugs handling process. - why add a whole new talkback.inc ? isn't that a bit overkill ? - why is <li>Bugs Hunting Guide</li> non-functional text ? Wow, questions over questions :-) Good job with bugz_resp.inc, BTW !! Needless to say I'll add this immediately as soon as these questions are covered :) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

3 4

Re: Lower bugs changing note
by Andriy Palamarchuk 04 Jun '02

04 Jun '02

--- Dustin Navea <speeddymon(a)yahoo.com> wrote: > The changes on the lower numbered bugs are done by > me, > trying to get some of these old bugs out of he list > of > ones to be worked on, if they have been fixed..... I noticed :-) Dustin, thank you for the great work you do. It was long overdue to clean these old issues. I have some comments - sometimes you mark as resolved and ask to reopen if the bug still exists bugs with very nice reports. I think this is good approach when you can't check whether the problem still exists or for some obscure applications, but many of the bug reports you closed are short, nice and consious. I think better approaches with these sort of bug reports is: a) try to reproduce yourself - the best approach. Your confirmation in the bug comments is very important for developer who may try to fix the issue. b) if research looks complex - a half a way to solving a bug, you can add comment, smth like "Needs to be confirmed". In both cases bug can be assigned to the component owner. c) ask to confirm without resolving the bug All these approaches insure that bug report won't be forgotten and this can happen if the bugs are just marked as "resolved". Could you try to go through the old bugs you marked as resolved? I already started to do this. I'll leave my comments in the bugs I reviewed. Thanks, Andriy __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

2 1

FW: WINE with MFC and C++ DLLs (Was: Info on porting Wine dlls and programs to Mingw)
by Steven Edwards 04 Jun '02

04 Jun '02

In case anyone is interested in a alternitive to winemaker. Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson -----Original Message----- From: José Fonseca [mailto:j_r_fonseca(a)yahoo.co.uk] Sent: Friday, May 31, 2002 1:18 PM To: Steven_Ed4153(a)yahoo.com Cc: mingw-dvlpr(a)lists.sourceforge.net Subject: Re: WINE with MFC and C++ DLLs (Was: Info on porting Wine dlls and programs to Mingw) On 2002.05.31 17:44 Steven Edwards wrote: > MFC can and has been built with Wine although M$ licensing regarding > MFC on non-windows platforms is confusing as it has been changes a few > times. I think VS6 Before SP3 is OK. > This is nice to know. The MFC has been subject of long threads here. It's good to know that we can give some alternatives when people ask. (My general idea is that people who minimally care with cross-compiler (not to mention cross-platform) compatibility would never choose to build an application upon MFC - and that's probably the reason for why MFC has been loosing some ground and interest... ) > Also you guys might be insterested in the winemaker.pl script. It > converts VS makefiles to UNIX makefiles and can configure your win32 > application to be built with winelib+MFC. I may look at adapting it to > Mingw as part of the port I once made a small sed script for that, but probably it's not as complete as winemaker.pl. But we do have a fairly complete MS Dev Studio workspace to Unix Makefiles converter. It's availabable on http://mefriss1.swan.ac.uk/~jfonseca/gnu-win32/software/msds/ and it will soon be included on a "mingw-utils" package. Perhaps that might be interesting for the WINE Lib project too? Regards, José Fonseca

2 1

Improving debugging (gdb) support
by tijs＠connectux.com 04 Jun '02

04 Jun '02

Hi, I'd like to improve debugging support for Wine, and have time to undertake a larger project. Either I could work on winedbg to match gdb's features, or I could try to make gdb understand Wine better. Given the amount of useful frontends for gdb, it seems wiser to go for the second option. I'd love to be corrected if you think working on winedbg is a better choice. Gdb seems to have trouble understanding the way windows processes run in Wine. If anyone has thought about this, I'd like to know your opinions on a good solution to this problem. Furthermore, it seems useful to make gdb parse the .pdb format, or other debugging information. Winedbg already has a working pdb parser, which I could port to gdb. Feel free to push me in the right direction. -- Tijs van Bakel, ConnecTUX, <tijs(a)connectux.com>

7 7

Keyboard layout detection not working??
by Shachar Shemesh 02 Jun '02

02 Jun '02

Hi all, I am using Debian SID with KDE. In KDE, I defined two keyboard layouts (US and IL). I tried to add Israeli keyboard detection using the attached patch (layout.diff). When trying to test that patch, however, I perform the following task: I type in the command as suggested in the docs (wine --debugmsg +key,+keyboard >& key.log). Attached are two run attempts. key.log is with the US keyboard selected, key2.log is with the Hebrew keyboard selected. Comparing the two outputs, several things become evident: 1. The Israeli keyboard is not detected. It fails to match even the non-Hebrew characters (such as the '/' instead of lower case 'q'). It's as if WINE did not notice that a non-English keymap was installed. On the other hand, there are some differences between the two runs. What's going on? 2. The dvorak keyboard has 0 mismatches???? I noticed that the code has some different virtual mapping of the keyboard. I am not aware that dvorak keyboards generate a different scan code mapping. Am I missing something here? 3. There does not appear to be any code that detects layout changes in X11, and sends the apropriate WM_INPUTLANGCHANGE message. I understood that implementing an event trigered by X layout change is a difficult matter, but it is highly necessary for my BiDi support (many programs, including Office, know the current direction, and have visual representation when it changes. Not implementing this message may prove to be problematic in that respect). I currently don't have the capacity to go after this particular problem, but if it remains unsolved by the time it becomes crucial to me, I will. If anyone has any leads on solving this problem, please let me know. I have entered bug #735 on this issue. Many thanks for your input, Shachar Index: dlls/x11drv/keyboard.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/keyboard.c,v retrieving revision 1.1 diff -u -r1.1 keyboard.c --- dlls/x11drv/keyboard.c 30 Apr 2002 21:16:39 -0000 1.1 +++ dlls/x11drv/keyboard.c 28 May 2002 13:20:04 -0000 @@ -531,6 +531,15 @@ "zZ","xX","cC","vV","bB","nN","mM","öÖ","çÇ",".:" }; +/*** Israeli keyboard layout */ +static const char main_key_IL[MAIN_LEN][4] = +{ + "`~","1!","2@","3#","4$","5%","6^","7&","8*","9(","0)","-_","=+", + "/Q","'W","÷E","øR","àT","èY","åU","ïI","íO","ôP","[{","]}", + "ùA","ãS","âD","ëF","òG","éH","çJ","ìK","êL","ó:",",\"","\\|", + "æZ","ñX","áC","äV","ðB","îN","öM","ú<","õ>",".?" +}; + /*** VNC keyboard layout */ static const WORD main_key_scan_vnc[MAIN_LEN] = { @@ -600,6 +609,7 @@ {"Latin American keyboard layout", 28591, &main_key_LA, &main_key_scan_qwerty, &main_key_vkey_qwerty}, {"Lithuanian (Baltic) keyboard layout", 28603, &main_key_LT_B, &main_key_scan_qwerty, &main_key_vkey_qwerty}, {"Turkish keyboard layout", 28599, &main_key_TK, &main_key_scan_qwerty, &main_key_vkey_qwerty}, + {"Israeli keyboard layout", 28598, &main_key_IL, &main_key_scan_qwerty, &main_key_vkey_qwerty}, {"VNC keyboard layout", 28591, &main_key_vnc, &main_key_scan_vnc, &main_key_vkey_vnc}, {NULL, 0, NULL, NULL, NULL} /* sentinel */

4 14

User (developer ?) friendly execution trace
by max 01 Jun '02

01 Jun '02

I find tracing a wine problem with wine --debugmsg for large programs unpractical. Usually you can know about exactly when a program hangs or behaves badly, but there's no way to activate/deactivate tracing after program start (afaik...) Being also a windoze (sigh) programmer, I find very useful some utilities like winspy that presents a window log in which you can start/stop tracing or logging of wine messages, system calls and so on, and activate/deactivate filters on the fly. This would allow spotting the bug when it arises instead of having tenths or hundreds of mbyte of logs. I could implement it as a filter taking input from wine, but I guess it'll slow downn much apps, having to parse wine output on the fly. Much better would be an internal implementation.... Some comments about ? Regards Max

3 2