Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Integration of TCC with build tools (Eclipse, g++, gcc, make)

Apr
9
0
Has anyone experience in specifying tcc.exe as the default shell/console for handling console-based applications.

I mean when you normally run, for example, g++ in the run window, it will bring up a shell (which is cmd.exe) and run the g++.exe inside it. I want to make tcc.exe come up when launching the applications in this way.

It is necessary for me to overcome the "input line too long" issue when building large applications from the Eclipse IDE.

Info: The reason behind that error is that recent windows versions have a limitation of command-line input of maximum 8191 characters [http://support.microsoft.com/kb/830473]. On the other hand, I see that tcc.exe accepts about 32768 characters (which will suffice for my case).

Note: I have set the ComSpec system variable to the fullpath of TCC.exe and still cmd.exe loads as the default shell terminal when lunching console-based applications.
 
I mean when you normally run, for example, g++ in the run window, it will bring up a shell (which is cmd.exe) and run the g++.exe inside it.
Are you actually running a bat file? You can make TCC the default for bat files using the TCCBatch.btm file (if you really want to). Or, you can run the bat file from within TCC or pass the bat file to TCC using the /C option.
 
Has anyone experience in specifying tcc.exe as the default shell/console for handling console-based applications.

I mean when you normally run, for example, g++ in the run window, it will bring up a shell (which is cmd.exe) and run the g++.exe inside it. I want to make tcc.exe come up when launching the applications in this way.

It depends how you're launching the apps. Changing the COMSPEC system variable in the Control Panel will cause new console windows that are started by other apps via COMSPEC to use TCC. (But this will probably require a reboot after changing COMSPEC, as the change will not be propagated to anything that is already running.)

If you're launching the apps from a shortcut (or the Start button), you'll have to edit the shortcut. (For example, the "Command Prompt" entry is hard-wired to CMD.EXE.)

If you're launching a batch file (.BAT or .CMD), you'll need to change the file associations from CMD.EXE to TCC.EXE. TCC includes a batch file (TCCBATCH.BTM) to do this for you.
 
Are you actually running a bat file? You can make TCC the default for bat files using the TCCBatch.btm file (if you really want to). Or, you can run the bat file from within TCC or pass the bat file to TCC using the /C option.

Many thanks for your the information about batch files.
Actually, my case is that there is an *.exe application (eg: eclipse.exe) that runs the g++-3.exe compiler from within itself.

Or, for example imagine the following is a button handler in an executable application that lunches the g++ compiler:
Code:
        private void button1_Click(object sender, EventArgs e)
        {
            Process.Start(@"d:\cygwin\bin\g++-3.exe");
        }
In these cases, I wanted the terminal window that automatically appears be that of tcc.exe, not that of the default cmd.exe
 
It depends how you're launching the apps. Changing the COMSPEC system variable in the Control Panel will cause new console windows that are started by other apps via COMSPEC to use TCC. (But this will probably require a reboot after changing COMSPEC, as the change will not be propagated to anything that is already running.)

If you're launching the apps from a shortcut (or the Start button), you'll have to edit the shortcut. (For example, the "Command Prompt" entry is hard-wired to CMD.EXE.)

If you're launching a batch file (.BAT or .CMD), you'll need to change the file associations from CMD.EXE to TCC.EXE. TCC includes a batch file (TCCBATCH.BTM) to do this for you.

Thanks a lot for your reply and the information about batch files. I have declared ComSpec and rebooted afterwards, but it seems that the launcher application does not use the variable and invokes the child executable directly.

Please also see my previous reply to David Marcus about my case.
 
In these cases, I wanted the terminal window that automatically appears be that of tcc.exe, not that of the default cmd.exe
I would guess that you'd need to change the process.start call to invoke TCC explicitly with a command tail that launches the desired application, and switches to control that TCC (things like /k to leave the window open after it has run, see the help for the full gamut of options you have)
 
I would guess that you'd need to change the process.start call to invoke TCC explicitly with a command tail that launches the desired application, and switches to control that TCC (things like /k to leave the window open after it has run, see the help for the full gamut of options you have)

Well, if I want to go into further details, I should say that an application executable (3rd party, like eclipse.exe), launches another application executable (again 3rd party, like g++.exe).
Since g++.exe is a console-based application, it will be launched in a way that a command-prompt-like console window will appear (of course the application has not invoked a "cmd /k" command, It has probably utilized a mechanism like the one I prototyped myself for testing and simulating the behavior).

NOTE: After some monitoring of the executable process images in the memory, I realized that when a console application is run, there is no cmd.exe run in association with it. In this regard, I am suspecting now that the cmd.exe shell may not be involved in the process at all [in a visible manner], and only a similar window (but at least 99% similar!) to it will appear when lunching the console-based applications.
 
If Eclipse isn't running cmd.exe, then there isn't much hope of you coaxing it to run TCC instead (unless they document a way to do this). Perhaps Eclipse is just popping up a window, capturing the output of g++ via some method, and displaying it in the window; don't know. But, if so, I doubt cmd.exe's command-line length limit is relevant, although Eclipse may have a similar limit.

Instead of having Eclipse run g++, why don't you tell it to run TCC and a btm file? Then you can make it do what you want.

I suppose you have to use Eclipse.
 
It has probably utilized a mechanism like the one I prototyped myself for testing and simulating the behavior
I believe that process.start will probably be calling ShellExecute under the covers, in which case the extension will be used to identify how to process the given filename and (if my reading of the registry entries is correct) will eventually end up simply issuing the equivalent of '"%1" %*'. On that basis you are right that there is not going to be an instance of cmd.exe associated with the invoked program any more than there would be if you double-clicked it from an Explorer window.

Beyond that you'd need an expert in how Windows handles console mode programs internally, and I'm guessing that Rex would be one of the leaders in that particular field :)
 
Given your example launcher it would appear
that CMD is not even in the picture. G++ is a console app so it would
launch in a console. My guess is that the line length limitation
is due to g++ itself and not cmd or tcc.

Most compilers have an option to retrieve
its options from a file.
E.g. mycompiler @myoptions
or
mycompiler -f myoptions

-Scott

fakoor <> wrote on 04/24/2011
01:00:33 AM:


>
> Thanks a lot for your reply and the information about batch files.
I

> have declared ComSpec and rebooted afterwards, but it seems that the
> launcher application does not use the variable and invokes the child
> executable directly.
>
> Please also see my previous reply to David Marcus about my case.
>
>
 
Most compilers have an option to retrieve
its options from a file.
E.g. mycompiler @myoptions
or
mycompiler -f myoptions
Well, I should give a try to this method. It seems to be a specific workaround to the scenario of compiler invocation command-length problem.
 
I believe that process.start will probably be calling ShellExecute under the covers, in which case the extension will be used to identify how to process the given filename and (if my reading of the registry entries is correct) will eventually end up simply issuing the equivalent of '"%1" %*'. On that basis you are right that there is not going to be an instance of cmd.exe associated with the invoked program any more than there would be if you double-clicked it from an Explorer window.

Beyond that you'd need an expert in how Windows handles console mode programs internally, and I'm guessing that Rex would be one of the leaders in that particular field :)

Well, yes, I am now more convinced that there is noting to do with cmd.exe itself when lunching such console-based applications. May be there is some windows internal parts that the cmd.exe uses as well to show its console the same as other console-based applications. And the limitation is coming from that source.
 

Similar threads

Back
Top