wine-devel

wine-devel@winehq.org

10 participants
84459 discussions

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

Patch: winemaker-options
by Martin Wilck 06 Sep '02

06 Sep '02

This patch fixes winemaker's annoying habit to insist on --mfc even if --nomfc was specified, and adds an option to not add any DLLs automatically. Patch: winemaker-options.diff Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> Modified files: tools: winemaker - fix --nomfc option which is currrently broken - add --nodlls option for small apps This patch is incremental over Francois Gouget's latest winemaker patch: http://www.winehq.com/hypermail/wine-patches/2002/09/0028.html and my previous patch (winemaker-bugs.diff) --- CVS/wine/tools/winemaker Fri Sep 6 17:35:39 2002 +++ TMP/wine/tools/winemaker Fri Sep 6 17:36:46 2002 @@ -234,6 +234,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. @@ -436,23 +444,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; } @@ -543,7 +565,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 { @@ -553,7 +575,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) { @@ -779,7 +801,11 @@ # 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; + 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 @@ -2169,7 +2195,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"; @@ -2182,9 +2208,6 @@ exit (2); } - -project_init(\@main_project,""); - while (@ARGV>0) { my $arg=shift @ARGV; # General options @@ -2245,11 +2268,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 { @@ -2264,6 +2289,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) { @@ -2279,6 +2309,8 @@ print_banner(); } +project_init(\@main_project,""); + # Fix the file and directory names fix_file_and_directory_names("."); -- 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

1 0

Winelib apps containing upper case letters don't run
by Martin Wilck 06 Sep '02

06 Sep '02

The patch below fixes a problem introduced August 14 (process.c 1.196): Names of "builtin" apps (into which category fall also Winelib apps) aren't found if they aren't lowercase-only. Explanation: Create a directory "Test" and there a file foo.cpp like this: #include <iostream.h> int main (void) { cout << "Hello world!" <<endl; return 0; } In the "Test" directory, run $ winemaker --cuiexe .; ./configure; make; ./Test => error. This fails because the "Test" shell script (aka "wineloader") calls "wine Test.exe", and this ends up searching "test.exe.so" in the DLL path. My patch below fixes that, but I'm not sure if it is the right thing to do. Perhaps wineloader should simply look for "Test.exe.so" rather than for "Test.exe". This is only one of several problems I have with the current winelib/winemaker. Martin Patch: process.diff Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> scheduler: process.c open_builtin_exe_file(): Allow running Winelib apps whose names contain upper case letters. Index: scheduler/process.c =================================================================== RCS file: /home/wine/wine/scheduler/process.c,v retrieving revision 1.198 diff -u -r1.198 process.c --- scheduler/process.c 27 Aug 2002 01:13:59 -0000 1.198 +++ scheduler/process.c 6 Sep 2002 12:05:17 -0000 @@ -265,11 +265,15 @@ { char exename[MAX_PATH], *p; const char *basename = get_basename(name); + void *dll = NULL; if (strlen(basename) >= sizeof(exename)) return NULL; strcpy( exename, basename ); for (p = exename; *p; p++) *p = FILE_tolower(*p); - return wine_dll_load_main_exe( exename, error, error_size, test_only ); + dll = wine_dll_load_main_exe( exename, error, error_size, test_only ); + if (!dll) + dll = wine_dll_load_main_exe( basename, error, error_size, test_only ); + return dll; } -- 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

1 0

Re: Comctrl generic notification support
by Andreas Mohr 06 Sep '02

06 Sep '02

Hi, On Thu, Sep 05, 2002 at 01:54:50PM -0400, Dimitrie O. Paun wrote: > ChangeLog > Add generic notification support to comctl32 > > Index: dlls/comctl32/comctl32.h > =================================================================== > RCS file: /var/cvs/wine/dlls/comctl32/comctl32.h,v > retrieving revision 1.16 > diff -u -r1.16 comctl32.h > --- dlls/comctl32/comctl32.h 31 May 2002 23:25:43 -0000 1.16 > +++ dlls/comctl32/comctl32.h 5 Sep 2002 17:33:49 -0000 > @@ -4,6 +4,7 @@ > * > * Copyright 1999 Thuy Nguyen > * Copyright 1999 Eric Kohl > + * Copyright 2002 Dimitrie O. Paun > * > * This library is free software; you can redistribute it and/or > * modify it under the terms of the GNU Lesser General Public > @@ -23,6 +24,8 @@ > #ifndef __WINE_COMCTL32_H > #define __WINE_COMCTL32_H > > +#include "commctrl.h" > + > extern HMODULE COMCTL32_hModule; > extern HBRUSH COMCTL32_hPattern55AABrush; > > @@ -125,4 +128,132 @@ > #define WINE_FILEVERSION 5, COMCTL32_VERSION_MINOR, 0, 0 > #define WINE_FILEVERSIONSTR "5.00" > > +/* Notification support */ > + > +inline static LRESULT __send_notify(HWND hwnd, UINT code, NMHDR *hdr) Isn't using double underscore for such non-system functions rather pretty weird ? (or IOW: even strongly discouraged ?) -- Microsoft Licensing 6.0: "Pay us now in advance, so that we can own you later."

