Re TSE 4.50.27

[knud van eeden]

Issue:

1. Typing g32.exe on the JPSoft tcc.exe command line does not start g32.exe as usual and as always.

2. To compare, if I go to my 4.50.26 installation typing g32.exe there it works just OK, no issue.

Conclusion by induction:

From:

4.50.27 g32.exe does not start.

4.50.27 tse.exe does not start

4.50.27 e.exe does not start.

....

Induction:

The current compiled in 4.50.27 .exe header format does not have the correct default Microsoft information to be able to start

(in some environments, e.g. JPSoft tcc.exe).

[S.E. Mitchell]

I asked Google, and here is what I was told.  It seems this is an issue with TCC, not Clang.  At least based on the information below.  I can look at recompiling with #2 below.  

I'm no so sure about #1 and #3.  

#1 causes performance degradation.  Who wants that? :)

When compiled with #3, it might cause a problem with anti-virus software.  I'm continuing to verify this.

1) The Real-Mode Stack Alignment Crash
Modern 32-bit Clang assumes a 16-byte stack alignment for
performance optimizations (especially for SSE instructions)
and generates binary entry code expecting it.

Borland C++ 5.51 generates binaries that assume a standard
4-byte alignment.

The TCC Conflict: When TCC hooks the process execution to
monitor the console attachment, it handles the initial thread
context alignment strictly according to legacy Win32 design.

If Clang attempts an optimization assuming 16-byte boundaries
and the console hook violates that alignment right at the
entry point, the program triggers an immediate, silent CPU
exception (STATUS_DATATYPE_MISALIGNMENT) before a single line
of your code executes, causing TCC to drop straight back to
the prompt.

The Fix: Force Clang to generate a legacy-compatible 4-byte
stack alignment by adding this flag to your compilation
command:

clang -mstack-alignment=4 g32.c -o g32.exe

Note that this will degrade performance.

2) Mandatory Thread Local Storage (__chkstk) and Stack
GuardsWhen compiling an editor, you likely have local
structural array allocations or character buffers on the
stack.

The Difference: If a local function stack exceeds 4096 bytes,
Clang inserts a call to an internal helper function called
__chkstk (or __alloca) to probe stack pages sequentially.

The TCC Conflict: Borland structures these differently.

Clang's 32-bit implementation of __chkstk occasionally
conflicts with custom console hooks or standard I/O
interception mechanisms built into TCC if it thinks it is
managing the process handles.

You can test disabling this runtime injection behavior by
turning off the stack probe sizing in Clang:

clang -mno-stack-arg-probe g32.c -o g32.exe

3) The Modern Linker Securites (ASLR/DEP) in 32-bit PE
HeadersEven in 32-bit mode, Clang adds modern PE header
indicators that Borland never did: ASLR (/DYNAMICBASE) and
Data Execution Prevention (/NXCOMPAT).

If you are running an older release branch of TCC, its binary
loader can read those flags, experience a parsing exception
internally, abort the hook, and cleanly return you to a new
line prompt.

The Fix: Tell Clang's linker to explicitly strip these flags
so the PE header mimics a clean, legacy Borland structure:

clang g32.c -o g32.exe -Wl,/dynamicbase:no -Wl,/nxcompat:no

--

---
You received this message because you are subscribed to the Google Groups "SemWare TSE Pro text editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to semware+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/semware/1390336382.541583.1789298429090%40mail.yahoo.com.

[knud van eeden]

I have exclusively used JPSoft tcc.exe the last 25 years or so and never had any such issue with e.g. starting g32.exe.

Only starting in this TSE for Microsoft Windows 4.50.27 the non-starting pops up, so the root cause is clearly in this 4.50.27,

without any doubt.

So it is something with 

 1. the compiler used (I suppose CLang compiler, instead of the usual Borland compiler) .

 2. The compiler options used in that compiler when compiling.

If CLang was used to compile, then the 4 following below options could be compiled in,

if you e.g. send me the resulting g32.exe programs then I can test it further with OpenAI ChatGPT here. 

or use any version of JPSoft tcc.exe on your system and test it in there.

===

Note: this response below was fully generated by OpenAI ChatGPT version 5.6 Sol Light (Plus (paid)):

