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?
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
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.
Duane Clark dclark@akamail.com 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 wrote:
Duane Clark dclark@akamail.com 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.
Duane Clark dclark@akamail.com 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 a écrit :
Duane Clark dclark@akamail.com 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+
-
Alexandre Julliard -
Duane Clark -
Eric Pouech -
Steven Edwards