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

Re: CxxFrameHandler problem
by John K. Hohm 11 Apr '03

11 Apr '03

Alexandre Julliard <julliard(a)winehq.com> wrote: > Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > > > Appended program uses CxxFrameHandler and crashes in wine with builtin > > msvcrt, but not with native. Compile as Release version and include the > MFC > > dll. Can somebody compile for Alexandre? Alexandre, is this a start or do > > you need something complete? > > That's a start, yes, thanks. I'll need a more complete example with > nested try blocks, destructors all over the place, typed exceptions, > etc. to make sure I understand all the compiler internal structures; > but I can at least try to make that simple case not crash... Although this may duplicate effort, I am familiar with several strange combinations of exception handling that I know work with Visual C++ 6.0; I will put them a test program for you. You can never have too many test programs, right?

1 1

Right button clicks
by Fabian Cenedese 18 Sep '02

18 Sep '02

Hi Does Wine support right mouse button double clicks? I have an App with a dialog (in fact an overridden MFC CDialog for about infos) in which I can double click with the right mouse button to show some additional info. But they never show up. After +relay tracing the messages I found that only WM_RBUTTONDOWN and WM_RBUTTONUP messages are generated, none of them get converted into clicks or even double clicks, no matter how fast I click. Does anyone have an idea? Thanks Fabi

2 3

Re: Wine Hides On-board RAM
by Ian D. Stewart 16 Sep '02

16 Sep '02

On 2002.08.18 12:21 Andreas Mohr wrote: > On Sun, Aug 18, 2002 at 11:32:54AM -0400, Ian D. Stewart wrote: > > I have recently noticed an unusual side-effect of running Wine. > When I > > first start up my system, /proc/meminfo reports MemTotal as 256892 > kb. > > After running Wine for awhile, /proc/meminfo reports MemTotal as > 32680 > > kb. The system performs as if it only had 32 MB of RAM. A reboot > of > > the system resets total memory to the proper value. > > > > My question is: > > > > 1) Has anybody else encountered this? > > 2) Does anyone know what causes this, or better yet how to avoid it? > > 3) Is there anyway to recover the lost RAM short of a reboot? > > Huh ? This is very, very, VERY strange ! > Something like this should never happen. > Are you sure it's caused by Wine only, or maybe it is due to faulty > memory > instead ? (and thus the board/Linux notices that only 32MB are useable > and resorts to accessing 32MB only). Well I can't say with absolute certainty that it's caused by Wine, but the system runs without any problems for extended periods of time so long as I don't run Wine, and consistently 'loses' memory when I *do* run wine. I don't know exactly what's going on. I do know that there appears to be some sort of threshold that is reached at which point the memory hiding occurs (e.g., the same issue arises whether I run Wine for 5 hours at one shot or for 30 minutes a day for 10 days) and the threshold isn't 'reset' until I reboot. > > Again, I'm utterly puzzled when hearing such a story. > Or maybe Wine accesses some Linux memory management function in some > way > that causes Linux to tamper with the value for some reason ? > This wouldn't be the first time that Wine is the only program to > reveal > some severe bug in Linux memory management... > > Definitely try upgrading your kernel, too. I have no problem with upgrading, but I would like to know *why* I am upgrading (i.e., what bug is causing the problem, and how does the new kernel address the bug). To do otherwise strikes me as being equivelant to the tendency in the Windows community whenever something odd happens. Thanx for the input, Andreas. Ian

5 8

Re: Re:can windows be reparented?
by Dmitry Timoshkov 13 Sep '02

13 Sep '02

<us(a)the-edmeades.demon.co.uk> wrote: > To be honest I never investigated further once I commented out the SetParent call, > as I was continuing to fix oleaut32 and left the gui side to someone else! > > I know it was being called in the failing case, and removing it allowed the > windows to pop up, BUT they were still wrong as you could access the 'parent' > whereas you should not be able to Could you please test patch posted by Bill Medland to wine-patches today? It's not entirely correct though. My tests show that SetWindowLong(GWL_HWNDPARENT) call changes simultaneously both parent and owner for top level windows and returns old value (not sure old owner or parent it is). But top level windows created by Visual Vasic are special: they have no parent, but only owner according to Spy++. In my tests I can't reproduce it yet. A bit of investigation of Wine source revealed that some places use GetAncestor(hwnd, GA_PARENT), while others use GetParent(hwnd). Since their behaviour is different in respect of top level and child windows, some major clean up in that area in Wine is needed. -- Dmitry.

4 5

re: RFC: 'test' bugzilla keyword
by Dan Kegel 09 Sep '02

09 Sep '02