4 3

Re: Atom test fix
by Dmitry Timoshkov 05 Sep '02

05 Sep '02

"Francois Gouget" <fgouget(a)free.fr> wrote: > Conformance tests must not use Wine-specific headers (like > wine/unicode.h) otherwise they will not compile on Windows. > > wine/test.h is the only exception. > > Changelog: > > * dlls/kernel/tests/atom.c > > Do not include wine/unicode.h > Duplicate strlenW I would suggest to simply replace it by lstrlenW, instead of duplicating code. -- Dmitry.

1 0

Re: VersionNumber reg. key
by Jeff Smith 05 Sep '02

05 Sep '02

My $0.02: I say don't create, and dynamically 'lie' about it's value. I'm sure it's easier said than done, but that's my thoughts, anyway. -- Jeff S >From: Ender <winedev(a)admdev.com> >To: wine-devel(a)winehq.com >Subject: VersionNumber reg. key >Date: Wed, 4 Sep 2002 21:28:32 -0500 (CDT) >read the HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\VersionNumber >key. And of course, as this is a 'required' key in Windows, there was no >code to cope with failure :) >whether or not Wine should dynamically 'lie' about this registry key, >depending what winver the current thread is running in. > - Ender _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com

3 2

[Bug 448] - need help debugging 16-32-bit parameter passing
by Martin Wilck 05 Sep '02

05 Sep '02

Included below are my latest results for Bug 448. The problem there is that winsock connects to port 512 although a service at port 5557 was specified. The winsock functions seem to work correctly: -> getservbyname16 returns port 0x15b5 = 5557 -> connect16 receives port 512 (!) directly after that. (the only thing that happens in between is a socket() call). The interesting part is that 512 in network byte order is 0x0002, i.e. the same as the protocol family (0x0002=AF_INET). Is it possible that something gets overwritten here when connect() is called? My problem is that I have no clue hall the magic relaying between 16 and 32 bit code in wine works. Perhaps someone can give me a hint? Martin ------- Additional Comments From martin.wilck(a)fujitsu-siemens.com 2002-09-05 07:58 ------- I finally got some time to look into this. It does not seem to be a winsock error. By inserting some TRACES, I can clearly see that getservbyname() correctly returns port 5557 (hex 0x15b5): trace:winsock:WINSOCK_getservbyname16 "ctsql", "tcp" trace:winsock:__ws_getservbyname name ctsql proto tcp flag 2 i 6 trace:winsock:WS_dup_se s_name ctsql s_port 15b5 s_proto tcp trace:winsock:WS_dup_se 16 s_port 15b5 trace:winsock:__ws_getservbyname s_name ctsql s_port 15b5 s_proto tcp [ ... ] But when "connect" is called, it is passed port 512 (hex 0200): trace:winsock:WINSOCK_connect16 socket 0048, ptr 0x40c493d6, length 16 sockaddr_in: family 2, address 172.25.186.5, port 512 02 00 02 00 ac 19 ba 05 00 00 00 00 00 00 00 00 Interestingly, (since the port is in network byte order) the hex patterns for address family and port are both 0x0002. This looks as if either - the app is assigning the family to the port number (?) (This would mean that the shouldn't be able to run on Windows either, since you say all was fine in 20011108, there must be another reason) - something goes wrong when the argument is passed from the 16- to 32bit layer. Have to look further. -- 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

1 0

Trying to debug Paradise Poker client
by Per Nystrom 05 Sep '02

05 Sep '02

Hi, I filed bug 1007 (kernel32.dll.Heap32* functions unimplemented) on this, but I'm not even sure that's the real problem. One thing that I'm seeing is retval=00000000 (FALSE) from all the calls to advapi32.CryptAcquireContextA() -- since this application relies *heavily* on encryption, I wonder if this is a good place to start. If I run it with the advapi32 dll overridden to use native, I get a different error and the App seems to crash even earlier in its execution. The following is what I got using the native advapi32 dll: fixme:file:VxDCall_VMM Unknown service 00010029 08070158:Ret kernel32.VxDCall4() retval=ffffffff ret=bfe81d8d fs=008f eax=ffffffff ebx=00000000 ecx=4011faa8 edx=405c6a00 esi=00000064 edi=00000001 ebp=405c6d5c esp=405c6d40 ds=002b es=002b gs=0ac7 flags=00000202 08070158:Call kernel32.CreateEventA(00000005,00000064,00000001,71467c2a "\205\300u\020h\024$EqSj\001S\377\327\243LPJqU\350\304\262\377\377;\363t\007V\377\025<\022Eq_^][\303\203=LPJq") ret=00000001 err:win32:CreateEventW Bad security attributes pointer 0x5 08070158:Ret kernel32.CreateEventA() retval=00000000 ret=00000001 wine: Unhandled exception, starting debugger... I'm attaching the entire relay trace (compressed) from running with the builtin advapi32 dll; it's much larger but probably more useful for fixing the problem. Any help is greatly appreciated! Per Nystrom System specifics: wine was built from the very latest in the CVS repository as of tonight Pentium II, 128Mb RAM and 1+ Gb swap running Red Hat 7.1 with updated X (4.2.0) glibc-2.2.4-29 gcc-2.96-81 -- "When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl."

2 1

Re: [PATCH] winsock-test.diff
by Alexandre Julliard 05 Sep '02

05 Sep '02

Martin Wilck <Martin.Wilck(a)Fujitsu-Siemens.com> writes: > Rationale: > - Make it easier to add new unit tests. > - Conform better to the usual wine unit testing scheme > (instead of running different tests from the same file, > run separate files testing different functionality) That's not really the usual scheme. It may look that way because we have few tests at the moment, but we can't put each test in a separate file, or we will end up with thousands of them. The right approach is to follow more or less the layout of the source files, that is if two APIs are implemented in the same source file they should be tested in the same test file; so I think the current winsock tests are OK as they are. And in any case #including .c files is strongly discouraged. -- Alexandre Julliard julliard(a)winehq.com

2 1

Tab Controls without name
by Fabian Cenedese 05 Sep '02

05 Sep '02

Hi I found something that would be easy to fix in case it really should be fixed. Working with tab controls I have the case where I set the tab name to empty because it's too big to be shown. In the TCITEM structure I set the text pointer to NULL instead of a "". Thus Wine stopped at some point doing a strlen on a NULL pointer. Obvious. Then I checked MSDN if this is allowed or not. It always says string pointer, never is a NULL pointer a possible value. Ok, so my code is wrong, easy to change. But still (the often cited sentence): It used to work in Windows. So now I don't know if Wine should be clean (and NULL pointer in tab name is not allowed) or if it should behave as Windows (no matter what docs say) and a NULL pointer is just an empty name... bye Fabi

2 2

VersionNumber reg. key
by Ender 05 Sep '02

05 Sep '02

Hi all, A few weeks ago I was setting up a fake-windows install, and ran across a few pieces of software that just crashed.. like the Visual Studio installer. After a little bit of investigation, I discovered these were trying to read the HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\VersionNumber key. And of course, as this is a 'required' key in Windows, there was no code to cope with failure :) At the very least this should be added to the default registry with a dummy value (oh yeah, values are like: "4.90.3000"). But my question is whether or not Wine should dynamically 'lie' about this registry key, depending what winver the current thread is running in. Thoughts? - Ender

