rubrapack 0.39.0

Explorer's right-click menu - the classic one and the Windows 11 one - from one table, without code and without a certificate.

Added

• [menu.ID]: an item of Explorer's right-click menu that starts a program of the package.

  [menu.Convert]
  on = [".png", ".jpg", "folder"]   # file types, "*", "folder", "background", "drive", "assoc:ID"
  text = "Convert with Example"
  text-ko = "Example 로 변환"
  target = "file:MainExe"
  args = "--convert \"%1\""

  Sub-menus (parent), what several selected items mean (multi), Shift-only items (extended), an icon, a text per language.

  • The classic menu (Windows 10; "Show more options" on Windows 11) gets registry verbs. No code of the package runs inside Explorer.
  • The Windows 11 menu shows only what a package with identity declares, each item a COM class. rubrapack brings that class: its menu part rubrapack_menu.dll serves every item (in dllhost.exe, not in Explorer), shows the text in the user's display language and starts the program.
    • An MSIX carries the part and declares the items.
    • An MSI installs the part and a small identity package (rubrapack_menu.msix: a manifest and logos) beside the program, registers that package when it is installed - for every user of the computer - and removes it when it is removed. No certificate is needed: the package is unsigned in the form Windows accepts from an installation with administrator rights; with --key and [msix] publisher it is signed.
    • Where the package cannot be registered (Windows before 10 version 2004, a per-user installation by a user without administrator rights) the installation goes on and the items are in the classic menu only.
  • Each item shows once: where the package is registered, the registry verbs are switched off.

• [assoc.ID]: content-type, perceived-type, and default = false (offer the program under "Open with" without taking the type).

Changed

• Every [assoc.ID] now also lists its prog-id under the extension's OpenWithProgids (one more registry value per extension), so the program shows under "Open with" where another program has the type.

Good to know

• On Windows 11 an item appears some seconds after the installation ends. Two or more items of one package for the same kind of thing are put by Windows under one entry named after the product; that entry has no icon yet.
• "drive" items and windows11 = false items are in the classic menu only.
• The menu part can log what it does: set the value MenuLog (a file's path) under HKCU\Software\rubrapack.

Checked on Windows 11 (26200): a silent installation registering the package for all users; the item in the Windows 11 menu in Korean; the program started with the selected folder, in that folder; two items of one file type grouped under the product's name; each item once in the classic menu; an upgrade; removal leaving neither package nor registry values nor files; a per-user installation by a standard user (classic menu only); an MSIX with the same items.

Manual

• Web: https://rubidus-api.github.io/rubrapack/ - Reference, "Explorer's right-click menu"; tutorial chapter 11.
• PDF: rubrapack-manual-0.39.0-en.pdf, rubrapack-manual-0.39.0-ko.pdf (attached)

Downloads

File	For
rubrapack-0.39.0-windows-x64.exe	Windows x64, tested on Windows 11 (single file, cross-built with MinGW-w64)
rubrapack-0.39.0-linux-x86_64	Linux x86-64, glibc 2.38 or later (Debian 13, Ubuntu 24.04 and later)
SHA256SUMS	checksums of the files above

rubrapack 0.38.0

Security fixes from a review of the whole source. Packages built with an earlier version carry the old helper parts: build them again with this one.

Security

In the parts a package carries (helper DLL, cleanup program, setup program):

• Cleanup task, per machine. The folder for the program that runs as SYSTEM was read from the environment of the user who started the installation (%ProgramData%), and a level of it that a user had created first was accepted. The SYSTEM step now asks Windows for the folder itself, and every level (rubrapack, cleanup, {ProductCode}) must be made by it or already be a real folder owned by SYSTEM, Administrators or TrustedInstaller; otherwise no task is registered.
• [remove] upgrade = false, per machine. The backup folder under <volume>\Config.Msi is now checked the same way on every move, move back and deletion; if it is not safe the file is left for the restart.
• Cleanup task, per user. It ran with the highest available rights from a folder the user's own programs can write. It now runs without elevation (and can still delete itself: the task's access list names the user).
• setup.exe (chain). Running elevated, it unpacked the packages into %TEMP%, where a program of the same user could replace one between its check and its installation. Its folder is now for SYSTEM and Administrators only.

