Difference in exection with and without START

[Steve Pitts]

Rex,

I suspect that this is a question that only you can answer, although others may have some comments on their experiences with this I'm sure.

What is the difference (in terms of what happens in your code) between these two commands??

[D:\programs\RealTemp]d:\programs\RealTemp\RealTemp.exe

[D:\programs\RealTemp]start d:\programs\RealTemp\RealTemp.exe

My reason for asking this question is that the program concerned behaves differently between the two invocations - with the former it correctly finds and reads its INI file whereas with the latter it does not. Now that may well be a bug in the program being invoked - http://www.techpowerup.com/realtemp/ - but I can't think of any good reason why it would happen and even using Sysinternals' PROCMON on it doesn't throw any light in that each option seems to end up performing a Load Image for the same program name, and with similar looking command lines on the Process Start, but in one case the program reads the INI and in the other it reads itself (ie. the EXE).

I've tried this with fully-qualified names, just the .exe and without .exe and all behave the same way, and it seems to make no difference whether or not the program directory is the current location and/or whether or not it is passed in using the /D switch (in the START case). It also matters not whether the commands are issued from a normal command prompt or an elevated one (in the former case a UAC elevation dialog occurs but the end result is identical either way).

The reason I'm bothered by this is that I want to invoke the program from a batch file running in an elevated command prompt and I cannot get it to behave the way I need it to.

 

[RogerB]

Steve, this is a stab in the dark, but I believe using START causes a new TCC session to be started in which your specified programme is run. That new TCC session will run the TCC ini file and TCSTART, so if you have any conditional commands for transient sessions etc. in your TCSTART it's possible that might be the cause of your problem.

Apologies if I'm barking up the wrong tree...

 

[mikea]

Is there any change in the program's behavior if you add the "/pgm" switch to the "start" command? Probably not, but who knows. One workaround I've used when programs don't behave quite right following "start":

pushd to the directory containing the program in question
start the program, with switches/arguments as need be
popd

 

[vefatica]

I can confirm that there is a difference in behavior. I downloaded RealTemp, ran it, and used its "Settings" dialog to change some colors from the default values. The INI file's timestamp changed, so I figure that's where the change was remembered. Now, if I start it thus:

realtemp.exe

I see my custom colors. OTOH, if I start it like this

start realtemp.exe

I don't see the custom colors. Both were while RealTemp's home directory was the current directory. The results are the same with TCC v16.

 

[Steve Pitts]

I believe using START causes a new TCC session to be started in which your specified programme is run

Thanks for the idea, but (whilst the help might suggest otherwise, past discussions here have confirmed that) TCC does not start a new console instance when invoking a Windows GUI program via START.

Is there any change in the program's behavior if you add the "/pgm" switch to the "start" command?

Sadly not, in fact my very first attempt used that format before being simplified over time and having a CDD to the directory containing the program added (this batch file will run in a transient session, so no need to preserve using PUSHD/POPD). Both good ideas but neither helped I'm afraid.

I can confirm that there is a difference in behavior

Thanks for testing it Vince - nice to know that it isn't specific to my environment.

 

[vefatica]

I spent a while on this and I can't figure out what's happening. Using WinDbg, I did notice one thing that seems peculiar. When "START" is used the debugger breaks ar CreateProcess() three times; when "START" is not used, it breaks twice. In both cases, and after the first call to CreateProcess(), the second parameter to CreateProcess() (LPWSTR lpCommandLine) contains a trailing space. Here's a pic from WinDbg showing the trailing space. I have also seen the double-quoted fully-qualified name with an extraneous space after the closing quote.

 

[TEA-Time]

Sysinternals' PROCMON on it doesn't throw any light

Maybe the working directory gets changed? What does Sysinternals' Process Explorer have to say about it?

 

[vefatica]

Here's a pic of the quoted lpCommandLine (CreateProcess's second arg) with the extraneous space. This one happens when START is used.

I'm pretty sure the start-up directory has nothing to do with it. The START vs. no_START difference remains the same when the fully-qualified exename is used from any TCC current working directory.

 

[vefatica]

Several observations (but no real answers).

I started WinDbg elevated; it started TCC elevated; TCC started RealTemp elevated. This required only one call to CreateProcess. In WinDbg I can only see/edit CreateProcess's first three arguments. When I debugged the "START" case, and WinDbg broke at CreateProcess, I edited the first two parameters to match those in the "no START" case. This changed nothing.

With ProcessMonitor, I noticed that RealTemp opens the INI file in both cases, but does a lot more reading when START is not used.

With CMD's START command it works OK.

I tried running RealTemp a couple other ways where I could specify the command line ... my plugin SHELLEX, and my own CPOD.EXE (CreateProcessOnDesktop). Both worked OK.

I'm at a loss. I hope we find out what's happening.

 

[Steve Pitts]

Several observations (but no real answers)

Thanks for putting so much effort into this Vince. Methinks we need to be patient and wait for Rex to get involved.

 

[vefatica]

Apparently I was wrong about one observation. When started with TCC's START command, RealTemp.exe does not access, or attempt to access, its INI file. FWIW, when it does access its INI file, it uses GetPrivateProfileString().

 

[vefatica]

And you were correct, Steve, in your initial observation, that when started with START, RealTemp apparently makes the same 66 queries of RealTemp.exe that it makes of RealTemp.ini when not started with START. I'm tempted to say that MUST BE RealTemp's fault, but something about START is triggering it!

 

[vefatica]

