IDE.EXE's command line?

[vefatica]

Does IDE.EXE modify its own command line?

 

[rconn]

I don't know what you're after. IDE retrieves its command line from the Windows GetCommandLine API, makes a copy, and parses that copy.

 

[vefatica]

I don't know what you're after. IDE retrieves its command line from the Windows GetCommandLine API, makes a copy, and parses that copy.

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.

 

[rconn]

IDE does not edit its command line in place. What you see in Task Manager is the command line passed to IDE by TCC.

 

[vefatica]

IDE does not edit its command line in place. What you see in Task Manager is the command line passed to IDE by TCC.

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.

 

[Joe Caverly]

I ran my getcommandline.btm as;

c:\program files\jpsoft\tcmd24>ide.exe E:\utils\GetCommandLine.btm

...and it returned;

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;

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                       : -1914685700

With bdebugger I get;

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

     _x64: 1
   _admin: 1
_elevated: 1

TCC  24.02.49 x64   Windows 10 [Version 10.0.18362.175]

Joe

 

[rconn]

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.

View attachment 2412

Moments later ...

View attachment 2413

If IDE.EXE isn't writing to GetCommandLine(), it must be magic.

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.

 

[vefatica]

With TCC v24, it works on Win7/32.

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.exe

 

[vefatica]

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.

My 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.

 

[rconn]

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().

 

[vefatica]

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.

 

[Joe Caverly]

With TCC v24, it works on Win7/32.

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.exe

@rconn can you elaborate on why this worked for me on 64-bit Windows 7 (TCC 23), but not on 64-bit Windows 10 (TCC 24), and why @vefatica can get it to work on 32-bit Windows 7 (TCC 24)?

Joe

 

[vefatica]

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.

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***

 

[vefatica]

@rconn can you elaborate on why this worked for me on 64-bit Windows 7 (TCC 23), but not on 64-bit Windows 10 (TCC 24), and why @vefatica can get it to work on 32-bit Windows 7 (TCC 24)?

Joe

I could speculate. The help says

The return value is either a string value returned by the API (if BUFFER or aBUFFER is specified), or the integer value returned by the API.

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).

 

[Joe Caverly]

I have this .btm;

@setlocal
@echo off
echo %@wmi[.,"select CommandLine from Win32_Process where name = 'ide.exe'"]
echo %cmdline
endlocal

When I run it thus;

ide.exe test.btm

...and run it in the ide, it returns;

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;

ide.exe test.btm
test.btm

It sees the ide.exe from the first TCC, and wmi does not return an error.

Why the difference between the two?

Joe

 

[vefatica]

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.

 

[vefatica]

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.

 

[vefatica]

And I wish it would stop making .watch files just to save ? and _?.

 

[vefatica]

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.

 

[Joe Caverly]

From bdebugger;

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...

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.btm

From TCC;

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

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