Re: dlls/msvcrt: process.c (msvcrt-popen-1)
Jaco Greeff [EMAIL PROTECTED] writes: 1. Calling the popen function returns a FILE* which needs to be converted to a MSVCRT_FILE*. The apprach taken here is potentially not the best route but the only one I could think of. Is it suffiecient? No, it's wrong. You should be using the Windows API (CreateProcess etc.) not the Unix popen(). Then you can build a proper MSVCRT_FILE. -- Alexandre Julliard [EMAIL PROTECTED]
Re: dlls/msvcrt: process.c (msvcrt-popen-1)
On 01 Nov 2002 08:40:20 -0800, Alexandre Julliard [EMAIL PROTECTED] wrote : Jaco Greeff [EMAIL PROTECTED] writes: 1. Calling the popen function returns a FILE* which needs to be converted to a MSVCRT_FILE*. The apprach taken here is potentially not the best route but the only one I could think of. Is it suffiecient? No, it's wrong. You should be using the Windows API (CreateProcess etc.) not the Unix popen(). Then you can build a proper MSVCRT_FILE. I was actually taking a re-look at that this afternoon. I agree, the initial reason for th implementation was obviously that _popen is supposed to mimic popen, but the file conversion leaves me feeling really uncomfortable. I'll fix it up and submit it shortly. Greetings, Jaco
Re: dlls/msvcrt: process.c (msvcrt-popen-1)
On 01 Nov 2002 08:40:20 -0800, Alexandre Julliard [EMAIL PROTECTED] wrote :
No, it's wrong. You should be using the Windows API (CreateProcess
etc.) not the Unix popen(). Then you can build a proper MSVCRT_FILE.
Sorry, I had a few beers tonight ;) Ok, I just remembered what my concerns
were about using CreateProcess initially when I looked at MSDN:
CreateProcess executes a Windows executable with parameters, whereas _popen
executes as shell, ie. you can do stuff like _popen(dir/w) which will
return an open file in which you can read the directory contents from. In
essence under Windows, this gets executed at cmd.exe /C dir/w.
Now using CreatePorcess we can potentially do the same, provided that the
executable (command interpreter) resides in your path. From MSDN:
The string can specify the full path and file name of the module to execute
or it can specify a partial name. In the case of a partial name, the
function uses the current drive and current directory to complete the
specification.
Now wera are faced with a problem in that wcmd is not a pure Windows
application and it doesn't reside in your Windows filesystem, rather it is
in your *nix path.
In the case of _popen, a file-handle is returned which allows you to either
read or write to the application unsing the normal fwrite/fprintf/etc.
commands. CreateProcess has an information structure containing the
following information:
typedef struct _PROCESS_INFORMATION {
HANDLE hProcess;
HANDLE hThread;
DWORD dwProcessId;
DWORD dwThreadId;
} PROCESS_INFORMATION;
I don't see any clear way of doing,
1. Converting the above structure into something usable, eg. MSVCRT_FILE
2. Actually allowing us to read or write to the application
Potentially the magic lies in the current Wine CreateProcess implementation,
I'll have a look at it. Is doing this really feasable using the
CreateProcess family? In essence a HANDLE will map back to an fd with the
wine implementation (rather we can get an fd for a HANDLE), but can this be
used to read/write to the process? The first obstacle however, will be in
having a clean way to get wcmd going if it doesn't reside in C:\. Maybe it
should be there and should be installed like notepad.exe for example?
Some questions, and yes I'm slow tonight... :) I think that just by typing
this some concerns have been aleviated so excuse my rumblings but just check
the logic.
Greetings,
Jaco
Re: dlls/msvcrt: process.c (msvcrt-popen-1)
On 1 Nov 2002, Jaco Greeff wrote: [...] Now wera are faced with a problem in that wcmd is not a pure Windows application and it doesn't reside in your Windows filesystem, rather it is in your *nix path. Try c:\Windows\System\wcmd.exe and I think you will find that it works. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...
Re: dlls/msvcrt: process.c (msvcrt-popen-1)
On Fri, 1 Nov 2002 11:21:26 -0800 (PST), Francois Gouget [EMAIL PROTECTED] wrote : Try c:\Windows\System\wcmd.exe and I think you will find that it works. *lol* Like I've said, expect me to be slow tonight :)
Re: dlls/msvcrt: process.c (msvcrt-popen-1)
Francois == Francois Gouget [EMAIL PROTECTED] writes: Francois On 1 Nov 2002, Jaco Greeff wrote: [...] Now wera are faced with a problem in that wcmd is not a pure Windows application and it doesn't reside in your Windows filesystem, rather it is in your *nix path. Francois Try c:\Windows\System\wcmd.exe and I think you will find that Francois it works. Giving a fully qualified patch is probably bad advice here. Try wcmd.exe only and have cmd.exe.so in wine's program directory. Wine sets on startup WINEDLLPATH to $topdir/dlls:$topdir/programs and wineapploader there should manage to start the application. Probably Alexandre knows more. Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: dlls/msvcrt: process.c (msvcrt-popen-1)
On Fri, 1 Nov 2002, Uwe Bonnes wrote: [...] Giving a fully qualified patch is probably bad advice here. Try wcmd.exe only and have cmd.exe.so in wine's program directory. Actually, using COMSPEC or something like that might be even better. The exact behavior has to be checked on Windows though. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ We are Pentium of Borg. You will be approximated. Division is futile.
Re: dlls/msvcrt: process.c (msvcrt-popen-1)
On Fri, 1 Nov 2002 20:50:07 +0100, Uwe Bonnes [EMAIL PROTECTED] wrote : Giving a fully qualified patch is probably bad advice here. Try wcmd.exe only and have cmd.exe.so in wine's program directory. Wine sets on startup WINEDLLPATH to $topdir/dlls:$topdir/programs and wineapploader there should manage to start the application. Umm, that might help a bit. When I get to the point of testing again, I'll give it a bash. What seems to be the concensus as to the right-way-to-do-things(tm) in this case? Greetings, Jaco
Re: dlls/msvcrt: process.c (msvcrt-popen-1)
On November 1, 2002 02:50 pm, Uwe Bonnes wrote: Probably Alexandre knows more. Well, yeah, he always does! :) -- Dimi.
Re: dlls/msvcrt: process.c (msvcrt-popen-1)
Quoting John K. Hohm [EMAIL PROTECTED]: No, it's wrong. You should be using the Windows API (CreateProcess etc.) not the Unix popen(). Then you can build a proper MSVCRT_FILE. Sorry, I had a few beers tonight ;) Ok, I just remembered what my concerns were about using CreateProcess initially when I looked at MSDN: I think you need to look more closely at the LPSTARTUPINFO lpStartupInfo argument to CreateProcess. It points to a STARTUPINFO structure having HANDLE hStdInput, HANDLE hStdOutput, and HANDLE hStdError members, which are used if the dwFlags member has the STARTF_USESTDHANDLES bit set. I'm a little wonky today too, I sent it to pudexo.org first. :-/