I tested the 4.50.27 executable directly from both JPSoft TCC 36.52 and the older TCC 35.00.19. It fails identically in both: no editor window appears and no process remains.

TSE 4.50.26 and earlier versions have always started directly from these TCC versions. The 4.50.27 executable starts correctly from Microsoft cmd.exe.

Moreover, this command entered inside TCC works:

C:\Windows\System32\cmd.exe /d /c g32notworking.exe

Therefore, this is not a missing dependency or inherited-environment problem, and it is not a recent TCC regression. It is a compatibility problem introduced by the new 4.50.27 build configuration and exposed by TCC’s direct launch path.

Since TSE now builds with multiple compilers, could you provide equivalent Borland C, GCC, Microsoft C and Clang g32.exe test builds? That would quickly identify whether the problem is Clang-specific or caused by shared linker options or startup changes.

For the Clang build, please first test these settings independently:

1. Disable DYNAMIC_BASE only.
2. Disable NXCOMPAT only.
3. Disable both.
4. Use four-byte stack alignment.
5. Disable stack probing only as a diagnostic.

Binary comparison confirms that 4.50.27 newly enables DYNAMIC_BASE and NXCOMPAT, adds a relocation section, changes the stack settings and imports many Universal CRT API-set DLLs. Changing one option per test build is necessary to identify the actual trigger.

The claim “TCC, not Clang” from the Google-generated response is not established. Your tests instead demonstrate that TSE’s new executable build is the changed side of the compatibility boundary. The multi-compiler builds should now make the cause comparatively straightforward to isolate.

To view this discussion visit https://groups.google.com/d/msgid/semware/CA%2BgEvkYR-WqVRD9iwjwGmumfcuHHoe28tYh-DC2%3DBQOxEbdCTw%40mail.gmail.com.

[knud van eeden]

Response from Google Gemini (Pro (paid)):

Thank you for that context—25 years of flawless operation clarifies everything. This means your previous toolchains (likely an older MSVC version, BCC, or GCC/MinGW) were spitting out classic PE executables with layout constraints that JPSoft's TCC has handled natively for decades.

Modern Clang/LLVM binary generation introduces a few major architectural shifts. When modern Clang builds a Windows binary, it defaults to a strict modern security layout and a distinct CRT (C Runtime) startup sequence that TCC's internal hook manager can inadvertently choke on, causing the silent exit.

Because this is a brand-new Clang build reple as Address Space Layout Randomization (ASLR) and Control Flow Guard (CFG). While standard cmd.exe accepts these natively, older or unpatched versions of TCC that intercept process launches can flag these hardened memory boundaries as invalid and forcibly terminate the execution thread without throwing a visible Windows crash dialog. [1]

• The Fix: Instruct Clang to drop the modern layout protection so it behaves exactly like your 25-year-old compiler legacy:

  clang source.c -o g32.exe -Wl,-no-dynamicbase -Wl,-no-nxcompat
  

3. Subsystem Definition Mismatch

If your legacy compiler was generating a strict Win32-driven console application, Clang might be marking the PE header characteristics in a way that makes TCC believe it requires a separate window allocation or an external handler.

• The Fix: To explicitly ensure it maps directly to standard terminal standard input/output, compile it with absolute static linkage and explicit subsystem enforcement:

  clang source.c -o g32.exe -static -Xlinker /subsystem:console
  

Recommended Test Command

Try rebuilding g32.exe with all optimization and security layers rolled back to match a legacy toolchain layout:

clang source.c -o g32.exe -O0 -Wl,-no-dynamicbase -Wl,-no-nxcompat -static

If you drop that command in and it still fails, please let me know:

• Is your tcc.exe a 32-bit or 64-bit installation?
• Are you using LLVM's native Clang or the MSVC wrapper variant (clang-cl.exe)?

Knowing this will let me give you the exact linker switches to strip out whatever PE headers are upsetting TCC!

[1] https://stackoverflow.com

[knud van eeden]

Note further that I am running (already longer time) the latest JPSoft tcc.exe version 36.52 build 88.

https://jpsoft.com/all-downloads/all-downloads.html

To view this discussion visit https://groups.google.com/d/msgid/semware/232298865.808705.1789399141298%40mail.yahoo.com.