I posted a query in a RealTemp forum. The author of RealTemp replied:

Thanks for posting that VinceF.

I had a look at the RealTemp code and found out that it has a feature that is not compatible with TCC. RealTemp allows a user to run 2 different versions of RealTemp from the same directory and allows each version to use a different INI file. For example, you could have RealTempA.exe and RealTempB.exe. The first program would use the RealTempA.INI config file and the second program would use the RealTempB.INI config file. I have no idea why I originally added this feature but I am sure it was a good idea at the time. I think it was so a person could access the temperature sensors on a dual CPU system. The code that I created for this feature is not working correctly with the Take Command program that you are using.

If this is important to you or to anyone in that other forum and you would like me to try to come up with a solution, send me a private message or ask them to send an email to the address in the About box of RealTemp. I will see what I can do.

I replied:

I doubt it's important to the original poster in the JPSoft forum. I'll try to find out.

I'm still very curious, and I suppose TCC's author is also, about what triggers the alternate behavior. Would you please explain?

 

[rconn]

The real answer has nothing to do with CreateProcess or any of its options. (If you're running TCC on-elevated, the CreateProcess will fail, so TCC runs RealTemp via ShellExecuteW.)

You can make RealTemp fail to load its .INI file from the command line in TCC or in CMD (command line or via START) just by running "REALTEMP.EXE" (i.e., in caps rather than lower case).

TCC's START converts the argument name (if it's an executable file) to upper case for compatibility with older versions of CMD and a few apps that rely on it. (Apparently CMD changed this behavior in Win 7 -- lucky CMD, it doesn't have to be compatible with prior versions!) Possibly now that TCC doesn't support XP, it can drop the auto-capitalization, but I'm a little reluctant knowing that it had to be done in the past for some apps.

So -- definitely a RealTemp issue. Expecting arguments to be in a specific case might make sense in Linux, but not in Windows.

 

[vefatica]

Thanks! I asked the author to explain what was triggering the behavior (maybe he will, maybe he won't). I tried it in uppercase with CMD; it read its INI file. What do the newer CMDs do ... convert to lower ... to whatever is in the file system?

 

[rconn]

With Win 8.1 x64, running REALTEMP.EXE in CMD, it fails to read the .INI file when run from the command line or from START.

 

[vefatica]

Thanks! I asked the author to explain what was triggering the behavior (maybe he will, maybe he won't). I tried it in uppercase with CMD; it read its INI file. What do the newer CMDs do ... convert to lower ... to whatever is in the file system?

And with Win7, RealTemp.exe reads its INI file either way (CMD elevated or not).

 

[rconn]

Did you try it with all caps?

 

[vefatica]

Did you try it with all caps?

Yes. CMD, all caps, START or not, elevated or not ... it reads its INI file.

And the CreateProcessW that ultimately starts RealTemp for CMD has first param, FQPathName in file system case, second param, L"REALTEMP.EXE". TCC's (without START) has the first param as FQPathName with the file name in caps; the second param L"REALTEMP.EXE ", with a trailing space.

 

[rconn]

TCC (without START) definitely does *not* uc shift the filename in either the first or second argument.

 

[rconn]

Yes. CMD, all caps, START or not, elevated or not ... it reads its INI file.

Then MS changed CMD again between Windows 7 and Windows 8.1. It definitely fails to read the .INI file in Win 8.

 

[rconn]

Yes. CMD, all caps, START or not, elevated or not ... it reads its INI file.

And the CreateProcessW that ultimately starts RealTemp for CMD has first param, FQPathName in file system case, second param, L"REALTEMP.EXE". TCC's (without START) has the first param as FQPathName with the file name in caps; the second param L"REALTEMP.EXE ", with a trailing space.

Are you running CMD and TCC elevated? If not, then what you're seeing is the CreateProcess call that's created internally by Windows when TCC calls ShellExecute. If you're running TCC elevated, then TCC only makes a single call to CreateProcess.

 

[vefatica]

Are you running CMD and TCC elevated? If not, then what you're seeing is the CreateProcess call that's created internally by Windows when TCC calls ShellExecute. If you're running TCC elevated, then TCC only makes a single call to CreateProcess.

I did all those tests from an elevated WinDbg. With both CMD and TCC, both started by WinDbg, there were no UAC prompts and CreateProcessW was called only once.

In testing last week, unelevated, I saw multiple calls to CreateProcessW, the last one, I imagine, triggered by ShellExecute

 

[Steve Pitts]

I doubt it's important to the original poster in the JPSoft forum

Sorry Vince, I've been busy with other things and to be honest I bypassed the issue by invoking an elevated CMD with a suitable batch file, which achieves what I set out to handle in the first place, so no it isn't important. Even reading all of the above I'm still not sure exactly what the problem is or who can fix it, so it is probably best left alone by all concerned.

 

[vefatica]

Sorry Vince, I've been busy with other things and to be honest I bypassed the issue by invoking an elevated CMD with a suitable batch file, which achieves what I set out to handle in the first place, so no it isn't important. Even reading all of the above I'm still not sure exactly what the problem is or who can fix it, so it is probably best left alone by all concerned.

I don't think you can call it a "problem". Though he hasn't been very specific, the author of RealTemp has said he does something unusual to facilitate starting RealTemp with other-than-default INI files. He seems disinclined to change the behavior unless it really causes a problem for someone. And, though I still don't understand exactly what triggers the unfortunate behavior, I don't think you can call it a "fault" of TCC.