In the command-line tool:

• new --from. An icon's key in the package was used as a file name, so a package could have an .ico file written outside dist/_icons. The name is now one plain component.

Changed

• guard = true, per machine: a folder that does not exist yet passes only when the deepest existing folder above it is owned by SYSTEM, Administrators or TrustedInstaller. Installing under Program Files is unaffected; a first installation into a new folder inside a folder someone else owns now stops with the guard's message (1603).
• The per-user cleanup task no longer runs elevated (above).

Fixed

• A per-user [remove] upgrade = false made its backup folder so that a standard user could not use it.
• Helper DLL and cleanup program: a path longer than the buffer is skipped instead of cut short; product and upgrade codes are checked to be GUIDs.
• MSIX launcher for console programs: a redirection or a pipe (app > out.txt) now reaches the program.
• build of a merge module without components, and a [files] pattern when memory runs out, no longer read through a null pointer.

Checked on Windows 11: the cleanup task per machine and per user (also installed by a standard user), a folder planted by another owner refused, a folder left by an earlier version accepted and locked, [remove] upgrade = false with rollback, the preflight, the guard with a new folder inside a user's folder. The readers of packages and sources were fuzzed further (a second harness: the source reader, the codecs, ZIP, and inspect, lint, extract, new --from on damaged files).

Manual

• Web: https://rubidus-api.github.io/rubrapack/ - Reference, "Guarding the install folder" and the cleanup task.
• PDF: rubrapack-manual-0.38.0-en.pdf, rubrapack-manual-0.38.0-ko.pdf (attached)

Downloads

File	For
rubrapack-0.38.0-windows-x64.exe	Windows x64, tested on Windows 11 (single file, cross-built with MinGW-w64)
rubrapack-0.38.0-linux-x86_64	Linux x86-64, glibc 2.38 or later (Debian 13, Ubuntu 24.04 and later)
SHA256SUMS	checksums of the files above

rubrapack 0.37.0

A look before the installation goes on: which programs use the product's files, and whether it can be done safely.

Added

• The preflight. Before an installation, an upgrade or a removal changes anything, the package looks which programs use the product's files - its own programs that are running, and other programs that have one of its DLLs loaded - shows how many and their names, and asks whether to close them all. Yes asks their windows to close and ends what is left a few seconds later; No goes on without closing (the files are replaced anyway; those programs keep the old ones until they are reopened); Cancel stops with nothing changed.
• For an installation or an upgrade it also checks that each existing package folder is one the installer may delete in, and that the older version still has its cached package. If not, the message says what is wrong and to remove the product first, and nothing is installed.
• [package] close-programs = "ask" | "always" | "never" sets the answer for a package; preflight = false leaves the step out. For an input method or a shell extension use "never": nearly every open program has its DLL loaded, and the files are replaced safely without closing anything.

Changed

• A silent run (/qn) now stops with an error (1603) when programs use the product's files, naming them in the log. Say what to do on the command line - msiexec /i app.msi /qn RPCLOSE=yes closes them all and goes on, RPCLOSE=no goes on without closing (what /qn did before) - or set close-programs in the package.

Checked on Windows 11: a silent upgrade stopping with the program named and the old version untouched; RPCLOSE=no and RPCLOSE=yes; the product's own program; removal; a missing cached package refused before anything changes; the question box and Yes with a window.

Manual

• Web: https://rubidus-api.github.io/rubrapack/ - Reference, "Before it goes on: the preflight"; tutorial chapter 12; formats, "Files in use".
• PDF: rubrapack-manual-0.37.0-en.pdf, rubrapack-manual-0.37.0-ko.pdf (attached)

Downloads

File	For
rubrapack-0.37.0-windows-x64.exe	Windows x64, tested on Windows 11 (single file, cross-built with MinGW-w64)
rubrapack-0.37.0-linux-x86_64	Linux x86-64, glibc 2.38 or later (Debian 13, Ubuntu 24.04 and later)
SHA256SUMS	checksums of the files above

