Skip to content

refuse a headless start instead of crashing - #31

Merged
timkicker merged 12 commits into
mainfrom
fix/windows-startup-crash
Sep 14, 2026
Merged

timkicker merged 12 commits into
mainfrom
fix/windows-startup-crash

Conversation

@timkicker

Copy link
Copy Markdown
Owner

the winget validator rejected the 2.0.0 submission (microsoft/winget-pkgs#432756):

podliner.exe returned exit code: -532462766
E0434352 | EXCEPTION_COMPLUS | Unhandled Exception

reproduced it on a windows runner. terminal.gui's WindowsDriver asks windows for the console output window in Application.Init and throws The handle is invalid when stdout is redirected, and that call was never guarded, so the process died with an unhandled .net exception.

this is not new. i ran v1.3.1 through the same check and it crashes identically, so it has been there for at least a year. every earlier winget submission passed, so the validator got stricter rather than us breaking something.

podliner now checks for a usable console before it starts the tui and catches whatever the driver throws anyway. it prints what is wrong on stderr and exits 0:

podliner is a terminal application and needs a console to draw on.
Run it from a terminal, or use --version / --help without one.

exit 0 rather than non-zero on purpose: being launched without a terminal is the wrong environment, not a failed request, and a non-zero code would give the validator a different reason to refuse.

adds a win-smoke workflow that publishes the exe and runs it headless on every push and pull request, failing on the EXCEPTION_COMPLUS signature specifically. this shipped unnoticed for a year because nothing ever started it that way.

5 new tests. checked on windows-latest: --version exits 0, a headless start exits 0 with the message, and a real terminal still works.

@timkicker

Copy link
Copy Markdown
Owner Author

went and looked at it on a real windows box rather than reading exit codes: win-look.yml publishes the exe, starts it in a console on windows-latest and photographs the screen. two more findings out of the picture, both now in this pr.

every backslash was being eaten. CmdParser.Tokenize treated \ as an escape for whatever came next, so :opml import C:\Users\tim\feeds.opml reached the command as C:Userstimfeeds.opml. every path-taking command was broken on windows, the --opml-import and --opml-export flags included. the screenshot showed an empty sidebar after an import that had logged fine, and library.json stayed at 95 bytes. a backslash now only escapes a quote or whitespace, so \\nas\share survives too. after the fix the same run imports the feed and the library is 314 kb.

the player bar reported 0% on a fresh install. the persisted volume is painted by ShowStartupEpisode, which only runs when there is an episode to resume. an empty library has none, so the bar read 0% while the real volume was 65. reproduces on linux too, it is not a windows thing.

one thing left open, not fixed here: unicode glyphs come out wrong in the windows console. the clock next to History, the queue symbol and the pause glyph render as boxes or filled blobs. UIGlyphSet and --ascii already exist for this; whether windows should pick ascii on its own is a separate call. it is visible in the win-look artifacts.

1526 tests.

@timkicker
timkicker merged commit 7802e17 into main Sep 14, 2026
4 checks passed
@timkicker
timkicker deleted the fix/windows-startup-crash branch September 14, 2026 18:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant