>>>Hi all,
>>>I've got apps in FPD2.6, FPW2.6a, and VFP7. All of these apps are run on different versions of Windows. ie W95, W98, W2K, WXP(coming). Most of these apps call DOS batch files to run some DOS programs. That's the problem.
>>>
>>>In DOS up to what's in Win2K, the START /WAIT command works as expected. The program is run from the batch file and the batch file waits until the called prog finishes before it continues. In DOS from Win2K up, the START /WAIT does not operate that way and essentially blows past the line containing the command doing nothing. (Don't get picky on me. I know what it really does.).
>>>
>>>The simple solution in Win2K is to remove the START /WAIT and leave the rest of the line intact. Then the batch file runs the way it does in previous versions of DOS.
>>>
>>>Unfortunately, as noted above, I can't tell which workstation will run what app.
>>>Is there some way programatically that I can determine which DOS or OS I'm running so that I can run the proper batch commands? Is there a simple way around this? We have several hundred batch files to contend with.
>>>
>>>Pete
>>Pete,
>>There is OS() and it has enhanced parameter in VFP7. Returns 'Windows 5.00' for w2k w/o optional parameter.
>>Also getenv('comspec') would return cmd.exe instead of command.exe for NT platforms.
>>Cetin
>
>On NT 4 GetEnv('comspec') return C:\Winnt\System32\cmd.exe same as in W2K. I think command.exe is on W9x systems. Getenv('OS') does not help either because it returns 'Windows_NT' for both W2K & NT.
>
>But OS() does return 'Windows 5.00' for W2K and 'Windows 4.00' for NT4, that's why I suggested OS().

Yes,
I too suggested OS() :) However some old programs fell into same mistake and newer Windows versions were gone unseen. It's too loose to give info.
Honestly getenv() variations too doesn't seem to be a bulletproof way (command.com it was - I wrote wrong too). Somebody might easily rename the shell. Either by brute force or say setting it to something else (as ndos in DOS days). SetVer also spoils things.
Probably I would use a single batch file with different commands introduced with each new version and check errorlevel. I don't know. I'm no good in batch writing and can't think of a way that would cover Fox2x to VFP7 (maybe a Fox2x exe calling assembly - it could be used by VFP7 too).
Anyway seems Pete has a solution working for him.
Cetin