> However, this function uses CreateProcess automatically in Win32's. I think "only for compatibility" does not mean that function is 'obsolete', because I have seen many places where this function still used. From my knowledge of English, 'obsolete' means that function no longer used because there is better replacement for that function. What is replacement for WinExec? ShellExecute, as I already mentioned, requires more parameters, does additional functionality and sits in completely another DLL, so it is not replacement.
> It is my opinion only. Let me know if I'm not right.

FWIW, it's not guarenteed to continue to be supported; if a future version of Windows drops support for the WOW VDM, many of the obsolete/"for compatibility" services may be dropped. There are lots of items in this category - many of the WNet family APIs that do not use a structure are also in this category, such as WNetAddConnection(), which is replaced by WNetAddConnection2() and WNetAddConnection3(), which offer superset behaviors. Many memory management functions fall in this category, too.

Since the superset behavior of ShellExecute() is advantageous, and the returns from it are equivalent, replacing the WinExec() with the more useful ShellExecute() seems a no-brainer; CreateProcess() is more complex, but I use it because there are really tremendous advantages to it's capabilities, at least from my POV. WinExec() is terribly flawed IAC, in that it doesn't permit you to specify either a starting directory, or control the initial placement of the main window or adjust the process environment, or track the app except by Window title bar (CreateProcess() of course does, as does the more complex ShellExecuteEx() thatbuilds on the basic ShellExecute() services. Note that while ShellExecuteEx() does superset ShellExecute()l ShellExecute() is not labelled as "for compatibility only", even though superset functions do exist.

YMMV, but given the relative painlessness of moving to ShellExecute() (frankly, I could write a small script using the VBScript.RegExp object to run through all my .PRG code and convert from WinExec() to ShellExecute() in under 15 lines of code) I'd switch before the issue was forced on me:

LOCAL aFiles(1,5), oReg, cFileString, nCnt
oReg = CREATEOBJ('VBScript.RegExp')
oReg.IgnoreCase = .T.
oReg.Global = .T.
oReg.Pattern = 'WINEXEC\(([^,]*),([^\)]*)\)'
=ADIR(aFiles,'*.PRG')
FOR nCnt = 1 TO ALEN(aFiles,1)
  cFileString = FILETOSTR(aFiles[nCnt,1])
  cFileString = oReg.Replace(cFileString,'ShellExecute(GetActiveWindow(),"OPEN",$1,0,0,$2)')
  =STRTOFILE(cFileString,aFiles[nCnt,1])
ENDFOR

Add a DECLARE...DLL for ShellExecute() and GetActiveWindow() to the app, and it's done. The only flaw in the regular expression above is where there's a "," embedded in the command line passed to WinExec().

FWIW, the needed DECLARE statements:

DECLARE INTEGER GetActiveWindow IN WIN32API
DECLARE INTEGER ShellExecute IN WIN32API INTEGER, STRING @, STRING @, INTEGER, INTEGER, INTEGER

And it's a good excuse to learn about the WSH's VBScript.RegExp object, since we need to do this kind of thing as developers pretty often - you can use this against the source code in SCX/VCX/FRX files by treating them as tables and processing the memo fields - it's just text. Problems importing an ASCII file? Piece of cake. Immensely useful for parser problems.

Yeah, I know a lot of VFP developers avoid using the WSH, but it's just too useful to ignore, and pretty easy to deploy. YMMV. I use it regularly, even when I know (and may have written) there's API code with similar functionality. Why reinvent the wheel?