.exe files from compiled with some compilers do not start from the tcc command line

[knudvaneeden]

Hello,

Is this maybe some known issue?

1. Compiled with Borland C++ e-bor.exe = starts foobar.exe in JPSoft tcc.exe? YES

2. Compiled wit CLang version 19 e-clang.exe = starts foobar.exe in JPSoft tcc.exe? NO

3. Compiled with GCC: e-gcc.exe = starts foobar.exe in JPSoft tcc.exe? NO

4. Compiled with Microsoft e-msvc.exe = starts foobar.exe in JPSoft tcc.exe? NO

5. Compiled with Open Watcom e-wcc.exe = starts foobar.exe in JPSoft tcc.exe? YES

===

But using Microsoft cmd.exe works all the time:

1. Compiled with Borland C++ e-bor.exe = starts foobar.exe using cmd.exe /c e-bor.exe YES

2. Compiled wit CLang version 19 e-clang.exe = starts foobar.exe using cmd.exe /c e-clang.exe YES

3. Compiled with GCC: e-gcc.exe = starts foobar.exe using cmd.exe /c e-gcc.exe YES

4. Compiled with Microsoft e-msvc.exe = starts foobar.exe using cmd.exe /c e-msvc.exe YES

5. Compiled with Open Watcom e-wcc.exe = starts foobar.exe using cmd.exe /c e-wcc.exe YES

When you run such a .exe by typing the .exe on the tcc.exe command line , typically basically nothing happens.

Used tcc version latest 36.52 build 88
but this seems reproducible in any earlier version of tcc.exe.
It never works thus.

Root cause: Maybe something with mandatory compiler options if you want it to let start in tcc.exe?

Note that Borland C++ command line compiler was in the past always used to compile that program
and that always worked. Now it is moved e.g. to CLang as a compiler and starting such .exe does not start
anymore from the command line. Similar for Microsoft MSVC and MinG gcc, it does not start.

 

[vefatica]

What is the EXE? What does it do? What is the exact failing command line you are trying to execute in TCC?

 

[knudvaneeden]

At the moment more interested if anyone has experience with some .exe not starting from the command line in JPsoft tcc command line. Let say the name is foobar.exe. So you type that name foobar.exe then press enter. After a slight delay nothing happens. Expected is that the program starts doing or showing something. Running the same executable in cmd.exe either by typing that cmd.exe in tcc and then running foobar.exe or otherwise similarly typing cmd.exe /c foobar.exe in tcc works fine, no issues.

 

[Joe Caverly]

What is the @exetype of the generated .exe file ?

Are the generated .exe files of subsystem type console or of subsystem type windows ?

For example, if I have an .exe that outputs to the console,
but I have the subsystem of the .exe as windows,
the .exe runs,
no output is displayed on the console,
and I am returned to the command prompt.

Ref: @EXETYPE TCC internal variable function
Ref: /SUBSYSTEM

Joe

 

[knudvaneeden]

They all show 6 (I assume that means 'Windows')
and we should know that Watcom the Watcom e-wcc.ee is a 'Console' type, so 7 is I assume also expected.

Not much to gain there thus as no difference in the working versus non-working versions.

echo %@exetype["e-bor.exe" ]

6

echo %@exetype["e-clang-msvcrt.exe"]

6

echo %@exetype["e-clang.exe" ]

6

echo %@exetype["e-gcc-msvcrt.exe"]

6

echo %@exetype["e-gcc.exe"]

6

echo %@exetype["e-wcc.exe"]

7

 

[Joe Caverly]

Posting the link to the conversation at the TSE Forum here for future reference;

TSE: 4.50.28: Starting .exe from the JPSoft tcc.exe command line

groups.google.com

Joe

 

[knudvaneeden]

This issue can be closed.

Root cause: What happened was that the .exe source code wrote to read-only memory
(assigning a value to a constant string)

Microsoft cmd.exe does not seem to care about it and moves on so the .exe application starts.

While in tcc.exe type e.g.:

cmd.exe /c g32.exe

So tcc.exe handles the situation differently, cares and it crashes there at that string assignment read-only memory overwrite attempt location in memory and the .exe crashes silently
on the tcc.exe command line.

So the compiled .exe from MingW gcc.exe, Microsoft cl.exe and Microsoft msvc.exe and clang.exe all had
this source coding issue compiled in and when running it in tcc.exe the .exe application
silently crashed.

When compiling with the older Borland C++ command line compiler and Open Watcom compiler the issue was also not a stopper on tcc.exe and
the .exe application started as usual.

So the end effect was a combination of which compiler was used to compile and also using tcc.exe to start from.

On the Microsoft cmd.exe environment the .exe compiled via the 4 different compilers all did run.