rubrapack 0.36.0

Features that are on by default when a condition holds.

Added

• [feature.ID] default-when = "<condition>" (with level above 1). A feature that is off by default is on by default at the first installation when the condition holds. Made for a part that used to be a package of its own and is now a feature of this one (replaces, 0.35.0): a search finds the old package's mark, the feature turns on, and even a silent upgrade keeps what the user had. Checked on Windows 11 with jamotong 0.70.0: a silent upgrade from a version with both separate Chinese packs ends with one product and both features installed.

Manual

• Web: https://rubidus-api.github.io/rubrapack/ - Reference, "Features"; tutorial chapter 8.
• PDF: rubrapack-manual-0.36.0-en.pdf, rubrapack-manual-0.36.0-ko.pdf (attached)

Downloads

File	For
rubrapack-0.36.0-windows-x64.exe	Windows x64, tested on Windows 11 (single file, cross-built with MinGW-w64)
rubrapack-0.36.0-linux-x86_64	Linux x86-64, glibc 2.38 or later (Debian 13, Ubuntu 24.04 and later)
SHA256SUMS	checksums of the files above

rubrapack 0.35.0

Add-ons removed with their product, packages that replace other products, and removal pages that say "removal".

Added

• [package] parent and remove-addons = true. An add-on (a language pack, a plug-in shipped as a package of its own) names its main product's upgrade code; the main product with remove-addons = true removes its add-ons when it is really removed - not when an upgrade replaces it - whichever way it was removed (Installed apps, its maintenance page, msiexec /x). Its cleanup task starts at once, waits for the removal to end and runs msiexec /x /qn for each add-on still installed; one that cannot be removed then is tried again later. Checked on Windows 11: an upgrade keeps the add-ons, a removal removes them within 40 seconds.
• [package] replaces = ["{UpgradeCode}", ...]. Products this package takes the place of - for example add-ons that become features of it. Installing it removes every installed version of them in the same run, so no two products own the same files. Checked on Windows 11: a new version that replaces two add-ons ends with only itself installed.

Changed

• Removal pages say "removal". During a removal the progress page and the last pages read "Removing ...", "Removal complete", "Removal cancelled", "Removal failed - ... rolled back" (Korean too), instead of the install texts.

Manual

• Web: https://rubidus-api.github.io/rubrapack/ - Reference, "Add-ons removed with their product" and "Taking the place of other products"; tutorial chapter 3.
• PDF: rubrapack-manual-0.35.0-en.pdf, rubrapack-manual-0.35.0-ko.pdf (attached)

Downloads

File	For
rubrapack-0.35.0-windows-x64.exe	Windows x64, tested on Windows 11 (single file, cross-built with MinGW-w64)
rubrapack-0.35.0-linux-x86_64	Linux x86-64, glibc 2.38 or later (Debian 13, Ubuntu 24.04 and later)
SHA256SUMS	checksums of the files above

rubrapack 0.34.0

Removal from Installed apps through the package's own dialogs, and a cleanup task fix.

Added

• [arp] no-remove = true. Uninstall in Settings > Installed apps runs msiexec /qb /x {ProductCode} - Windows Installer's own reduced window, not the package's dialogs - and when a program with a window holds one of the files (for an input method or a shell extension: nearly every program), Windows shows its own files-in-use box, in English, with Cancel as the default. With no-remove, Uninstall is turned off for the product and it is removed through Modify, which runs the package's dialogs: Remove, then the package's files-in-use dialog with Continue as the default. Needs [package] ui = minimal, installdir or features and no no-modify. Checked on Windows 11: Settings runs msiexec /qb /x and ignores the product's UninstallString; with the key, Uninstall is greyed out and Modify opens the package's maintenance page.

Fixed

• The cleanup task could miss what its own removal left - for example the copy of a DLL that was still loaded, which then waited for the restart. It told its own queued deletions from earlier ones by their position in Windows' list, and positions move when another cleanup task or a rescue takes an entry out. It now records the earlier deletions by path before the installation runs.