Francois Gouget wrote: > if we make it easy to track > conformance test issues in Bugzilla, we may get new contributers (sure I > realize it's not a magic bullet either). Thus I propose to add a 'test' > keyword to make it easy to find such issues in bugzilla for people > specifically interested in conformance tests. Excellent idea. The keyword 'test' might be a bit confusing -- some bug tracking systems use that word as a state. How about something short that has very few hits on Google? Like, um, "apifail" or "unitfail"? - Dan

4 6

[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

Press: Running Windows Games with WineX 2.1
by Francois Gouget 08 Sep '02

08 Sep '02

* August 29, 2002 - LinuxOrbit Break out Your Games Library: Running Windows Games with WineX 2.1 http://www.linuxorbit.com/modules.php?op=modload&name=Reviews&file=index&re… -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.

3 5

Problem with regression tests getting stuck
by Paul Millar 04 Sep '02

04 Sep '02

Hi everyone, I've had the regression tests freeze on me again (see [1] for previous report). Sylvain has reported problems with the wininet regression tests (described in [2]). The symptoms are the same, but for me the problem is only intermittent. This time I caught the problem with gdb and obtained the following info: [...] Loaded symbols for /lib/libresolv.so.2 0x402e7744 in __libc_close () at __libc_close:-1 -1 __libc_close: No such file or directory. in __libc_close (gdb) bt #0 0x402e7744 in __libc_close () at __libc_close:-1 #1 0x400ec9a4 in __DTOR_END__ () from /home/paulm/WINE-cvs/wine/dlls/libntdll.dll.so #2 0x400b3df5 in WaitForMultipleObjectsEx (count=0, handles=0x0, wait_all=0, timeout=100, alertable=0) at ../../scheduler/synchro.c:257 #3 0x400b3b88 in Sleep (timeout=100) at ../../scheduler/synchro.c:178 #4 0x40358747 in winapi_test (flags=268435456) at tests/http.c:121 #5 0x40358b36 in func_http () at tests/http.c:184 #6 0x40358f9d in run_test (name=0xbffffc63 "http.c") at wtmain.c:244 #7 0x40357037 in __wine_exe_main () at wininet_test.exe.spec.c:133 #8 0x400aff84 in start_process () at ../../scheduler/process.c:528 #9 0x400b3f3f in call_on_thread_stack (func=0x400afd2c) at ../../scheduler/sysdeps.c:108 So, to summarise (with some extra bits of information): The problem occurs when wininet/tests/http.c is testing asynchronous HttpSendRequest(), so flags > 0. The problem is triggered at line 121 of http.c, i.e.: 120 while ((flags)&&(!goon)) 121 Sleep(100); Sleep(), in turn, just calls WaitForMultipleObjectsEx(). From scheduler/synchro.c: 176 VOID WINAPI Sleep( DWORD timeout ) 177 { 178 WaitForMultipleObjectsEx( 0, NULL, FALSE, timeout, FALSE ); 179 } WaitForMultipleObjectsEx() has problems when it gets to 257: 256 SERVER_END_REQ; 257 if (ret == STATUS_PENDING) ret = wait_reply( &cookie ); 258 if (ret != STATUS_USER_APC) break; ret is 1079729528, btw. AFAIK, __DTOR_END__ (see near bottom of stack) is the destructor for a function call in ntdll. I'm probably missing something obvious, but I don't see the connection between scheduler/synchro.c:257 and ntdll. The closest is wait_reply() (in scheduler/client.c) calls wait_reply_data (in same file), which calls NtCurrentTeb(), which is commented as an NTDLL function. But there doesn't seem to be an implementation of NtCurrentTeb in ntdll. Any ideas? Cheers, Paul. [1] http://www.winehq.com/hypermail/wine-devel/2002/08/0006.html [2] http://www.winehq.com/hypermail/wine-devel/2002/07/0386.html PS, I'll create a bugzilla in a bit. ---- Paul Millar

2 4

Quartz DLL
by tom 03 Sep '02

03 Sep '02

Hello, I was looking at the WineX cvs version on sourceforge and it looks as if they have a quartz.dll based on ffmpeg. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/winex/wine/dlls/quartz/ What are the odd's of this work being put into the main wine tree ? As the old quartz.dll got pulled........ Tom

6 6

ALSA 0.9 sound problems
by TJ 02 Sep '02

02 Sep '02

Hi =) I have ALSA 0.9 with OSS compat modules. I recently got DeusEx to run (on Wine w/ openGL, not talking about WineX) However using winealsa.drv sound is very laggy and lots of nasty clicks and hissing occurs, but if I use wineoss.drv sound is fine?? (note OSS driver will be talking to ALSA via the snd-pcm-oss compat module) Also when using the wineoss module and the game (not just DeusEx but most games I got working) is setting up sound it seems to freeze, all i do then is ctrl+z, fg, in controling term and things run fine from then on. -TJ

3 4