September 2002 - Wine-Devel

Re: May we use winelib-wcmd as $COMSPEC command processor?

by Alexandre Julliard

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > It works with a winelib executable, when COMSPEC points to the real file. As > our present built system creates .exe.so files, comspec must specify this > existing .exe.so file (or the .exe.so file must be renamed to an .exe > file). Just as a reference for others... You shouldn't need to rename the file or point to the .exe.so. Unless you have changed the loadorder, a .exe loaded from the system directory should match the .exe.so, just like it does for dlls even if the file itself doesn't exist. So a CreateProcess of %systemdir%\wcmd.exe should launch wcmd.exe.so, just like a LoadLibrary of %systemdir%\user32.dll will load user32.dll.so, even if you don't have a real user32.dll file in there. If it doesn't do this there's a bug somewhere. -- Alexandre Julliard julliard(a)winehq.com

Sept. 8, 2002

Re: May we use winelib-wcmd as $COMSPEC command processor?

by Uwe Bonnes

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes: Alexandre> Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: >> > echo $COMSPEC wcmd.exe (I added an echo command to winewrapper) >> WINEDLLPATH >> /home/bon/tmp/wine/compile/wine/dlls:/home/bon/tmp/wine/compile/wine/programs >> >> 088fccb8:Call kernel32.CreateProcessA(40c8248f "wcmd.exe",40c87f04 >> "wcmd.exe /c I:\\xilinx\\bin\\nt\\ChipView.bat -f magcom >> .vm6",405c6c3c,405c6c3c,00000001,00000000,00000000,00000000,405c6bf8,405c6be8) Alexandre> The app is passing COMSPEC as application name to Alexandre> CreateProcess, so my suggestion won't work, you have to make Alexandre> COMSPEC a full path. Setting it to Alexandre> "c:\windows\system\wcmd.exe" should work. It works with a winelib executable, when COMSPEC points to the real file. As our present built system creates .exe.so files, comspec must specify this existing .exe.so file (or the .exe.so file must be renamed to an .exe file). Just as a reference for others... Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Sept. 8, 2002

Re: May we use winelib-wcmd as $COMSPEC command processor?

by Alexandre Julliard

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > > echo $COMSPEC > wcmd.exe > (I added an echo command to winewrapper) > WINEDLLPATH > /home/bon/tmp/wine/compile/wine/dlls:/home/bon/tmp/wine/compile/wine/programs > > 088fccb8:Call kernel32.CreateProcessA(40c8248f "wcmd.exe",40c87f04 "wcmd.exe > /c I:\\xilinx\\bin\\nt\\ChipView.bat -f magcom > .vm6",405c6c3c,405c6c3c,00000001,00000000,00000000,00000000,405c6bf8,405c6be8) The app is passing COMSPEC as application name to CreateProcess, so my suggestion won't work, you have to make COMSPEC a full path. Setting it to "c:\windows\system\wcmd.exe" should work. -- Alexandre Julliard julliard(a)winehq.com

Sept. 8, 2002

Re: New header winternl.h

by Alexandre Julliard

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. 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. -- Alexandre Julliard julliard(a)winehq.com

Sept. 8, 2002

Re: May we use winelib-wcmd as $COMSPEC command processor?

by Uwe Bonnes

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes: Alexandre> Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: >> 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",... Alexandre> If you simply set COMSPEC to "wcmd.exe" it should work I Alexandre> think (assuming wcmd.exe.so is in your WINEDLLPATH of Alexandre> course). Probably I forget something, but it doesn't work for me: > echo $COMSPEC wcmd.exe (I added an echo command to winewrapper) WINEDLLPATH /home/bon/tmp/wine/compile/wine/dlls:/home/bon/tmp/wine/compile/wine/programs 088fccb8:Call kernel32.CreateProcessA(40c8248f "wcmd.exe",40c87f04 "wcmd.exe /c I:\\xilinx\\bin\\nt\\ChipView.bat -f magcom .vm6",405c6c3c,405c6c3c,00000001,00000000,00000000,00000000,405c6bf8,405c6be8) ret=405feddd trace:dosfs:DOSFS_GetFullName L"wcmd.exe" (last=1) trace:dosfs:DOSFS_FindUnixName /home/bon/work/projekte/elab/magcomp,L"wcmd.exe" trace:dosfs:DOSFS_OpenDir "/home/bon/work/projekte/elab/magcomp" warn:dosfs:DOSFS_FindUnixName L"wcmd.exe" not found in '/home/bon/work/projekte/elab/magcomp' 088fccb8:Ret kernel32.CreateProcessA() retval=00000000 ret=405feddd > ls -l /home/bon/tmp/wine/compile/wine/programs/wcmd.exe.so lrwxrwxrwx 1 bon users 16 Sep 8 01:58 /home/bon/tmp/wine/compile/wine/programs/wcmd.exe.so -> wcmd/wcmd.exe.so Any hints? -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Sept. 8, 2002

RE: New header winternl.h

by Patrik Stridvall

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

Sept. 8, 2002

RE: New header winternl.h

by Francois Gouget

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. 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. 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). -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ A particle is an irreducible representation of the Poincaré Group - Eugene Wigner

Sept. 8, 2002

RE: New header winternl.h

by Jürgen Schmied

> 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. juergen --- juergen.schmied(a)debitel.net

Sept. 8, 2002

RE: TBS_DOWNISLEFT

by Patrik Stridvall

> 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

Sept. 8, 2002

Re: TBS_DOWNISLEFT

by Francois Gouget

On Sun, 8 Sep 2002, Dimitrie O. Paun wrote: > Can someone with a recent SDK tell me the value of TBS_DOWNISLEFT, > defined in commctrl.h? Value is 0x0400 -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY

Sept. 8, 2002