Sally 1.0.27 - Experimental Unicode Migration

Community announcement: #109

Multi-platform Release CI: https://github.com/0xeb/sally/actions/runs/35792894558 (x64, x86, and ARM64 passed)

Warning

Experimental Unicode migration release

Sally 1.0.27 contains the largest internal change in the project so far. Core
file names, paths, UI text, persistence, shell integration, and bundled
plugins were migrated to native Unicode and long-path ownership.

The change was extensively reviewed and tested, but regressions and breaking
edge cases are still possible. Please do not replace your only trusted Sally
installation immediately if you depend on it for critical file operations.
Keep 1.0.26 available until you have tested your normal workflows.

Bug reports are especially valuable for this release. If something worked
in 1.0.26 and fails in 1.0.27, please open an issue and include the Sally
version, Windows version, architecture, exact steps, the affected path or file
name shape, and whether the name contains non-ASCII characters, emoji, a long
path, a network path, or a plugin/archive boundary.

Highlights

• Native Unicode file names, paths, panel text, dialogs, viewer/search text,
  registry values, histories, shell integration, and bundled-plugin paths.
• Long-path-safe dynamic ownership instead of MAX_PATH-bounded semantic path
  buffers.
• Unicode-aware search and case folding, including UTF-8 database-viewer
  searches.
• Wide-native bundled plugins and explicit codecs at real byte boundaries such
  as FTP and archive formats.
• Improved behavior for non-ASCII install paths, UNC/network paths, shell
  operations, drag/drop, clipboard data, and external viewers/editors.
• Ten translated language packs rebuilt and versioned for 1.0.27.

Important behavior changes

Unicode sort order

Sorting now compares real Unicode names rather than damaged active-code-page
projections. Non-ASCII names may appear in a different order from older Sally
versions. This is intentional and there is no option to restore the previous
code-page-dependent order.

Unicode clipboard and drag/drop text

Panel, archive, and plugin-filesystem paths use Unicode clipboard text where
older paths could publish only CF_TEXT. Legacy text is still co-published
where appropriate, but very old external programs that only understand ANSI
clipboard data may behave differently.

Configuration Editors/Viewers priority lists (#108)

The blue Up/Down arrows now visibly reorder the Editors and Viewers priority
lists. The previous code moved the internal model but left owner-drawn rows in
their old order; editing after a move could also update the wrong association.

Fixed by 9930c1f7a.

Other notable fixes

• Non-ASCII paths work through copy, move, delete, rename, Find, viewers,
  editors, directory history, archive operations, and startup/configuration
  paths.
• UTF-8 regular-expression case folding works by Unicode code point rather than
  through an ANSI byte table.
• Database Viewer Find no longer skips UTF-8 cells containing text outside the
  active Windows code page.
• External archivers refuse an unrepresentable path instead of silently using a
  best-fit alias that could name a different file.
• Multi-volume archive dialogs, password input, shell-extension IPC, overlay
  icons, configuration persistence, and numerous plugin UI paths retain exact
  Unicode text.
• Editor/viewer mask priority changes remain synchronized between the visible
  list and stored configuration.

Plugin compatibility

• Bundled plugins are wide-native.
• Existing pre-v108 binary plugins can still load through an isolated
  compatibility adapter.
• Compatibility conversion is exact-or-refuse; it is not an ANSI ownership
  model inside Sally.
• A plugin requiring a newer host refuses to load instead of calling an
  incompatible interface optimistically.

If a third-party plugin behaves differently in 1.0.27, please identify the
plugin name and version in the bug report.

Known limitations and risk areas

• Release artifacts are built for x64, x86, and ARM64. Automated build and
  artifact validation cover all three; the deepest runtime/Sandbox testing
  remains on x64.
• FTP and archive formats remain byte-oriented where their protocols require
  it; text is encoded/decoded at explicit boundaries.
• External ANSI-only tools may reject a path they cannot represent. Sally now
  fails visibly instead of silently changing the path.
• Old persisted settings are imported for upgrade compatibility, while new
  values are written in current native formats.
• Existing pre-v108 third-party plugin binaries remain supported through the
  frozen compatibility layer.
• PictView is not included because its image engine source is unavailable.
• WinSCP integration remains unported.

Before upgrading

1. Keep a copy of Sally 1.0.26.
2. Back up or export your Sally configuration if it is important to you.
3. Test representative local, network, archive, plugin, viewer/editor, and shell
   workflows before relying on 1.0.27 for critical work.

Reporting a regression

Please open an issue at:
https://github.com/0xeb/sally/issues

Useful details:

• Sally version and architecture.
• Windows version and system locale/code page.
• Whether the problem also occurs in 1.0.26.
• Exact reproduction steps and expected/actual result.
• The relevant file/path shape, sanitized if necessary.
• Whether the path is local, UNC/network, archive-contained, plugin-provided,
  longer than 260 characters, or contains non-ASCII/emoji characters.
• Screenshots and Sally’s Help > Report a Bug output when available.

Validation summary

• Native MSVC Release builds and populated runtimes completed for x64, x86, and
  ARM64.
• Private Unicode and architecture gate: 239/239 passed.
• Same-guest pre-Unicode comparisons found no lost file-operation ability in
  the current build and multiple Unicode/long-path gains.
• 11/11 core language packs load with the exact 1.0.27 binary version.
• Release-artifact checks passed for binary notices, shell-extension freshness,
  and language-pack compatibility.

Full Changelog: v1.0.26...v1.0.27