RE: Bug: texworks.exe wrapper errs if file is already open in TeXworks

Update: After more tracing, this is identified as a bug in TeXworks and has been fixed. (It will exit with code 0 after handing data to the existing instance.)

-----Original Message-----
From: Ji Luo 
Sent: Friday, September 26, 2025 3:53 AM
To: [email protected]
Subject: Bug: texworks.exe wrapper errs if file is already open in TeXworks

This bug affects file associations on Windows. To reproduce:

1. Let example.tex be a TeX file. Close all instances of TeXworks.
2. Right-click example.tex in Explorer, choose Open with -> texworks.exe.
3. Do step 2 again.

In step 2, TeXworks opens normally. In step 3, it's expected that the existing instance of TeXworks flashes the taskbar. In TeX Live 2025 installed on Windows 11 version 24H2 (x64), there's a warning message box saying

> P:\ath-to-TeX-Live\bin\windows\runscript.tlu:933: command failed with exit code <some-number>:
> texworks "P:\ath-to-file\example.tex"

This is because ProgID "TL.TeXworks.edit.2025" sets the command to "P:\ath-to-TeX-Live\bin\windows\texworks.exe" "%1". This "texworks.exe" is a wrapper that runs "runscript.tlu", which eventually runs "P:\ath-to-TeX-Live\tlpkg\texworks\texworks.exe" (let's call this actual TeXworks) with the arguments after setting up environment variables. The actual TeXworks will return a non-zero exit code if it transfers control to an existing instance, causing "runscript.tlu" to create a message box in GUI mode.

This is annoying to the user. Presumably, any error should be displayed by the actual TeXworks to the user, and the wrapper should display an error *only if it fails to launch the actual TeXworks at all*, not when the actual TeXworks is launched but subsequently fails. It's not clear if exiting non-zero when the work is relayed to an existing instance is intended behavior of TeXworks (i.e., presumably there's failure in the reproduction scenario).

In addition, if the actual TeXworks happens to exit with non-zero exit code after a long time, the wrapper will still display a warning message box. This is also unnecessary --- when a GUI program on Windows crashes, typically there's Windows Error Reporting dialog informing user of this fact, so the wrapper's message box is redundant. This phenomenon can be reproduced by performing steps 1 and 2, then calling TerminateProcess on the child process with exit code 55555555. (Using TerminateProcess is just a way to make the actual TeXworks appear to have crashed. In an actual scenario, TeXworks might crash due to its own bugs, or if it becomes a victim of shell extensions in its "open file" dialog, etc.)

The suggested fix is to make "runscript.tlu" work as follows in GUI mode: if the intended process is successfully created (i.e., the program is found by system, it's accessible to current user, it's not an invalid PE image, etc.), then just relay the exit code without creating any further UI; if the intended process is not created, then display a message box and exit with non-zero code.

-Ji Luo

P.S. Personally, I use TeXworks as a PDF viewer. This problem was first discovered after I switched from MiKTeX to TeX Live and tried to open a PDF twice (this happens naturally if the last line of command is "pdflatex main & start main.pdf" and you repeat this command after editing files).