1 0

Re: Partial implementation of NotifyRegister notifications
by Alexandre Julliard 05 Sep '02

05 Sep '02

Joshua Thielen <thielen(a)netprince.net> writes: > I expect there to be problems with this patch (some of it is probably > a bit over my head) so eyes are requested, please! I already know that > the number and order of the segment messages (NFY_LOADSEG and FREESEG) > doesn't exactly match those sent in Windows, and I'm not totally sure > of the affect this patch will have on 16-bit memory and threading > details in wine. You should really have some kind of TOOLHELP_SendNotification function instead of calling wine_call_to_16_regs all over the place. Also the handling of segmented pointers (especially the lpstrModuleName) doesn't look right. Apart from that, it looks quite reasonable. -- Alexandre Julliard julliard(a)winehq.com

1 0

Catching MFC exception
by Fabian Cenedese 04 Sep '02

04 Sep '02

Hi I found one of the wrong behaviours though I don't know where to solve it. For creating an ocx one can give a window title. I gave a "" to the CreateControl function. But this poses a problem to MFC, it's only prepared for valid strings or NULL pointers. That's why it generates the exception: void AFXAPI AfxThrowOleException(SCODE sc){ #ifdef _DEBUG TRACE1("Warning: constructing COleException, scode = %s.\n", AfxGetFullScodeString(sc)); #endif COleException* pException = new COleException; pException->m_sc = sc; THROW(pException); } In Windows this is caught by another function in MFC and doesn't do any harm: BOOL AFX_CDECL COleControlSite::SafeSetProperty(DISPID dwDispID, VARTYPE vtProp, ...) { va_list argList; // really only one arg, but... va_start(argList, vtProp); BOOL bSuccess; TRY { SetPropertyV(dwDispID, vtProp, argList); bSuccess = TRUE; } CATCH_ALL(e) { DELETE_EXCEPTION(e); bSuccess = FALSE; } END_CATCH_ALL va_end(argList); return bSuccess; } Now it seems that the exception handling inside (or wherever) the MFC.dll doesn't work if running in Wine or the MFC exceptions are different and the exception comes right through. I can overcome this problem by giving a valid window title but that solves it only for me. I have no idea how and if this can be solved but maybe this description gives a hint to a programmer with more insight. Thanks Fabi

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