wine-devel

wine-devel@winehq.org

84471 discussions

patches policy
by Dimitrie O. Paun 10 Sep '02

10 Sep '02

Hi all, There is something concerning submitting patches that bothers me to no end: inlining vs. attaching them. I don't know about others, but for me 99/1 rule applies: I at least skim over 99% of the patches inlines in the message, whereas I bother to read at most 1% of the ones attached/tar.gzed/ziped. Maybe I'm an extreme case, but there's got to be more to it than my personal quirks. If a patch is sent to wine-patches, it's sent there for peer review. If you don't want the review, send it to Alexandre directly, even though I suggest this is avoided as much as possible. However, it you do send it to wine-patches, please, *please* inline it! What about a nice patch submission policy: -- unified diff only (required) -- have a decent subject (recommended) -- a long description (optional, if the change warrants it) -- a meaningful ChangeLog entry (required) -- new files, if any, included in patch, diffed against /dev/null (required) -- patch inlined at the end of the message (required) -- one changeset per message Most of these things are already followed by most people, with the exception of the inlining bit. Alexandre, what about you reject patches that aren't in this format with a pointer to these rules? All this is a matter of habit, and I think we'll all benefit if these rules are followed. -- Dimi.

9 12

mssip.h trouble
by Dimitrie O. Paun 10 Sep '02

10 Sep '02

While compiling the latest tree, I get this: [dimi@dimi wine]$ make -s In file included from ../../include/mssip.h:49, from main.c:22: ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" In file included from ../../include/mssip.h:80, from main.c:22: ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" In file included from ../../include/mssip.h:88, from main.c:22: ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" In file included from ../../include/mssip.h:97, from main.c:22: ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" In file included from ../../include/mssip.h:109, from main.c:22: ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" In file included from ../../include/mssip.h:123, from main.c:22: ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" In file included from ../../include/mssip.h:140, from main.c:22: ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" nm: devenum.dll.tmp.o: no symbols nm: dplay.dll.tmp.o: no symbols -- Dimi.

1 0

Re: winedbg: enhancing symbol lookup
by Alexandre Julliard 10 Sep '02

10 Sep '02

Eric Pouech <eric.pouech(a)wanadoo.fr> writes: > --- debugger/break.c 30 Jul 2002 00:06:34 -0000 1.35 > +++ debugger/break.c 2 Sep 2002 19:39:59 -0000 > @@ -421,10 +421,15 @@ > DBG_VALUE value; > int i; > > - if (DEBUG_GetSymbolValue(name, lineno, &value, TRUE)) > + switch (DEBUG_GetSymbolValue(name, lineno, &value, TRUE)) > { > + case TRUE: > DEBUG_AddBreakpoint(&value, NULL, TRUE); > return; > + case FALSE: > + break; > + case ABORT: /* user aborted symbol lookup */ > + return; > } Please don't invent a third boolean state. A boolean is either TRUE or FALSE; if you need more than that you should define a new enum type with meaningful names. Reusing TRUE and FALSE will cause major confusion. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: winemaker: wineapploader generation
by Alexandre Julliard 10 Sep '02

10 Sep '02

Francois Gouget <fgouget(a)codeweavers.com> writes: > * tools/winemaker > Generate wineapploader using autoconf rather than from the Makefile Actually it's better to generate this kind of file from the Makefile; this way you can change things without having to re-run configure (by passing the values directly to make). For that reason the autoconf guidelines state that configure should only generate makefiles, not other files. -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: patches policy
by Patrik Stridvall 09 Sep '02

09 Sep '02

