ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE.

DonationCoder.com Software > Drag&Drop Robot

Suggestion: Use Comspec

<< < (4/5) > >>

myarmor:
Btw, if you want to check out what I'm talking about, there's a free (limited featureset, still more advanced than
the default command processor) named TCC/LE, a trial of Take Command, and a trial of Take Command LE at jpsoft.com

---
Mods: I'm not trying to advertise their product, but I thought you might like to look at it and see why I want it to be used
instead of the normal command processor.

If you consider THIS post to be an advertisement, then please remove it if you want to.

mouser:
on this forum we welcome people expressing opinions about software they like (the only time you will find people complaining about spam/adverts is when someone signs up for the sole purpose of advertising their software).

myarmor:
@Mouser, I'd noticed you had your fill of that kind (an opinion I share), so I wanted to make sure this wasn't seen as one. :)

I'm still rather new on these forums you know. :)

mouser:
Glad to have you here :)

f0dder:
I generally set lpApplicationName=0, and construct a fully-qualified pathname (including quotes if necessary (ie., paths including spaces)) for lpCommandLine - this seems to give the most consistant results.

I dunno if the "To run a batch file, you must start the command interpreter" info from MSDN has ever been necessary, or if it's perhaps just a relic from the win3.x days... guess it might be worth firing up a win9x vmware image (and install + test a NT4 image) and see if they work with appname=0 and specifying just the batch file in cmdline.

Getting systemroot and appending cmd.exe definitely breaks Win9x compatibility - there really shouldn't be any systems with %ComSpec% set, and if you want to be really paranoid, don't hardcode anything but check the registry association for .bat (but that's almost at the point of being silly, imho).

second question, assuming i want to just let the OS do it's default when an alternate command shell isn't specified, can i check %comspec% and tell if a replacement shell has been configured.  i.e. if i see cmd.exe file in %comspec% shall i just assume its default and let CreateProcess handle the .bat file normally.
-mouser
--- End quote ---
Good question, really - see, if you simply start cmd.exe with a batch file as argument, you just get a new cmd.exe instance, and no executing batch file. You need to specify /C (run-and-terminate) or /K (run-and-remain) to cmd.exe before the batch file path. This is probably why CreateProcess has special magic for handling batch files in the first place!

Probably the best idea is to drop %ComSpec% entirely (magic'ing it for cmd.exe and command.com sounds like a recipe for disaster), and look up the registry... HKEY_CLASSES_ROOT\{.bat,.cmd} , follow the default value and check the shell\open\command of that key, doing proper expansion of it's default value.

OK, that sounds like too much bother as well, and a lot of opportunities for failing.

third and final question -- is there any value in letting the user manually specify the command shell to use when launching .bat files instead of checking %comspec%.  this would be useful for people who want to use an alternate shell not configured through %comspec%
-mouser
--- End quote ---
Probably the most failsafe method of doing it, and definitely the easiest.

EDIT: I just checked the (32-bit) version of kernel32.dll from my XP64 system, and indeed CreateProcess has hardcoded checks for .bat and .cmd, and hardcodes "cmd /c".

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version