Manual

• Web: https://rubidus-api.github.io/rubrapack/ - Reference, "Installed apps entry and properties" and "Cleaning up later"; tutorial chapter 5; formats, "Files in use".
• PDF: rubrapack-manual-0.34.0-en.pdf, rubrapack-manual-0.34.0-ko.pdf (attached)

Downloads

File	For
rubrapack-0.34.0-windows-x64.exe	Windows x64, tested on Windows 11 (single file, cross-built with MinGW-w64)
rubrapack-0.34.0-linux-x86_64	Linux x86-64, glibc 2.38 or later (Debian 13, Ubuntu 24.04 and later)
SHA256SUMS	checksums of the files above

rubrapack 0.33.0

Smoother installs, upgrades and removals while programs hold the package's files - input methods, shell extensions.

Added

• The cleanup task. A removal, an upgrade or a repair that has to leave a file for the next restart (because a running program holds it) registers a scheduled task, rubrapack cleanup {ProductCode}. It deletes those files - and the installer's backup copies of them in Config.Msi - as soon as nothing holds them, then the folders that stayed only because of them, and then itself. Without anything to do it goes at its first run; after 30 days it leaves the rest to the restart. It runs as SYSTEM for per-machine packages and as the user for per-user ones, and deletes only what its own installation left. [package] cleanup = false leaves it out.
• Rescue. When a product is removed while a program holds one of its files, Windows queues the file's deletion for the next restart. If another package then installs an identical file at that path, Windows Installer keeps the file already there and the queued deletion too - the restart deletes the new owner's file. Per-machine packages now take such deletions back as they install, and the cleanup task never deletes a file an installed product has at that path.
• [remove.ID] upgrade = false: the removal does not run when an upgrade removes this version, only when the product is really removed - for files the new version still wants, or that programs still running the old version may read again.

Changed

