[fasmg][Win64]

Example binary functionality of Most Recent Used (MRU) lists with a fixed size of one. It's an easy way to preserve dialog settings across multiple executions with very little effort. Should work from before WinXP to present.

Note: registry file included to clear any testing.

Extending the idea:

1. add a dropdown and support up to 29 configuration sets for the dialog.

2. wrap dialog macros to create save/restore functions automatically.

It works on my Windows 10.

Nice tutorial code.

The MRU list has been under documented for a long time. This is in spite of the legal settlement against MS, and the continued updates and modernization of the common controls library. MRU's are very useful to persist state and give the user a cohesive feel even when the UI parts are completely separate in their source or functionality.

Now that I think about it, I should add some indicator as to where the present data is from: default, registry or modified.

A number of MRU examples for fasm2 showing three qualities of the in-process LRU cache:

1. Promote-on-touch dedup
2. Comparator as keying function
3. Bounded LRU eviction


window_topology.asm - `WINDOWPLACEMENT` MRU keyed by `(monitor_count, per-monitor rect, DPI, primary)`.

ab_toggle.asm - Two-slot A/B config toggle. `uMax=2`; re-adding the previous slot promotes it.

re_breadcrumb.asm - Disassembly navigation: comparator on `(module_hash, RVA)`; in-blob `hit_count` survives revisits.

cmd_palette.asm - Command palette with `score = uses * 0.85^pos`. SSE2 doubles + insertion sort, split-int format around wsprintfW's no-`%f`.

connections.asm - SSH/SQL profiles. Composite `(host, port, user)` key; preserves `cwd` / `last_cmd` on reconnect when caller omits them.

editor_state.asm - Per-file cursor / scroll / fold mask. `MRU_CACHEWRITE` so writes batch until `FreeMRUList`. `open` / `move` / `fold` / `list`.

find_replace.asm - Variable-length blob `[u16 fl][find][u16 rl][repl]`; comparator memcmps the find prefix only, length-breaks ties.

snippets.asm - Variable-length blob with `SnippetHdr` + body + deps payload; use-counter bumps on each insert.

_del_verify.asm - Functional test: prove `DelMRUString` works on binary MRU data despite its name. Prints PASS / FAIL.

_lazy_probe.asm - Diagnostic: resolve all 14 MRU ordinals, print address / RVA / alias detection.

rtfedit: a fasm2 RichEdit MRU tour-de-force

I’ve been building a small Win64 RichEdit editor as a practical tour of the old comctl32 MRU API. It started as a simple recent-files example, but has grown into a multi-MRU state demo for a real GUI program.

What it demonstrates

• Multiple independent MRU instances in one application
  
• Recent files with active-document restore on startup
  
• Cursor-position persistence per recent file
  
• Theme toggle as a two-slot MRU
  
• Persistent editor settings, including word wrap and file dialog filter choice
  
• Find/replace history
  
• Named font MRU with per-slot apply options
  
• Named text-color MRU keyed by COLORREF
  
• New-file templates backed by MRU metadata plus saved RTF bodies
  
• Transactional save path and dirty-document policy
  

The interesting part is that most of the state is not using a custom config file. It is built around the undocumented-but-long-lived comctl32 MRU functions: CreateMRUListW, EnumMRUListW, FindMRUData, AddMRUData, DelMRUString, and FreeMRUList.

Why I think it is useful

This is not just a “recent files” menu. The program treats MRU lists as small persistent LRU caches for application state. Each list has its own comparator/key policy, so the same API supports recent files, themes, settings, find/replace pairs, fonts, colors, and templates.

The shared helper layer is in mru_multi.inc, and the larger feature modules are split into:

• mru_fonts.inc
  
• mru_colors.inc
  
• mru_templates.inc
  

Current status

The editor now has enough behavior to be useful as a testbed: open/save, recent restore, find/replace, formatting, colors, templates, settings, and startup persistence. Remaining ideas include bookmarks and a command palette MRU.

If you have ever wondered whether the comctl32 MRU API can carry structured application state instead of just strings, this project is meant to be a readable working example - far beyond the example stubs above.

rtfedit progress update: MRU state is becoming an editor architecture

A while back I posted about rtfedit, a small Win64 RichEdit editor written in fasm2 as a practical tour of the old comctl32 MRU API. Since then it has moved well past “recent files demo” territory.

The project is now using MRUs as a general persistent-state substrate for a real editor surface.

Major progress since the first post

• A source-owned document model now tracks open documents, paths, dirty state, saved generation, selection, and active document state.
  
• The app supports multiple documents, a top-level Document menu, Close, and Close All.
  
• Recent files now restore the last active document on startup, including cursor/selection state.
  
• Template MRUs allow the current document to become a named new-file template.
  
• Editor settings persist word wrap, file-dialog filter choice, and console visibility.

The new console/diagnostics surface

The editor now has a docked RichEdit-backed console proxy. It is not just a separate input box bolted onto the side. Commands are entered directly in the console RichEdit prompt, while previous transcript text is protected.

The console surface currently supports several internal commands.

Non-internal input is routed through the active terminal profile. Terminal profiles are themselves MRU-backed and currently seed CMD, PowerShell 7, and Windows PowerShell targets.

The transcript is styled RichEdit content. Output, prompts, diagnostics, warnings, errors, and internal messages can each use different presentation. A lot of work went into making theme changes update existing transcript colors efficiently by working with RTF color-table/style behavior instead of repainting everything one span at a time.


Source organization changed significantly

The MRU layer has been refactored so adding a new MRU no longer means editing a central app-specific table.

Each feature file owns its own:

• blob structure
  
• constants
  
• comparator
  
• data emitter
  
• scratch state
  
• feature helpers/UI

Current MRU-backed state

• Window placement keyed by monitor topology
  
• Recent files with active-document restore
  
• Editor settings
  
• Theme toggle
  
• Find/replace history
  
• Named font configurations
  
• Named text colors
  
• File templates
  
• Terminal profiles
  
• Console command history

Why this still interests me

The comctl32 MRU API is usually thought of as a “recent files menu” helper. This project keeps showing it can be more than that: a family of small persistent LRU caches, each with its own comparator and payload policy.

The important trick is to stop thinking of an MRU entry as just a string. It can be a structured blob with a key prefix, payload, use counts, display names, hashes, paths, selection state, formatting policy, or whatever else fits the small-cache model.

It is still a small editor, but it has become a fairly dense working example of MRU-driven application state in fasm2. Next areas are command-history presentation, terminal-profile-owned histories, bookmarks, and eventually the command palette / diagnostics.