IDE.EXE's command line?
- Thread starter vefatica
- Start date
I'm after IDE.EXE's command line.
The only way I know of to get Task Manager (et al.) to show a command line like that is to edit the string pointed to by GetCommandLine() in place. That's allowed, and the change is system-wide, but it may be a little rude.
TCC has to name the EXE to run it. Task Manager shows what's pointed to by GetCommandLine(). How do you suppose this (below) happens.
Moments later ...
If IDE.EXE isn't writing to GetCommandLine(), it must be magic.
I ran my getcommandline.btm as;
...and it returned;
With TCC-RT I get;
With bdebugger I get;
This used to work properly in TCC 23, but it no longer works in TCC 24. Mind you, I was running TCC 23 in 64-bit Windows 7, whereas I am now running TCC 24 in Windows 10
Joe
Code:
c:\program files\jpsoft\tcmd24>ide.exe E:\utils\GetCommandLine.btm
Code:
The String Address for the Command Line is: 1319122630
The Length of the Command Line is : 0
The Command Line is :With TCC-RT I get;
Code:
e:\utils>tccrt GetCommandLine.btm
The String Address for the Command Line is: -1914685700
The Length of the Command Line is : 22
The Command Line is : -1914685700With bdebugger I get;
Code:
The String Address for the Command Line is: 1134704278
The Length of the Command Line is : 0
The Command Line is :This used to work properly in TCC 23, but it no longer works in TCC 24. Mind you, I was running TCC 23 in 64-bit Windows 7, whereas I am now running TCC 24 in Windows 10
Code:
_x64: 1
_admin: 1
_elevated: 1
TCC 24.02.49 x64 Windows 10 [Version 10.0.18362.175]Joe
I don't get your point; you're showing TCC and not IDE. IDE is an internal TCC command; TCC sticks the TCMD.INI arg and the batch file name on the command line and calls IDE.EXE. When you run something in IDE.EXE, the TCC parser embedded in IDE will change the title. Nobody writes directly to the string returned from GetCommandLine.
With TCC v24, it works on Win7/32.
Code:
v:\> ver
TCC 24.02.49 Windows 7 [Version 6.1.7601]
v:\> \\jj\v$\gcl.btm
The String Address for the Command Line is: 1515436
The Length of the Command Line is : 30
The Command Line is : g:\tc24\tcc.exeMy point was that you can make TaskMgr's command whatever you line by editing the string at GetCommandLine().
So, as I said before, it must be magic (gremlins, leprechauns, ...). With 120+ processes, every one that shows a command line, except IDE.EXE, shows the name of an EXE (possibly followed by parameters). The internal BDEBUGGER/IDE must name IDE.EXE to start it. If IDE.EXE isn't altering the command used by CreateProcess, I'd like to know what's happening.
TCC & IDE & TCMD all call GetCommandLine() once, in exactly the same way:
CAtlString strCommandLine = GetCommandLine();
There's no pointer to the text, so there is no subsequent possibility for anyone to modify what GetCommandLine() points to. Barring catastrophic failures in C++, ATL, Windows, and Intel's hardware. (Okay, we're all used to the catastrophic failures coming from Intel ...)
When I run BDEBUGGER or IDE (both internal TCC commands that generate a custom command line to pass to IDE.EXE), I see IDE.EXE in the task manager with the command line passed to it by TCC. Debugging batch files or loading new files in tabs doesn't affect the fixed result shown by task manager. And the text shown in task manager is not necessarily the same as returned by GetCommandLine() inside IDE.EXE.
Also (this is Windows, not TCC / IDE / TCMD) the executable argument is not necessarily returned as the first argument by GetCommandLine(). (That's been happening for at least 20+ years, back to NT 3.1.) And what is returned by GetCommandLine() depends on exactly how CreateProcess is called (there's several different ways to pass the arguments). And Windows will on its own sometimes rewrite the arguments passed to CreateProcess (for example, to add paths).
Looking for the executable name in the string returned by GetCommandLine() is fruitless. If that's what you're looking for, you should be using GetModuleFileName().
CAtlString strCommandLine = GetCommandLine();
There's no pointer to the text, so there is no subsequent possibility for anyone to modify what GetCommandLine() points to. Barring catastrophic failures in C++, ATL, Windows, and Intel's hardware. (Okay, we're all used to the catastrophic failures coming from Intel ...)
When I run BDEBUGGER or IDE (both internal TCC commands that generate a custom command line to pass to IDE.EXE), I see IDE.EXE in the task manager with the command line passed to it by TCC. Debugging batch files or loading new files in tabs doesn't affect the fixed result shown by task manager. And the text shown in task manager is not necessarily the same as returned by GetCommandLine() inside IDE.EXE.
Also (this is Windows, not TCC / IDE / TCMD) the executable argument is not necessarily returned as the first argument by GetCommandLine(). (That's been happening for at least 20+ years, back to NT 3.1.) And what is returned by GetCommandLine() depends on exactly how CreateProcess is called (there's several different ways to pass the arguments). And Windows will on its own sometimes rewrite the arguments passed to CreateProcess (for example, to add paths).
Looking for the executable name in the string returned by GetCommandLine() is fruitless. If that's what you're looking for, you should be using GetModuleFileName().
Don't worry about it. I just don't get it and that's my problem. I figure CreateProcessW must somehow get the name of IDE.EXE. The EXE's name not showing up in TaskMgr is pretty odd. I just want to know how that happens.
As for the command line, I see what's happening (and I'm reminded why I swore many years ago that I wouldn't use CreateProcess's first parameter (szApplicationName)). If you use szApplicationName (FQname) and put the tail of the command line in szCommandLine (WITH A LEADING SPACE), then CreateProcess works as desired and the "command line" (according to TaskMgr, WMI, et al.) is szCommandLine (WITH THE LEADING SPACE). It never made much sense to me. And looking at TaskMgr, it apparently isn't done often.
Code:
v:\> echo ***%@wmi[.,"select CommandLine from Win32_Process where name = 'ide.exe'"]***
*** @"D:\tc24\TCMD.INI" myline.btm***
v:\> echo ***%@pstat[ide.exe,C]***
*** @"D:\tc24\TCMD.INI" myline.btm***I could speculate. The help says
Reading that literally, it's interpreting GetCommandLine()'s value as a 32-bit quantity when it's really a 64-bit pointer. If the pointer is wrong, the length will be wrong (as you observed, me too). It just might be a fluke that your Win7 didn't go past 2^32 and Win10 does. And working its on Win7/32 would be no surprise.
I made some changes (without success). %StrLen is (should be) the length of the string in characters.
This much should be moved/copied: %@eval[%StrLen * 2 + 2] (to get the terminating NUL.
In Win10 you can use RtlCopyMemory (ntdll.dll).
I have this .btm;
When I run it thus;
...and run it in the ide, it returns;
cmdline returns correct result, wmi gives an error.
Leaving the IDE.EXE running, via TCMD, I open a second TCC, and run the same .btm from the command line, and it returns;
It sees the ide.exe from the first TCC, and wmi does not return an error.
Why the difference between the two?
Joe
Code:
@setlocal
@echo off
echo %@wmi[.,"select CommandLine from Win32_Process where name = 'ide.exe'"]
echo %cmdline
endlocalWhen I run it thus;
Code:
ide.exe test.btm
Code:
TCC: (Sys) C:\Program Files\JPSoft\TCMD24\test.btm [3] The parameter is incorrect.
"%@wmi[.,"select CommandLine from Win32_Process where name = 'ide.exe'"]"
"C:\Program Files\JPSoft\TCMD24\test.btm"cmdline returns correct result, wmi gives an error.
Leaving the IDE.EXE running, via TCMD, I open a second TCC, and run the same .btm from the command line, and it returns;
Code:
ide.exe test.btm
test.btmIt sees the ide.exe from the first TCC, and wmi does not return an error.
Why the difference between the two?
Joe
I changed the BTM a bit and used (more properly?) "BDEBUGGER v:\wimi.btm". I see the same thing (and worse). Below, top to bottom, the BTM, result in IDE, result in TCC. Nothing is elevated. My only guess is that WMI is just plain broken in IDE.EXE.
Another odd thing is that when I debug that BTM (only two lines as shown in my last post), the first line is executed as soon as I press the start debugging arrow. Usually it doesn't execute the first line immediately.
I think I can say what's wrong with WMI in IDE.EXE. IDE.EXE does not call CoInitializeSecurity() (or doesn't call it correctly).
When I call CoInitializeSecurity() during the initialization of a plugin ...
... in TCC.EXE it returns RPC_E_TOO_LATE (already been initialized).
... in IDE.EXE it returns S_OK and WMI then works in IDE.EXE.
When I call CoInitializeSecurity() during the initialization of a plugin ...
... in TCC.EXE it returns RPC_E_TOO_LATE (already been initialized).
... in IDE.EXE it returns S_OK and WMI then works in IDE.EXE.
From bdebugger;
...returns...
From TCC;
...thus the external Microsoft wmic.exe works in IDE.EXE
Added: How does TaskList determine the Startup Command?
Joe
Code:
echo Using @wmi : %@wmi[.,"select CommandLine from Win32_Process where name = 'ide.exe'"]
echo Using cmdline : %cmdline
echo Using tasklist: %@word["@",-0,%@execstr[tasklist /l ide]]
echo Using WMIC : %@execstr[1,WMIC process where name="ide.exe" get Commandline]...returns...
Code:
TCC: (Sys) E:\Utils\getcommandline.btm [24] The parameter is incorrect.
"%@wmi[.,"select CommandLine from Win32_Process where name = 'ide.exe'"]"
Using cmdline : "E:\Utils\getcommandline.btm"
Using tasklist: "C:\Program Files\JPSoft\TCMD24\TCMD.INI" getcommandline.btm
Using WMIC : @"C:\Program Files\JPSoft\TCMD24\TCMD.INI" getcommandline.btmFrom TCC;
Code:
e:\utils>getcommandline.btm
Using @wmi : @"C:\Program Files\JPSoft\TCMD24\TCMD.INI" getcommandline.btm
Using cmdline : getcommandline.btm
Using tasklist: "C:\Program Files\JPSoft\TCMD24\TCMD.INI" getcommandline.btm
Using WMIC : @"C:\Program Files\JPSoft\TCMD24\TCMD.INI" getcommandline.btm
Code:
e:\utils>which tasklist wmic
tasklist is an internal command
wmic is an external : C:\WINDOWS\System32\Wbem\wmic.exe...thus the external Microsoft wmic.exe works in IDE.EXE
Added: How does TaskList determine the Startup Command?
Joe
Last edited:
