Hello Jason,
I'm just curious: xcopy.exe is an external program in Windows, but you want to make it a builtin command in Wine?
Regards Alex
-----Original Message----- [mailto:wine-patches-bounces@winehq.org] On Behalf Of ext Ann & Jason Edmeades
If I now run "wine xcopy", then it works (and gives a basic error for now), but it I run "wine cmd", then "xcopy" I get file not found. As far as I can tell, cmd will only search the path for such a program and fails to find it.
Should I add it to the fake dlls, which I think would cause a file to be created in system32, or how should cmd handle this situation as xcopy.exe.so isn't available on the path.
I'm just curious: xcopy.exe is an external program in Windows, but you want to make it a builtin command in Wine?
No, its already committed in the tree already as an external program (programs\xcopy).
The installer I was fiddling with which caused me to write xcopy actually uses (effectively) "cmd.exe /c xcopy....". The fact I cant run a wine supplied program from within another portion of wine was what concerned me. I was trying to understand how wine locates it, given that CreateProcess doesnt find it (nor SearchPath).
IF the answer is that we need fake dlls, we probably need to ensure we do it for any exe from the wine 'programs' branch.
Jason
Jason Edmeades us@edmeades.me.uk writes:
The installer I was fiddling with which caused me to write xcopy actually uses (effectively) "cmd.exe /c xcopy....". The fact I cant run a wine supplied program from within another portion of wine was what concerned me. I was trying to understand how wine locates it, given that CreateProcess doesnt find it (nor SearchPath).
IF the answer is that we need fake dlls, we probably need to ensure we do it for any exe from the wine 'programs' branch.
No, cmd.exe should be fixed to be able to run a builtin exe even if the file is not found in the path. CreateProcess is able to do that already, so it's probably just a matter of not bailing out when SearchPath fails.
The installer I was fiddling with which caused me to write xcopy actually uses (effectively) "cmd.exe /c xcopy....". The fact I cant run a wine supplied program from within another portion of wine was what concerned me. I was trying to understand how wine locates it, given that CreateProcess doesnt find it (nor SearchPath).
IF the answer is that we need fake dlls, we probably need to ensure we do it for any exe from the wine 'programs' branch.
No, cmd.exe should be fixed to be able to run a builtin exe even if the file is not found in the path. CreateProcess is able to do that already, so it's probably just a matter of not bailing out when SearchPath fails.
Unfortunately I need to know if it's a console app or not, and hence call FindExecutable followed by SHGetFileInfo. These don't seem to report anything on the internal programs so I couldn't tell whether to wait for it to complete (eg xcopy) or let it run (eg notepad).
I'm patching it to assume worse case (run it synchronous) and just wait, unless you have any other suggestions, working on the theory this is a very rare case.
Jason
"Ann & Jason Edmeades" us@edmeades.me.uk writes:
Unfortunately I need to know if it's a console app or not, and hence call FindExecutable followed by SHGetFileInfo. These don't seem to report anything on the internal programs so I couldn't tell whether to wait for it to complete (eg xcopy) or let it run (eg notepad).
I'm patching it to assume worse case (run it synchronous) and just wait, unless you have any other suggestions, working on the theory this is a very rare case.
We could certainly fix SHGetFileInfo to do the right thing for builtins, using the same method we use for GetFileVersionInfo.