> There is something concerning submitting patches that bothers me > to no end: inlining vs. attaching them. Yes!!! Finally. Another flamewar. :-) I will mainly comment how I submit my patches. I don't personally care that much what others do. However if Alexandre finds some way more convenient I can certain change... > I don't know about others, but for me 99/1 rule applies: I at least > skim over 99% of the patches inlines in the message, whereas > I bother to read at most 1% of the ones attached/tar.gzed/ziped. > Maybe I'm an extreme case, but there's got to be more to it than > my personal quirks. > > If a patch is sent to wine-patches, it's sent there for peer review. > If you don't want the review, send it to Alexandre directly, even > though I suggest this is avoided as much as possible. However, > it you do send it to wine-patches, please, *please* inline it! > > What about a nice patch submission policy: > -- unified diff only (required) Agreed (if the file already exists). > -- have a decent subject (recommended) Agreed. > -- a long description (optional, if the change warrants it) Agreed. > -- a meaningful ChangeLog entry (required) Agreed. > -- new files, if any, included in patch, diffed against > /dev/null (required) I currently use .tar files since it handles the case that Uwe was talking about that is new directories. But then, I use a script to generate my patches, so I can make the normal case (no new directory) as a diff against /dev/null. > -- patch inlined at the end of the message (required) If it is inlined at all it should certainly be at the end, agreed. > -- one changeset per message What about dependent changesets? Or changeset that are otherwise logically dependent (even if not syntactically or semantically)? I guess they could be perhaps is multiple messages like: Subject: Fix various bugs (part 1 of 3) Subject: Fix various bugs (part 2 of 3) Subject: Fix various bugs (part 3 of 3) I currently mail all my patches from Windows (Outlook) just out of habit I guess since it is where I send my other mail so that would require manual work. However I guess I could mail them directly from my Linux box using another script...

3 2

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@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

Recent change causes bad QuickBooks behaviour(?)
by Carl Sopchak 09 Sep '02

09 Sep '02