• The files-in-use dialog now says what really happens and defaults to going on: Continue (the engine's Ignore) is the default button, and the text says the files are replaced now, programs already open keep the old ones until they are reopened, and no restart is needed. The old text told the user to have the files replaced at the next restart, which rubrapack packages never needed.

Checked on Windows 11 with a held DLL and held data files, per machine and per user: upgrades and removals with no restart prompt; the cleanup task deleting what was left once the holders exit; a package that installs into another product's folder touching only its own files; an identical file reinstalled by another product surviving.

Manual

• Web: https://rubidus-api.github.io/rubrapack/ - Reference, "Cleaning up later" and "Removing and copying"; tutorial chapters 4 and 12; formats, "Files in use".
• PDF: rubrapack-manual-0.33.0-en.pdf, rubrapack-manual-0.33.0-ko.pdf (attached)

Downloads

File	For
rubrapack-0.33.0-windows-x64.exe	Windows x64, tested on Windows 11 (single file, cross-built with MinGW-w64)
rubrapack-0.33.0-linux-x86_64	Linux x86-64, glibc 2.38 or later (Debian 13, Ubuntu 24.04 and later)
SHA256SUMS	checksums of the files above

rubrapack 0.32.0

Preview handlers in MSIX packages.

Changed

• A [handler.*] with kind = "preview" now goes into an MSIX (desktop2:DesktopPreviewHandler, in the package's file type association beside the thumbnail handler) instead of being refused. Checked on Windows 11: Explorer's preview pane shows the packaged handler's preview, as it does the MSI's.
• Give a packaged preview handler's class threading = "sta". A package runs its COM classes in a surrogate (dllhost); with both, mta or neutral the surrogate can call the handler on a thread without a message loop, and its preview stays blank (seen in our tests). rubrapack warns (RP1612) when an MSIX preview handler's class is not sta. The MSI is not affected: Windows' preview host always calls on its own single-threaded apartment.
• A property handler is still MSI-only (RP1612 in an MSIX), now with a measured reason: in Explorer's Properties → Details, the same handler gave its values when installed by the MSI and none from the package (with both and with sta).

Manual

• Web: https://rubidus-api.github.io/rubrapack/ - Reference, "Explorer handlers"; tutorial chapter 11.
• PDF: rubrapack-manual-0.32.0-en.pdf, rubrapack-manual-0.32.0-ko.pdf (attached)

Downloads

File	For
rubrapack-0.32.0-windows-x64.exe	Windows x64, tested on Windows 11 (single file, cross-built with MinGW-w64)
rubrapack-0.32.0-linux-x86_64	Linux x86-64, glibc 2.38 or later (Debian 13, Ubuntu 24.04 and later)
SHA256SUMS	checksums of the files above

rubrapack 0.31.0

Conveniences: what an error means, answers in JSON for scripts, and a schema for editors.

Added

• rubrapack explain RP1612 says what a diagnostic code is about, shows every message that carries it, what to do, and where the manual says more. Without a code it lists the ranges.
• --json on lint (a source, a package, --previous, an MSIX) prints one JSON object - the file, the exit code, the error and warning counts, and each diagnostic with its line, column, severity, code and message - with the usual exit code. On inspect <file.msi> it gives every table, one table, or the summary information as JSON.
• rubrapack schema prints the JSON Schema of sources: every table, its keys, which are required, which take true/false or a number. Saved as rubrapack.schema.json and named on a source's first line (#:schema ./rubrapack.schema.json), editors built on Taplo - Visual Studio Code's Even Better TOML among them - complete keys while you type and mark misspelled ones.

The message table of explain and the schema are made from rubrapack's own code, and the tests fail when either falls behind it. Every source in the test suite validates against the schema.

Manual

• Web: https://rubidus-api.github.io/rubrapack/ - tutorial chapter 18, "What an error means" and "For scripts"; chapter 19, "In an editor"; Reference, "Command line".
• PDF: rubrapack-manual-0.31.0-en.pdf, rubrapack-manual-0.31.0-ko.pdf (attached)

Downloads

File	For
rubrapack-0.31.0-windows-x64.exe	Windows x64, tested on Windows 11 (single file, cross-built with MinGW-w64)
rubrapack-0.31.0-linux-x86_64	Linux x86-64, glibc 2.38 or later (Debian 13, Ubuntu 24.04 and later)
SHA256SUMS	checksums of the files above

rubrapack 0.30.0

Explorer handlers for your file types: thumbnails, previews and properties.

Added

• [handler.ID] declares an Explorer handler served by a COM class of a DLL in the package (a [com.ID]): kind = "thumbnail" (the picture Explorer shows for a file), "preview" (what the preview pane shows) or "property" (the properties Explorer and search list), with the file types it serves.
  • In an MSI rubrapack writes what Windows looks for: each type's ShellEx value for a thumbnail or preview handler, the PreviewHandlers list and Windows' preview host as the preview class's AppID, and PropertySystem\PropertyHandlers for a property handler (per-machine packages only, as Windows reads them).
  • In an MSIX a thumbnail handler goes into a file type association of the package. Packaged preview and property handlers were not seen working on Windows 11 (their classes reach the package's COM catalog, but Explorer did not use them in our tests), so an MSIX refuses those two kinds and msi-only = true keeps them for the MSI.

Checked on Windows 11 with a real handler DLL: from the MSI the shell's thumbnail is the handler's picture, System.Title comes from the property handler, and the preview handler is created in Windows' preview host; from the MSIX Explorer shows the handler's thumbnails; after removal none of them remain.

Manual

• Web: https://rubidus-api.github.io/rubrapack/ - tutorial chapter 11, "COM classes"; Reference, "Explorer handlers".
• PDF: rubrapack-manual-0.30.0-en.pdf, rubrapack-manual-0.30.0-ko.pdf (attached)

Downloads

File	For
rubrapack-0.30.0-windows-x64.exe	Windows x64, tested on Windows 11 (single file, cross-built with MinGW-w64)
rubrapack-0.30.0-linux-x86_64	Linux x86-64, glibc 2.38 or later (Debian 13, Ubuntu 24.04 and later)
SHA256SUMS	checksums of the files above