v2.6.0.0: feedback on the new line-endings option and "HashCheck Options" context-menu entry

[SirKocur]

Hi Mounir,

First - thank you for picking HashCheck back up. The project had been quiet
for a long time and it's great to see active releases again.

I'd like to ask about two changes introduced in v2.6.0.0 (vs. v2.5.0.1) and
share some friendly feedback. This isn't a complaint - I'd genuinely like to
understand the reasoning before forming a strong opinion.

1. New "Checksum file line endings" option (CRLF / LF)

Could you share the use case that motivated adding this toggle? The one I can
think of is users who want byte-identical output with files produced by
certutil, PowerShell Get-FileHash, or other native Windows tools that emit
CRLF - but I'm not sure how common that actually is in practice.

My concern is that one of HashCheck's biggest strengths compared to other
alternatives (e.g. OpenHashTab) has always been a deliberately small options surface.
UTF-8 + LF is the cross-platform de facto standard - Git, sha256sum, BSD
md5, and basically every Unix-side verifier - and reading already works for
both line endings, so nothing breaks for existing users either way.

Would you consider defaulting to LF and removing the toggle entirely?

2. New "HashCheck Options" entry in the shell context menu

The Options dialog is now reachable directly from the right-click menu of any
file. I'd push back on this one a bit more:

• The Windows 11 context menu is already a constrained UX surface (the
  "Show more options" two-step), so every extra entry has a real cost for
  every other action a user performs on that file.
• Settings dialogs are conventionally opened from inside an app, not from the
  shell. There's precedent for shell-integration settings under a submenu
  (TortoiseGit, 7-Zip), but those don't sit at the top level alongside verbs
  like "Verify Checksum File."
• A user opens these settings maybe once after install. Putting them one
  click away from every file in the system feels disproportionate to how
  often they're actually used.

What a minimalist v2.6 could have looked like

For comparison, here's a mockup of how the same upstream additions (XXH3-64,
XXH3-128) could be integrated without expanding the Options surface:

The two new algorithms slot into the existing checksum grid as a third
column. No new sections, no new toggles - the dialog stays at the same
conceptual complexity it had in v2.5. A returning user opens it and
immediately knows where everything is.

This is what I meant by HashCheck's "deliberately small options surface"
earlier - it's not just about line count in the dialog, it's about the
shape. Adding a fourth section ("line endings") and a new top-level shell
entry both shift HashCheck toward a different category of tool. The reason I
(and I'd guess others) chose HashCheck over OpenHashTab in the first place
was specifically that it didn't try to be configurable for every taste.

If the new shell integration entries serve real use cases I'm not seeing,
fair enough - but the radio control already in the dialog ("Show / Show in
extended / Never show") could be extended to cover them per-entry, which
would let power users opt in without burdening the default install.

---

Also - and I may be misreading the screenshot - it looks like
"Verify Checksum File" and "Create Checksum File…" appear twice in
the menu (once near the top, once below "Copy as path"). If that's not
intentional, it might be a separate bug worth tracking:
#34

Happy to hear the reasoning - there may well be a use case I'm not seeing.
Thanks again for the work on this fork.