[knud van eeden]

===

> Clang 19.1.7 32-bit, optimized for size or speed

The latest stable release of LLVM/Clang is version 23.1.1, released on September 8, 2026. [1]

===

> Does Clang version 19 had startup problems of its .exe compiled files?

Google 'AI Mode':

===

No, Clang version 19 does not have an inherent, widespread startup problem for compiled .exe files, but specific compilation issues can simulate startup crashes depending on your setup.

The two most common reasons why an executable compiled with Clang 19 might fail or exit instantly upon launch include:

1. Aggressive Compiler Optimizations (Dead Code Elision): Clang 19 introduces stricter undefined behavior tracking and optimization passes. In certain cases, minor conditional logic bugs (such as an incorrect loop boundary or an uninitialized variable) cause the optimizer to conclude that the entire block is unreachable. As a result, Clang 19 can optimize main() down to a single instruction (ret), causing the program to instantly terminate on startup without throwing an explicit error or printing any logs. [1]
2. Missing Runtime Libraries or Environment Discrepancies: When cross-compiling or using Clang on Windows without properly mapping the Microsoft Visual C++ (MSVC) environment or MinGW-w64 paths, the compiled .exe can fail to launch. If the program cannot link to or find standard libraries (like the correct libstdc++ or libc++ headers), it will crash or terminate immediately on startup. [2, 3, 4, 5]

Additionally, if you are experiencing crashes while running the compiler itself, there is a known edge-case bug in Clang 19.1 (clang-cl.exe) when compiling specific C++ code patterns utilizing std::unique_ptr or modules simultaneously on Windows runner systems. [6, 7]

To isolate the issue, could you tell me:

• What operating system and environment (e.g., MSVC, MinGW, MSYS2) are you using?
• What error message or exit code do you get when you run the .exe from a command prompt?
• Does a simple "Hello World" program suffer from the same startup problem?

[1] https://www.reddit.com

[2] https://www.reddit.com

[3] https://www.reddit.com

[4] https://forums.opensuse.org

[5] https://github.com

[6] https://github.com

[7] https://github.com

[S.E. Mitchell]

Probably best to take this discussion private.

I doubt the entire list wants to hear about all this :)

--

To view this discussion visit https://groups.google.com/d/msgid/semware/282321003.813280.1789400541128%40mail.yahoo.com.

[knud van eeden]

There was once an additional 'TSE Beta' mailing list (stopped in 2024) especially for TSE beta releases where this kind of technical programming issues

would be discussed, but that has been sunset by e.g. some user suggestions earlier in 2024. 

And all mailing lists (e.g. 'TSE Linux' mailing list stopped in 2025) have been reduced to 2 more general mailing lists on primarily GoogleGroups and occasionally used FreeLists,Org.

So well then as a consequence more specialized information lands now by design on basically only one general mailling list readable by all subscription TSE mail list users.

For sure not my idea or suggestion thus as that 'TSE Beta' list might have come handy and is more focused on that kind of issues for a then selected smaller group of assumedd specialist TSE users.

I foresee with this very big compiler change starting with 4.50.27 very many big problems, as already some users have reported, of which this startup issue is only one.

It will I expect take longer time to iron everything out and get a stable version.

E.g. expected issues with DLLs due to changing of the calling conventions, it might not be the case, not sure. Recompiling the DLLs

might be necessary.

But if e.g. using the spell.dll DLL works in 4.50.27 then it is probably not an issue.

Of course moving forward, if we can get e.g. 20 to 30 percent faster g32.exe programs that is great and the idea is fully supported.

To view this discussion visit https://groups.google.com/d/msgid/semware/CA%2BgEvka0qFs6i-0grsBVAX4k3w62o8hBAYE23ZXEuhaymx9Lsw%40mail.gmail.com.

[J. David Boyd]

But we do!   How else do we learn this kind of nitty gritty detail?

To view this discussion visit https://groups.google.com/d/msgid/semware/CA%2BgEvka0qFs6i-0grsBVAX4k3w62o8hBAYE23ZXEuhaymx9Lsw%40mail.gmail.com.

--

What's so funny about peace, love, and understanding?