September 2002 - Wine-Devel

RE: New header winternl.h
by Patrik Stridvall Sept. 9, 2002

Sept. 9, 2002

> 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 Sept. 8, 2002

Sept. 8, 2002

* 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 Sept. 8, 2002

Sept. 8, 2002

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 Sept. 8, 2002

Sept. 8, 2002

> 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 Sept. 8, 2002

Sept. 8, 2002

> 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 Sept. 8, 2002

Sept. 8, 2002

> 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 Sept. 8, 2002

Sept. 8, 2002

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 Sept. 7, 2002

Sept. 7, 2002

--- 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 Sept. 7, 2002

Sept. 7, 2002

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 + +(a)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 Sept. 7, 2002

Sept. 7, 2002

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