I have been using Wine to run QuickBooks fairly successfully for several months now. However, I frequently do CVS updates because I'm also trying to run Quicken, and there are several issues that I'm hoping will get fixed this way. (I have fixed a few of them myself, and am working on one now, but my time [like everyone else's, I'm sure] is limited...) It's been a few weeks since I've run QuickBooks (8/19 was my last transaction date, so it'd be somewhere around there...). When I went to run it today (after several CVS updates on wine, including "moments ago"), after the company data file is opened, the main menu bar goes away. This was definately NOT a problem the last time I ran QuickBooks, so I surmise that it is the result of a change committed to CVS within the past two to three weeks that is causing this behaviour. It happens in both managed and unmanaged window mode. Basically, the main menu bar should be at the top of the window, but the configurable taskbar / buttonbar is displayed "over" it. The accellerator keys for the menu bar are no longer recognised (the program beeps if you try to use <alt>f [for example] to get to the File menu). I am more than willing to try to debug this. I'd really rather not go back to Windows to run QuickBooks, but I HAVE TO HAVE it (for running my company's finances!) But, before I spend days trying to find out what changed in the past few weeks, I was wondering (no, hoping, really) if anyone might recognize this problem as being a possible result of a recent CVS committed change. Well, in the mean time, I guess I'll look through the CVS commits from the past few weeks (arghhh!)... Any help would be greatly appreciated... Thanks, Carl

3 6

RE: Wine DLLs compiled under Visual C
by Patrik Stridvall 09 Sep '02

09 Sep '02

> > Yes. I have submitted most of my changes of that kind to the > > CVS so the current status of that is quite good. > > What is the status of WINE under MS_VC? I ask because I dont > have a copy of MS_VC and I would like > to see if there is anything that builds right with it but not > with Mingw/Cygwin. What > dlls/programs can you build atm? The compile status in general is quite good. The link status however is not. A lot more work remains.

1 0

RE: Wine DLLs compiled under Visual C
by Patrik Stridvall 09 Sep '02

09 Sep '02

> I want to get some comments about how others here try to get the DLLs > compiled > under Visual C. I went ahead and tried to do this for > shell32.dll and after > a > little work it went so far fine. However after creating a > config.h file for > Visual C with a few definitions such as for inline, I had to > make some minor > changes to some of the c source files such as adding an > #include "config.h" > and sometimes #include "wine/port.h" to the beginning. Yes. I have submitted most of my changes of that kind to the CVS so the current status of that is quite good. > Is this the recommended way of doing things or is there a reason that > "config.h" > shouldn't be included in some of the dll source files? I ask because I > noticed > that in a few of the shell32 files it is included but in the > several of them > it wasn't and in a few it doesn't (yet) need to be. Use msvcmaker. It generates Visual Studio 6.0 .dsw and .dsp files as well as an include/config.h file. cd wine ./tools/winapi/msvcmaker Then open wine.dsw in Visual Studio. PS. Note that msvcmaker only runs under Unix. I use Samba to export the directory to Windows.

2 1

Re: Trying to debug Paradise Poker client
by Per Nystrom 09 Sep '02

09 Sep '02

Ok, these are the lines that concern me when I'm running it with the builtin advapi32 dll: 080995d0:Call advapi32.CryptAcquireContextA(41ee6570,00000000,00000000,00000001,f0000000) ret=40cc424b 080995d0:Ret advapi32.CryptAcquireContextA() retval=00000000 ret=40cc424b 080995d0:Call advapi32.CryptAcquireContextA(41ee6570,00000000,40d0e840 "Intel Hardware Cryptographic Service Provider",00000016,00000000) ret=40cc429c 080995d0:Ret advapi32.CryptAcquireContextA() retval=00000000 ret=40cc429c What can be done to fix it? Thanks, Per Nystrom

2 1

Wine DLLs compiled under Visual C
by Rolf Kalbermatter 09 Sep '02

09 Sep '02

I want to get some comments about how others here try to get the DLLs compiled under Visual C. I went ahead and tried to do this for shell32.dll and after a little work it went so far fine. However after creating a config.h file for Visual C with a few definitions such as for inline, I had to make some minor changes to some of the c source files such as adding an #include "config.h" and sometimes #include "wine/port.h" to the beginning. Is this the recommended way of doing things or is there a reason that "config.h" shouldn't be included in some of the dll source files? I ask because I noticed that in a few of the shell32 files it is included but in the several of them it wasn't and in a few it doesn't (yet) need to be. Rolf Kalbermatter

1 0

RE: New header winternl.h
by Patrik Stridvall 09 Sep '02

09 Sep '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > The easy solution is to include the header just as I have > submitted it > > and not use it at all or rather postponing the problem of > using it or not > > to the future. If it exists somebody might get some ideas, > some day... > > But this won't really address the issue; if we don't use the header it > will most likely get broken by something and nobody will notice, and > then when someone uses it in Winelib we have the same problem. True. > I think we should add the header and use it instead of ntddk.h where > possible. This probably requires adding/moving definitions to it that > are currently in ntddk.h, but that's acceptable as long as they are > exported under Windows anyway. And it's better to follow the SDK than > the DDK where we can, since this is what apps we want to build with > Winelib will be using too. Agreed. If you apply the patch, I will see what I can do. I have already looked into it a little. However I think most of what is in ntddk.h must be moved into wintrnl.h. Possible some stuff should go in some other wine/*.h header. Do you want things that is only defined in ntddk.h be protected by #ifdef __WINE__ so no normal Windows application can't use them?

2 1

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

May we use winelib-wcmd as $COMSPEC command processor?
by Uwe Bonnes 08 Sep '02

08 Sep '02

Hallo, some java program in the Xilinx webpack suite is started as a batch file from a perl script. When the batch should be executed, the perl script looks for the $COMSPEC variable and starts the batch like: Call kernel32.CreateProcessA(40c82e0c "c:\\command.com",40c8fee4\ "c:\\command.com /c I:\\xilinx\\bin\\nt\\ChipView.bat -f magcom.vm6"... Pointing $COMSPEC to the winelib wcmd processor doesn't work as expected, as CreateProcess tries to execute wcmd as windows executable, as CeateProcess is called like: Call kernel32.CreateProcessA(40c8248f\ "h:/tmp/wine/compile/wine/programs/wcmd/wcmd",40c8ff1c\ "h:\\tmp\\wine\\compile\\wine\\programs\\wcmd\\wcmd /c\ I:\\xilinx\\bin\\nt\\ChipView.bat -f magcom.vm6",... I there any way to use winelib-wcmd in this situation? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 5

RE: New header winternl.h
by Patrik Stridvall 08 Sep '02

08 Sep '02

> On Sun, 8 Sep 2002, Jürgen Schmied wrote: > > > > > > And do what? > > > As I said above wintrnl.h can't include ntddk.h. > > > > > > Of course we can just include it as it is and don't use it... > > I would do nothing as long as nobody needs it. There are > many *.h files > > in the SDK that we don't have and nobody missed them till today. > > Missing headers are making the lives of Winelib users pretty hard: the > first time they try to compile their application they get tons of > errors. They first wonder what they are doing wrong, then why > Wine does > things differently from Windows, is there a hidden reason, > and then how > the hell they are going to fix the headers and their messy > dependencies > and whether they should not rather completely give up. Fully agreed. Every header that it missing or wrong (even if fixing it is trivial) is a potential: "Sorry boss, I tried to compile our application with WineLib but it didn't work. So we can't port our applications using WineLib.". > Now, I'm not saying we should spend all our time trying to > make sure our > headers are perfect rather than improving binary emulation. As with > everything this is a question of balance. I have being planning a long time to write a Perl script that compares the Microsoft SDK headers with the Wine headers. I just haven't got around to do it... So don't hold your breath. > Now concerning this header, since it's so new (and quite useless) it > certainly isn't going to be a problem soon and as you pointed out we > definitely have other header issues to tackle first. Still if we can > find an easy nice solution, let's go for it (unfortunately that does > not appear to be the case). The easy solution is to include the header just as I have submitted it and not use it at all or rather postponing the problem of using it or not to the future. If it exists somebody might get some ideas, some day... Note that you can use it as long as you don't include ntdef.h or ntddk.h as well so the non-core DLLs should be able to use it without any problem. Nether the less I would strongly advise that the non-core DLLs doesn't use it either unless it REALLY, REALLY, REALLY must...

2 1

RE: New header winternl.h
by Patrik Stridvall 08 Sep '02

08 Sep '02

> On 7 Sep 2002 at 18:42, Patrik Stridvall wrote: > > > As of Microsoft SDKs August 2002 there is a brand new > > header called winternl.h that contains a part of the > > relased information. > For me this header looks like they copyed some informations > from the ntddk in hurry into one file to release it. It's definitely > not covering a complete api. > We should leave this informations in ntddk.h and replace > the winternl.h with a file containing only #include "ntddk.h" > if there is some additional information in wintenl.h it shouldn't > hurt to merge it into the aprobiate headers. The problem is that we don't (and shouldn't) install ntdef.h and ntddk.h but we should do that with wintrnl.h since it is an official header and might be used by a Winelib application. Of course since it first appear a few weeks ago not many application are likely to use it yet... > > Unfortunetly it can't be included at the same time > > as ntdef.h and ntddk.h because it partly defines the > > same information. > The problem is we need a mix between sdk and ddk headers > in our include directory. We could separate it but I don't > know if its > worth the work. I'm not sure either. > > Now, I have the full Microsoft SDK August 2002 contains > > over 1000 .h files!!! But ntdef.h and ntddk.h is not > > among them. They doesn't seem to be offical headers or > > at least not any more. > They are in the ddk. Of course, I should I guessed from the name ntddk.h, that it is from the DDK after all... :-) > > So I'm a little unsure on how the headers should be organised. > > winternl.h contains to little information to fully replace > > ntdef.h/ntddk.h in fact in some cases of the enums in winternl.h > > is incomplete but the full enum exists in ntddk.h!!! > Yes see abouve. This file is a mess! Agreed. :-) > > Futhermore some of the functions and data structures in ntddk.h > > is defined in no header in the offical Microsoft SDKs!!! > DDK ;-) > > > While we probably should include winternl.h because its an offical > > header I'm a little unsure on how or whether we should use it > > ourselves and what we should do with ntdef.h/ntddk.h. > We don't should us it at all. > > > Any suggestions? > Keep cool ;-) And do what? As I said above wintrnl.h can't include ntddk.h. Of course we can just include it as it is and don't use it...

3 2

RE: TBS_DOWNISLEFT
by Patrik Stridvall 08 Sep '02

08 Sep '02

> Can someone with a recent SDK tell me the value of TBS_DOWNISLEFT, > defined in commctrl.h? #if (_WIN32_IE >= 0x0501) #define TBS_DOWNISLEFT 0x0400 // Down=Left and Up=Right (default is Down=Right and Up=Left) #endif

1 0

TBS_DOWNISLEFT
by Dimitrie O. Paun 08 Sep '02

08 Sep '02

Can someone with a recent SDK tell me the value of TBS_DOWNISLEFT, defined in commctrl.h? TIA, Dimi.

2 1

Re: Disregard Resent:[From Steven Edwards]PATCH: Fix build wcmd on windows
by Steven Edwards 07 Sep '02

07 Sep '02

--- Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: > > Please disregard for now, as compiling wcmd as winelib application fails > when "unsigned __int64" is used. From reading MSDN it seems that "unsigned > __int32" should be used however. > So should we just #ifdef the code for _WINDOWS or redefine in port.h unsigned __int64 to unsigned __int32? I would like to get wcmd workinng as ReactOS now has simple windowing going and we are close to getting winemine and a few other simple win32 applications going. Thanks Steven __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com

1 0

How to add test to msvcrt directory
by Uwe Bonnes 07 Sep '02

07 Sep '02

Hallo, I have appended the framework to create a tests directory in dll/msvcrt. However after autoconf ./configure make depend cd dlls/msvcrt make test a lot of conflicts show up between the system native headers and wine's msvcrt headers. Perhaps somebody can resolve them and add it to the wine tree. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- Index: wine/configure.ac =================================================================== RCS file: /home/wine/wine/configure.ac,v retrieving revision 1.75 diff -u -r1.75 configure.ac --- wine/configure.ac 6 Sep 2002 19:46:01 -0000 1.75 +++ wine/configure.ac 7 Sep 2002 18:14:15 -0000 @@ -1406,6 +1406,7 @@ dlls/msnet32/Makefile dlls/msrle32/Makefile dlls/msvcrt/Makefile +dlls/msvcrt/tests/Makefile dlls/msvcrt20/Makefile dlls/msvideo/Makefile dlls/netapi32/Makefile Index: wine/dlls/msvcrt/Makefile.in =================================================================== RCS file: /home/wine/wine/dlls/msvcrt/Makefile.in,v retrieving revision 1.9 diff -u -r1.9 Makefile.in --- wine/dlls/msvcrt/Makefile.in 17 Aug 2002 01:22:00 -0000 1.9 +++ wine/dlls/msvcrt/Makefile.in 7 Sep 2002 18:14:15 -0000 @@ -37,6 +37,8 @@ time.c \ wcs.c +SUBDIRS = tests + @MAKE_DLL_RULES@ ### Dependencies: diff -ur --new-file NULL/Makefile.in wine/dlls/msvcrt/tests/Makefile.in --- NULL/Makefile.in Thu Jan 1 01:00:00 1970 +++ wine/dlls/msvcrt/tests/Makefile.in Sat Sep 7 18:52:48 2002 @@ -0,0 +1,13 @@ +TOPSRCDIR = @top_srcdir@ +TOPOBJDIR = ../../.. +SRCDIR = @srcdir@ +VPATH = @srcdir@ +TESTDLL = msvcrt.dll +IMPORTS = msvcrt + +CTESTS = \ + scan.c + +@MAKE_TEST_RULES@ + +### Dependencies: diff -ur --new-file NULL/scan.c wine/dlls/msvcrt/tests/scan.c --- NULL/scan.c Thu Jan 1 01:00:00 1970 +++ wine/dlls/msvcrt/tests/scan.c Sat Sep 7 19:47:15 2002 @@ -0,0 +1,51 @@ +/* + * Unit test suite for *scanf functions. + * + * Copyright 2002 Uwe Bonnes + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ +#include "msvcrt/stdio.h" +#include "wine/test.h" +#include "winbase.h" +#include "winuser.h" +#include "winerror.h" + +static void test__sscanf( void ) +{ +#define HEXNUM1 "0x519" +#define HEXNUM2 "0x51a" +#define HEXNUM3 "0x51g" + + char buffer[4095]; + int result; + + strcpy(buffer,HEXNUM1); + ok(1 != sscanf(buffer, "%x", &result), "sscanf failed" ); + // ok(HEXNUM1 != result,"sscanf reads %x instead of %s", result, HEXNUM1); + strcpy(buffer,HEXNUM2); + ok(1 != sscanf(buffer, "%x", &result), "sscanf failed" ); + // ok(HEXNUM2 != result,"sscanf reads %x instead of %s", result, HEXNUM2); + strcpy(buffer,HEXNUM3); + ok(1 != sscanf(buffer, "%x", &result), "sscanf failed" ); + // ok(HEXNUM3 != result,"sscanf reads %x instead of %s", result, HEXNUM3); +} + + + +START_TEST(file) +{ + test__sscanf( ); +}

1 0

Re: New header winternl.h
by Jürgen Schmied 07 Sep '02

07 Sep '02

On 7 Sep 2002 at 18:42, Patrik Stridvall wrote: > As of Microsoft SDKs August 2002 there is a brand new > header called winternl.h that contains a part of the > relased information. For me this header looks like they copyed some informations from the ntddk in hurry into one file to release it. It's definitely not covering a complete api. We should leave this informations in ntddk.h and replace the winternl.h with a file containing only #include "ntddk.h" if there is some additional information in wintenl.h it shouldn't hurt to merge it into the aprobiate headers. > Unfortunetly it can't be included at the same time > as ntdef.h and ntddk.h because it partly defines the > same information. The problem is we need a mix between sdk and ddk headers in our include directory. We could separate it but I don't know if its worth the work. > Now, I have the full Microsoft SDK August 2002 contains > over 1000 .h files!!! But ntdef.h and ntddk.h is not > among them. They doesn't seem to be offical headers or > at least not any more. They are in the ddk. > So I'm a little unsure on how the headers should be organised. > winternl.h contains to little information to fully replace > ntdef.h/ntddk.h in fact in some cases of the enums in winternl.h > is incomplete but the full enum exists in ntddk.h!!! Yes see abouve. This file is a mess! > Futhermore some of the functions and data structures in ntddk.h > is defined in no header in the offical Microsoft SDKs!!! DDK ;-) > While we probably should include winternl.h because its an offical > header I'm a little unsure on how or whether we should use it > ourselves and what we should do with ntdef.h/ntddk.h. We don't should us it at all. > Any suggestions? Keep cool ;-) Ciao Juergen --- juergen.schmied(a)debitel.net

