Re: ShellExecute patch
Alexandre Julliard a écrit : > > Duane Clark <[EMAIL PROTECTED]> writes: > > > One of several problems I see in my patch (obviously I should have > > slept on it before submitting) was that it would not return hProcess > > when requested. Getting that info appears to me to require an explicit > > call to CreateProcess, rather than using WinExec. > > True, it does; OTOH returning a valid instance from ShellExecute16 > requires a WinExec... another possible solution is to simply implement > a completely separate ShellExecute16 by copying the relevant parts of > the code. another solution is to pass a function pointer to the internal implementation of ShellExecuteEx this fn pointer would be: - when called from SEExA & SEExW, a local function based on CreateProcess to return a real handle - when called from SE16, another local function based on WinExec16 this would allow to keep all 16 bit stuff in one file, and to compile it out if necessary (mingw for example) A+
Re: ShellExecute patch
Duane Clark <[EMAIL PROTECTED]> writes: > One of several problems I see in my patch (obviously I should have > slept on it before submitting) was that it would not return hProcess > when requested. Getting that info appears to me to require an explicit > call to CreateProcess, rather than using WinExec. True, it does; OTOH returning a valid instance from ShellExecute16 requires a WinExec... another possible solution is to simply implement a completely separate ShellExecute16 by copying the relevant parts of the code. -- Alexandre Julliard [EMAIL PROTECTED]
Re: ShellExecute patch
Alexandre Julliard wrote: > Duane Clark <[EMAIL PROTECTED]> writes: > > >>I would use #ifndef NO_WIN16. Would that be acceptable for CVS? I need >>to fix an obvious bug, so I think I will just make the change to call >>CreateProcessA and put in the ifndefs and see what happens. > > > I don't think a #ifdef is appropriate. What I would suggest is to > always call WinExec, and change WinExec to behave like WinExec16 when > called from a 16-bit app. One of several problems I see in my patch (obviously I should have slept on it before submitting) was that it would not return hProcess when requested. Getting that info appears to me to require an explicit call to CreateProcess, rather than using WinExec.
Re: ShellExecute patch
Duane Clark <[EMAIL PROTECTED]> writes: > I would use #ifndef NO_WIN16. Would that be acceptable for CVS? I need > to fix an obvious bug, so I think I will just make the change to call > CreateProcessA and put in the ifndefs and see what happens. I don't think a #ifdef is appropriate. What I would suggest is to always call WinExec, and change WinExec to behave like WinExec16 when called from a 16-bit app. -- Alexandre Julliard [EMAIL PROTECTED]
Re: ShellExecute patch
Steven Edwards wrote: > > Sounds cool but it really depends on if Alexandre will accept the > patch or not. At some point I will be add the configure option > --no-win16 so just doing a #ifdef NO_WIN16 should be fine. Building > on mingw already requires not including shell.c so I need to make the > Makefile and configure changes anyway. Its not that important ATM so > if it will be a problem we can wait till more ReactOS developers are > interested in fixing it. I would use #ifndef NO_WIN16. Would that be acceptable for CVS? I need to fix an obvious bug, so I think I will just make the change to call CreateProcessA and put in the ifndefs and see what happens.
Re: ShellExecute patch
> Hmm, the WinExec looks fairly easy but the WinExec16 appears to be a bit > more difficult to handle. Perhaps it could be handled more easily with > some sort of ifdef around those parts? Any suggestions? Sounds cool but it really depends on if Alexandre will accept the patch or not. At some point I will be add the configure option --no-win16 so just doing a #ifdef NO_WIN16 should be fine. Building on mingw already requires not including shell.c so I need to make the Makefile and configure changes anyway. Its not that important ATM so if it will be a problem we can wait till more ReactOS developers are interested in fixing it. Thanks Steven __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
Re: ShellExecute patch
Steven Edwards wrote: >> I guess I am not sure what the problem is with WinExec. Originally >> ShellExecuteEx used CreateProcessA and ShellExecute used WinExec, >> which simply calls CreateProcessA. I could certainly directly call >> CreateProcessA if that is preferable. > > > Yes, I tried to do that once before but could not get it to work > quite right as I am still learning how to program. Mingw cant import > from the Win16 api so CreateProcess needs to be used if we want to > have shell32 for testing under mingw or use under ReactOS. Hmm, the WinExec looks fairly easy but the WinExec16 appears to be a bit more difficult to handle. Perhaps it could be handled more easily with some sort of ifdef around those parts? Any suggestions?
Re: shellexecute patch
On Thu, Feb 14, 2002 at 07:40:54PM +0100, Rein Klazes wrote:
> On Thu, 14 Feb 2002 19:14:28 +0100, you wrote:
> > But I might be wrong and your patch is completely independent of mine.
>
> I think so. The patch is just preventing that ShellExecuteA( ...,
> "K:\\setup.exe","option",...) will cause a call to
> WinExec16("K:\\setup.exeoption") that fails for a "file not found"
> error.
Hmm, thinking more about it (hmm, should have done that before :),
I guess you're absolutely and completely 100% right.
I really don't want to know how many installers failed due to this problem...
(I'm certainly remembering several cases that almost cry for correlation
to this fix...)
--
Andreas MohrStauferstr. 6, D-71272 Renningen, Germany
Tel. +49 7159 800604http://home.nexgo.de/andi.mohr/
Re: shellexecute patch
On Thu, 14 Feb 2002 19:14:28 +0100, you wrote:
> On Thu, Feb 14, 2002 at 11:57:55AM +0100, Rein Klazes wrote:
> >
> > Needed for Visual Studio.NET installer.
> >
> > Changelog:
> >
> > dlls/shell32: shell.c
> > In ShellExecute16, make sure there is a space between command
> > and parameters.
> Hmm, I suspect that might be wrong.
> (in case your ShellExecute16() is being called by ShellExecute(), that is)
>
> ShellExecute() was supposed to call WinExec() instead of WinExec16()
> (long filename support).
>
> I wrote a ShellExecute patch some weeks ago that didn't get applied,
> probably because there were compile warnings.
>
> But I might be wrong and your patch is completely independent of mine.
I think so. The patch is just preventing that ShellExecuteA( ...,
"K:\\setup.exe","option",...) will cause a call to
WinExec16("K:\\setup.exeoption") that fails for a "file not found"
error.
Rein.
--
Rein Klazes
[EMAIL PROTECTED]
Re: shellexecute patch
On Thu, Feb 14, 2002 at 11:57:55AM +0100, Rein Klazes wrote: > > Needed for Visual Studio.NET installer. > > Changelog: > > dlls/shell32: shell.c > In ShellExecute16, make sure there is a space between command > and parameters. Hmm, I suspect that might be wrong. (in case your ShellExecute16() is being called by ShellExecute(), that is) ShellExecute() was supposed to call WinExec() instead of WinExec16() (long filename support). I wrote a ShellExecute patch some weeks ago that didn't get applied, probably because there were compile warnings. But I might be wrong and your patch is completely independent of mine. -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://home.nexgo.de/andi.mohr/
