1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Difference in exection with and without START

Discussion in 'Support' started by Steve Pitts, Jan 24, 2015.

  1. Steve Pitts

    Joined:
    Jul 7, 2008
    Messages:
    158
    Likes Received:
    0
    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??

    Code:
    [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.
     
  2. RogerB

    Joined:
    Apr 18, 2014
    Messages:
    142
    Likes Received:
    3
    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...
     
  3. mikea

    Joined:
    Dec 7, 2009
    Messages:
    210
    Likes Received:
    2
    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
     
  4. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,883
    Likes Received:
    29
    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:
    Code:
    realtemp.exe
    I see my custom colors. OTOH, if I start it like this
    Code:
    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.
     
  5. Steve Pitts

    Joined:
    Jul 7, 2008
    Messages:
    158
    Likes Received:
    0
    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.

    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.

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

    Joined:
    May 20, 2008
    Messages:
    7,883
    Likes Received:
    29
    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.
    upload_2015-1-24_21-53-1.png
     
  7. TEA-Time

    Joined:
    Jun 2, 2008
    Messages:
    282
    Likes Received:
    1
    Maybe the working directory gets changed? What does Sysinternals' Process Explorer have to say about it?
     
  8. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,883
    Likes Received:
    29
    Here's a pic of the quoted lpCommandLine (CreateProcess's second arg) with the extraneous space. This one happens when START is used.
    upload_2015-1-24_22-7-59.png
    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.
     
  9. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,883
    Likes Received:
    29
    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.
     
  10. Steve Pitts

    Joined:
    Jul 7, 2008
    Messages:
    158
    Likes Received:
    0
    Thanks for putting so much effort into this Vince. Methinks we need to be patient and wait for Rex to get involved.
     
  11. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,883
    Likes Received:
    29
    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().
     
  12. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,883
    Likes Received:
    29
    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!
     
  13. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,883
    Likes Received:
    29
    I posted a query in a RealTemp forum. The author of RealTemp replied:
    I replied:
     
  14. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,804
    Likes Received:
    82
    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.
     
  15. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,883
    Likes Received:
    29
    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?
     
  16. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,804
    Likes Received:
    82
    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.
     
  17. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,883
    Likes Received:
    29
    And with Win7, RealTemp.exe reads its INI file either way (CMD elevated or not).
     
  18. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,804
    Likes Received:
    82
  19. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,883
    Likes Received:
    29
    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.
     
  20. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,804
    Likes Received:
    82
    TCC (without START) definitely does *not* uc shift the filename in either the first or second argument.
     
  21. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,804
    Likes Received:
    82
    Then MS changed CMD again between Windows 7 and Windows 8.1. It definitely fails to read the .INI file in Win 8.
     
  22. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,804
    Likes Received:
    82
    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.
     
  23. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,883
    Likes Received:
    29
    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
     
  24. Steve Pitts

    Joined:
    Jul 7, 2008
    Messages:
    158
    Likes Received:
    0
    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.
     
  25. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,883
    Likes Received:
    29
    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.
     

Share This Page