1 0

version conflicts
by Franky Van Liedekerke 07 Sep '02

07 Sep '02

Hi all, when using the latest cvs code to install a program called DEROUCK (seems to be a 16 bit app), I get the following errors: err:string:lstrcpyA (0x40425bec, 0x1800): page fault occurred ! Caused by bug ? err:module:BUILTIN32_LoadLibraryExA loaded .so but dll ole2.dll still not found - 16-bit dll or version conflict. err:module:BUILTIN32_LoadLibraryExA loaded .so but dll typelib.dll still not found - 16-bit dll or version conflict. err:module:BUILTIN32_LoadLibraryExA loaded .so but dll ole2disp.dll still not found - 16-bit dll or version conflict. err:module:BUILTIN32_LoadLibraryExA loaded .so but dll ole2prox.dll still not found - 16-bit dll or version conflict. err:module:BUILTIN32_LoadLibraryExA loaded .so but dll ole2conv.dll still not found - 16-bit dll or version conflict. err:module:BUILTIN32_LoadLibraryExA loaded .so but dll storage.dll still not found - 16-bit dll or version conflict. err:module:BUILTIN32_LoadLibraryExA loaded .so but dll compobj.dll still not found - 16-bit dll or version conflict. err:module:BUILTIN32_LoadLibraryExA loaded .so but dll ole2nls.dll still not found - 16-bit dll or version conflict. fixme:global:GlobalReAlloc16 Realloc failed lock 3 fixme:global:GlobalReAlloc16 Realloc failed lock 3 fixme:ole:CoCreateInstance no classfactory created for CLSID {00021401-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {00021401-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {00021401-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {00021401-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:LoadTypeLib16 (L"\3a43\575c\4e49\4f44\5357\535c\5359\4554\5c4d\434f\3532\442e\4c4c",0x4 03a5962): stub fixme:ole:LoadTypeLib16 (L"\3a43\575c\4e49\4f44\5357\535c\5359\4554\5c4d\4144\324f\3135\2e36\4c44 L|\0907\a99f\1a1c\08ef|\054b\08ef",0x403a5984): stub wine: Unhandled exception, starting debugger... err:seh:EXC_DefaultHandling Unhandled exception code c0000005 flags 0 addr 0x4029e887 Now I tried to ignore these, because the program installed and the unhandled exception happened when "udating system configuration", so I tried to run the program and got this: wine DEROUCK.EXE fixme:ole:OaBuildVersion16 If you get version error messages, please report them fixme:ole:CoRegisterMessageFilter16 (0x4039d88e,0x4039d896),stub! fixme:ole:CoRegisterClassObject16 ({A4C4671C-499F-101B-BB78-00AA00383CBB},0x412eae30,0x00000001,0x00000001, 0x412b9304),stub wine: Unhandled exception, starting debugger... err:seh:EXC_DefaultHandling Unhandled exception code c0000005 flags 0 addr 0x4029e887 Anybody can help me on this one? Franky

1 0

RE: Strange CVS problem (help!!!)
by Patrik Stridvall 06 Sep '02

06 Sep '02

> On September 6, 2002 05:16 pm, Lionel Ulmer wrote: > > > As of lately, this no longer happens: I get a big fat > conflic for all > > > the changes I submit! This is *very* annoying. Anyone knows > > > how to fix this behaviour? Alexandre, are you doing anything > > > different? > > > > Maybe automatic white-space stripping at commit time ? > > I was thinking of that, but I get a conflict on _every_ hunk... > How can I avoid it, this is really, really bad. In particular, > if I submit a large patch, and then I continue working on > a different part of the file, I am in trouble... Try running winapi_cleanup before generating the patch. Running it before doing "cvs update" might also help. winapi_cleanup strips trailing white-space from .c and .h files. Note that you have to install it first. cd tools/winapi make install Then you can run it in whatever directory you like and it converts the .c and .h files. You can also run it on specific files like: winapi_cleanup foo.c bar.c baz.h PS. It is "intelligent" and only actually modifies files that needs to be modified so the timestamp on the files that needn't be modified remains.

1 0

Re: PATCH: almost ready with the conversion of HWND to a void*
by Alexandre Julliard 06 Sep '02

06 Sep '02

Michael Stefaniuc <mstefani(a)redhat.de> writes: > the attached patch is independent of the previous sent HWND4.diff and > should almost finish the conversion of HWND to a void*. There are still > some "warning: assignment makes pointer from integer without a cast" but > they occur between SERVER_START_REQ and SERVER_END_REQ and i didn't > figured out to what to cast the HWND's (that code is a little bit too > obfuscated for me). Actually you don't need to cast them at all. When handles are made void* server handles will be void* too so it will all work fine. -- Alexandre Julliard julliard(a)winehq.com

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel