v4.7.1 — Windows ISO Updater

Stable release. Fixes the automatic Portuguese language-pack download that still failed in 4.7.0 with SEC_E_WRONG_PRINCIPAL. Version 4.7.1 is now the latest stable download. The existing interface, settings and work folders are preserved.

Fixed — Microsoft HTTP-only language-pack endpoints

• Preserve the exact payload URL supplied by the HTTPS UUP metadata. The previous code forced HTTP links to HTTPS; Microsoft CDN endpoints such as tlu.dl.delivery.mp.microsoft.com can reject that with a certificate-name mismatch. Switching between HTTPS download clients could not correct the URL.
• Permit an HTTP automatic payload only when a valid expected size and SHA-1 are supplied. Verify both before the helper returns and before caching / conversion; discard partial or mismatched bytes. Keep the Microsoft host allowlist and refuse redirects. DISM still checks package signatures and applicability during integration.
• Keep genuine HTTPS URLs and normal certificate validation. No certificate check is disabled and no HTTPS source is downgraded to HTTP. Advanced manual CAB downloads continue to require HTTPS.
• Use the same metadata URL and mandatory integrity checks when curl is absent. Log when Microsoft supplies an HTTP payload URL; keep signed query parameters intact.

Release, validation and documentation

• Add a promotion workflow that verifies the existing app and rebuild, packages current documentation / sources, and promotes the existing release through GitHub Actions.
• Promote the existing 4.7.1 pre-release to a full release and mark it latest. Keep the tested application and its published SHA-256 unchanged; update the README, changelog, release title and release notes to stable status.
• Include the single-file app and checksum, a complete release ZIP with documentation, and an updated source ZIP with the stable documentation. The original Git tag and GitHub-generated source archives retain the tested release snapshot; the attached source ZIP includes the later documentation update.
• The original Microsoft URL for the reported pt-PT / build 19041 / x64 pack downloaded successfully: 23,659,629 bytes, SHA-1 5fc91fadd2aa3bef71d7a100ebbe0959d9c19604, matching the HTTPS metadata. The new PowerShell download path was also exercised live on Linux; native Windows conversion / integration remains a testing step.
• 18 automated suites / 723 checks pass. Update the README, security documentation, app version, generated single-file app and bug-report form. Regression checks cover original URL preservation, HTTP metadata requirements, size / hash rejection, missing curl, HTTPS fallback and redirect refusal.

Upgrade and usage

1. Download Windows-ISO-updater-GUI_v4.7.1.cmd and its .sha256, verify the checksum and place the app beside your existing settings / tools.
2. Resume the same work folder and download the selected language packs. Payloads must pass size / SHA-1 verification before ESD-to-CAB conversion starts.
3. Integrate into fresh unpacked media if the image was already serviced. If conversion / integration fails, share the new engine.log and dism.log with private paths removed.

Downloads: use the single .cmd or Windows-ISO-Updater-v4.7.1.zip (app, checksum and current documentation). Windows-ISO-Updater-v4.7.1-source.zip contains the source and updated stable documentation. Verify downloads with SHA256SUMS.

Source snapshots: the original tag and GitHub-generated source archives retain the tested app commit. The attached source ZIP includes the stable documentation from 29f0897. The app and its published SHA-256 are unchanged.

Full Changelog: v4.7.0...v4.7.1

v4.4.0 — Media Creation Tool ISOs and Microsoft signatures

The ISO check now also handles ISOs made with the Media Creation Tool, which can't be checked by SHA-256 because the tool builds the ISO on the PC. When the SHA-256 isn't one Microsoft lists, the Microsoft signatures of the ISO's setup and boot files are checked instead.

Upgrading from 4.3: download Windows-ISO-updater-GUI_v4.4.0.cmd and delete the old .cmd. Settings, the signing folder and the work folder are kept. An ISO 4.3 found Not verified is checked again (signatures) the next time it is unpacked, or with Check the ISO.

Added

• Signatures of the setup and boot files. When an ISO's SHA-256 isn't in Microsoft's list or on microsoft.com, the ISO is mounted read-only for a few seconds:
  • setup.exe, sources\setup.exe, setupprep.exe, setuphost.exe, bootmgr.efi and the UEFI boot files (efi\boot\boot*.efi, cdboot.efi) must each carry a valid signature of Microsoft Corporation;
  • a missing setup or UEFI boot file counts as a fault too;
  • an ISO the user mounted stays mounted.
  • The Windows image itself (install.esd / install.wim) isn't signed as a whole, so page 1 says this check doesn't cover it.
• Media Creation Tool ISOs are recognised by their Windows image, install.esd (Microsoft's download ISOs have install.wim). When every signature is fine, page 1 shows Made with the Media Creation Tool - setup and boot files signed by Microsoft (blue) and explains why the SHA-256 can't be in a list. Unpack and Run everything go on without asking, and the result is kept, so the ISO isn't read or looked up again.
• Modified ISOs: when a setup or boot file isn't signed by Microsoft, page 1 shows Modified: files in this ISO are not signed by Microsoft (red) with the files, and advises downloading an original Windows 10 or 11 ISO from Microsoft. Unpack and Run everything ask first.
• Not verified now also says when the setup and boot files are signed by Microsoft.
• The button is now Check the ISO (it was Check SHA-256).
• All new texts are in the six interface languages.

Code and tests

• src/29_engine_isocheck.ps1:
  • Test-IsoFolderSignatures checks the signatures;
  • Invoke-WithMountedIso mounts the ISO, the same way unpacking does;
  • Test-IsoOriginal has two new results, mct and badsig, and keeps the signatures with the result;
  • Write-IsoCheckResult writes the log lines.
• src/50_gui.ps1: Get-IsoCheckView gives the text, color and note for page 1 and the question.
• tests/isocheck.tests.ps1 (71 checks) covers:
  • signatures with a stand-in for Get-AuthenticodeSignature: valid, changed file, another signer, untrusted chain, unreadable format, missing setup or boot file;
  • mounting and dismounting, including after an error, and an ISO already mounted;
  • Media Creation Tool and modified ISOs, kept and not checked again, and signature lists read back from state.json as empty;
  • page 1 colors and texts, translated;
  • no question for a Media Creation Tool ISO, and a question for a modified one.

Full Changelog: v4.3.1...v4.4.0

v4.3.1 — Fix: the window didn't open on Windows

Fix: 4.2.0 and 4.3.0 didn't open on Windows. The console showed "Windows ISO Updater could not start: Argument types do not match" at foreach ($x in @($Texts)).

Upgrading: download Windows-ISO-updater-GUI_v4.3.1.cmd and delete the old .cmd. Settings, the signing folder and the work folder are kept.

Fixed

• The window is translated when it opens (since 4.2.0): Get-UiTexts collects every text of the window in a list, and Set-UiTexts puts the language on them. The list was made with New-Object, and PowerShell can't run @(...) over such a List[object]: it stops with "Argument types do not match". The list is now made with ::new(), and Set-UiTexts goes through it without @().

Tests

• tests/lang.tests.ps1 (41 checks): Get-UiTexts and Set-UiTexts now run on a whole window of stand-ins for the WPF elements (text, button with tooltip and screen-reader name, tab header, text box tooltip, list columns, 400 more texts), in Portuguese and back to English, and on a list made with New-Object. Before, they only got a plain array, which is why the tests passed. The new checks fail on 4.3.0 with the same error.

Full Changelog: v4.3.0...v4.3.1

v4.1.0 — Faster slipstream: updates already in the image skipped, editions at the same time

A faster slipstream, from the DISM logs of a real run: an ISO Microsoft refreshed already has the cumulative update, and the tool no longer unpacks it again for every image. Also several editions at the same time, older driver versions left out, and the time of every step at the end of the log.

That run used a Windows 10 22H2 ISO "updated Oct 2025" (already at build 19045.6456) and the October 2025 update (KB5066791):

• DISM unpacked the update 6 times: install.wim, WinRE and twice for each boot.wim index. Each pass took 2.5–4 minutes and ended with "already in the correct state" — about 23 minutes of DISM work that changed nothing.
• boot.wim (17:54) was the slowest part of the 18-minute slipstream.

Upgrading from 4.0: download Windows-ISO-updater-GUI_v4.1.0.cmd and delete the old .cmd. Settings, the signing folder and the work folder are kept.

Added

• Updates an image already has are skipped:
  • the build an update brings is read from the XML inside the .msu (Package_for_RollupFix version);
  • the build of every image (editions, WinRE, both boot.wim indexes) is read from the WIM;
  • an image already at that build (same servicing base: Windows 10 19041–19045, Windows 11 22621–22631, 26100–26200) skips the update, and the log says so;
  • when the build can't be read, the update is applied as before.
• boot.wim: the cumulative update in one pass when that pass installs it.
  • Microsoft's way for WinPE adds the update twice, because the first pass can stop with 0x8007007E after it installed the servicing stack.
  • The second pass now runs only when the first one didn't install it. It used to always run and unpack the whole update again (3–4 minutes per index).
• Drivers: older versions are unticked. Windows keeps the old versions of a driver in its driver store, and Add drivers from this PC exported them all; the run above had 3 NVIDIA display drivers and 12 Intel Bluetooth versions among 109 packages.
  • The picker now unticks every package that is an older version of another one in the list (same INF name, provider and class; newest by date, then version).
  • A new column Older shows which ones. All that fit keeps them unticked too.
  • The same applies to imported folders.
• Editions at the same time (page 7, Speed). DISM can't use more than one process for one image, but several editions can be updated side by side:
  • each ticked edition is staged into a WIM file of its own and updated in a background job, with its own mount folder (mnt\osN), scratch folder and DISM / engine logs;
  • automatic: 2 at once on 4+ processor cores, 3 on 8+; or set 1–4 (1 = one after the other, as before);
  • each one needs about 25 GB free on the work drive; with less, fewer run at once and the log says why;
  • WinRE is updated once, from the first edition, as soon as that edition is mounted. Every edition waits for it just before it is saved;
  • the new install.wim keeps the original edition order, and editions that are not updated are copied as they are. It is written while the remaining editions are still being updated;
  • each edition's log follows in the Activity panel when it finishes. If one fails, the others are stopped, the mounts are discarded and the unpacked media stays as it was;
  • if no background worker can start, the editions are updated one after the other, with a warning.
• Time per step at the end of the slipstream log:
  • for every edition: stage, mount, drivers, servicing stack, cumulative update, enablement package, cleanup, .NET, waiting for WinRE, save, export;
  • WinRE and boot.wim (per index), the media folder, and the total.

Fixed

• Let Windows Defender skip the work folder: when Defender is not running (0x800106ba, turned off or another antivirus), the log says so in one note instead of a warning at every job.
• Setup Dynamic Update: one line with the number of updated setup files instead of one line per file (93 in that run).
• The storage / network driver set for WinRE and boot.wim counted one driver when there were none (no effect on DISM).

Code and tests

• The updates of one mounted edition are one function (Add-EditionUpdates), used by the main job and by the edition jobs.
• tests/service.tests.ps1 (82 checks, 35 new), against the stand-in dism and a stand-in expand that hands out the XML of a .msu:
  • the update build read from a real-shaped .msu XML; when an update counts as already in an image;
  • an ISO already at the build: no image gets the update (with one and two editions at once), a newer update goes into every image, boot.wim in one pass, and two passes when the first one fails;
  • older driver versions; the Defender-not-running note;
  • how many editions run at once (automatic, setting, editions ticked, free space);
  • 3 editions with 2 at once: at most 2 mounted together, each staged into its own WIM, the new install.wim in the original order with the unticked edition, own logs and scratch folders;
  • WinRE updated once before any edition is saved and copied into all three;
  • the time-per-step table;
  • faster than one after the other;
  • a failing edition (the others stopped, media unchanged), and no background worker (one after the other).

README

• Speed: the new option, the time-per-step table; troubleshooting row for the free-space warning.

Full Changelog: v4.0.0...v4.1.0

v4.0.0 — Choice of signing engine: MakeCat (default), libwdi-style, generate-cat-file, Inf2Cat

The signing changes of NVIDIA Modded Drivers Signer 2.3.0, and a choice of the engine that builds the catalogs. A new major version because drivers are now signed by a different engine by default.

Upgrading from 3.x: download Windows-ISO-updater-GUI_v4.0.0.cmd and delete the old .cmd. Settings, the signing folder and the work folder are kept. Signing now uses MakeCat by default; choose Inf2Cat on page 5 for the old behaviour. Packages you already signed stay as they are.

Added

• Engine buttons on page 5 (Signed NVIDIA / modded), saved as SignEngine in the settings file:
  • MakeCat (default): makecat.exe and a generated .cdf build one catalog per driver folder (<folder>_w10u.cat) with the SHA-256 hash of the INF files that need a new signature and of every file of the folder. Each file is hashed once — about 20 s for NVIDIA's 3 GB Display.Driver, where Inf2Cat can take up to an hour. makecat.exe comes from an installed Windows Kit or from Microsoft's NuGet packages (SDK build tools, then WDK).
  • libwdi-style (experimental): the same folder catalog, built with Windows' CryptCAT API (wintrust.dll) from a C# class compiled when needed, the way libwdi does it. Nothing to download.
  • generate-cat-file (WSL) (experimental): LINBIT's tool, downloaded as source from GitHub (pinned commit, SHA-256 checked) and built inside WSL.
  • Inf2Cat: Microsoft's standard tool, as before (isolated copies, several runs at the same time, time estimate).
  • A note under the buttons says what the chosen engine does and what it needs.
• Every file of the folder goes into the catalog, also the ones an INF copies as a whole directory and doesn't list in [SourceDisksFiles] (ngx-builtins, NvCamera). Windows checks every file it copies, and one missing hash makes it refuse the driver.
• Compressed files (nvngx_dlssd.dl_, while the INF names nvngx_dlssd.dll) are expanded with expand.exe into a temporary folder and hashed under the name the INF uses, because Windows checks the expanded file. The compressed file is hashed too.
• Inf2Cat is the fallback: when the engine isn't available (no makecat.exe, no WSL) or can't build a folder's catalog, Inf2Cat catalogues that folder in the same run. Inf2Cat is downloaded only then.
• After signing, every INF is checked against its new catalog with signtool verify /pa /c; a mismatch with a folder engine is reported with the hint to sign again with Inf2Cat.
• The log lists what went into each catalog (INF files, listed files, other files of the folder, compressed files) and warns about files an INF copies that are not in the folder.
• The list of signed packages has an Engine column. The Tools page shows makecat.exe.

Changed

• Inf2Cat runs at the same time is now Catalog runs at the same time: MakeCat runs up to 4 folders at once.
• tools\ holds makecat.exe when the MakeCat engine is used; Inf2Cat.exe is downloaded only when Inf2Cat signs.

Code and tests

• New src/39_engine_catalogs.ps1 with the engines, ported from the signer: INF [SourceDisksFiles] parsing with compressed files, catalog members, the .cdf, the CryptCAT class, the WSL build and run.
• The Inf2Cat process queue is now a general tool queue (Invoke-ToolQueue, with a working folder per run) that MakeCat uses too.
• New tests/sign-engines.tests.ps1 (52 checks) with stand-ins for makecat, expand.exe and wsl.exe: catalog members and the .cdf, MakeCat end to end (only the edited INF moves to the folder catalog, the shared WHQL catalog stays valid), the fallback to Inf2Cat, libwdi-style and generate-cat-file runs, the CryptCAT source compiling, the engine setting and buttons.

README

• New Signing engines section; troubleshooting, files, privacy and legal notice (generate-cat-file GPL-2.0, libwdi-style) updated.

Full Changelog: v3.6.0...v4.0.0

v3.5.1 — Window opens again on Windows

Fix for 3.5.0, which did not open on Windows.

Upgrading from 3.5.0: download Windows-ISO-updater-GUI_v3.5.1.cmd and delete Windows-ISO-updater-GUI_v3.5.0.cmd. Settings, the signing folder and the work folder are kept.

Fixed

• 3.5.0 stopped at start with "Windows ISO Updater could not start: '#FF0B0E14' is not a valid value for property 'Background'". The theme colors were stored in the window's resources as PowerShell's wrapper object instead of the brush itself. Windows PowerShell 5.1 keeps that wrapper when an object goes straight into a dictionary, and WPF can't use it as a color. Every theme resource now holds the brush itself, so the window opens again in the dark and the light theme.

Code and tests

• New Set-Resource helper: the only way resources are stored, always as the .NET object itself.
• tests/theme.tests.ps1 shows the wrapper problem with a plain dictionary, checks that Set-Resource stores the object itself, and fails if any code assigns a resource directly.

README

• New Changelog section with a short summary of every version and a link to this file.

Full Changelog: v3.5.0...v3.5.1

v3.5.0 — Dark / Light Theme, Text Size and Font

Display and accessibility options in the top right corner: a dark / light theme, the text size and the font.

Upgrading from 3.4: download Windows-ISO-updater-GUI_v3.5.0.cmd and delete the old .cmd. Settings, the signing folder and the work folder are kept. The window starts dark at 100 %, as before.

Added

• Theme switch (sun / moon, top right, next to minimize): dark or light, at once, no restart.
• Display and accessibility panel (accessibility icon, top right) with:
  • Theme: Dark, Light, or Like Windows, which follows the app mode in Windows' color settings.
  • Text size: 100 %, 115 %, 130 % or 150 %. It zooms the whole window, so text, buttons and lists grow together. The sidebar scrolls when the larger size doesn't fit.
  • Font: Segoe UI, Verdana, Tahoma or Arial. Verdana and Tahoma have wider, more distinct letters. The log keeps Consolas, so its columns stay aligned.
• Keyboard: Ctrl + plus / Ctrl + minus / Ctrl + 0, or Ctrl + mouse wheel, change the text size anywhere in the window. Esc closes the panel.
• The choices are saved in the settings file (UiTheme, UiZoom, UiFont) and used at the next start. The driver picker and the certificate password dialog follow them too.
• The title bar buttons (theme, display, minimize, maximize, close) have names for screen readers.
• Light theme:
  • every text color has at least 4.5:1 contrast on its background (WCAG AA);
  • the log keeps its colors (green OK, yellow warning, red error) in darker shades;
  • the text cursor in input boxes is dark in the light theme (it was white).

Code and tests

• The XAML stays written in the dark colors. When a window is loaded, every color of a brush becomes a theme resource (T_<hex>), and switching the theme swaps those resources. Brushes made in code go through New-Brush, which maps them too, and the log lines are recolored.
• New suite tests/theme.tests.ps1 checks:
  • that the three windows are well-formed XAML after the conversion, with no fixed brush color left;
  • that every color used, in the XAML and in code, has a light color;
  • the 4.5:1 contrast of all text / background pairs in the light theme;
  • the theme, text size and font settings;
  • the panel state and the title bar buttons.
• In total there are 12 suites with about 375 checks.

Full Changelog: v3.4.0...v3.5.0

v3.4.0 — Renamed to Windows ISO Updater

The program is now Windows ISO Updater: the file is called Windows-ISO-updater-GUI_vX.X.X.cmd and carries its version in the name. Plus a round of fixes found in a code review.

Upgrading from 3.3: download Windows-ISO-updater-GUI_v3.4.0.cmd, put it in the same folder and delete the old Win10-ISO-Updater.cmd. Your options are carried over (Win10-ISO-Updater.settings.json is read once and saved as Windows-ISO-Updater.settings.json), and the signing folder and the work folder are kept. The GitHub repository is now j0p3s/Windows-ISO-Updater.

Changed

• New file name: Windows-ISO-updater-GUI_vX.X.X.cmd. The version is read from one place ($Script:AppVersion in src/10_engine_head.ps1); build.py puts it in the file name, the header, the start line and the version label in the window, and removes older builds.
• The release workflow attaches Windows-ISO-updater-GUI_vX.Y.Z.cmd and its .sha256; the tests workflow checks that the committed build is the build of src/.
• Names and titles say Windows ISO Updater everywhere (window, message boxes, log, ISO label fallback WINDOWS_CUSTOM). The settings file name no longer changes with the version.
• The Save as box of the Build page suggests Win10_custom.iso or Win11_custom.iso after the Windows version of the unpacked ISO.

Fixed

• Your own SetupComplete.cmd kept byte for byte. Adding the driver call used to rewrite the file as ASCII, so accented characters in it became ? and a UTF-8 BOM was dropped. Now only the call line is inserted; encoding and BOM stay.
• Accents in a driver package name (for example a folder called Gráficos) no longer end up as ? in SetupComplete-drivers.cmd: names are transliterated to plain ASCII. An $OEM$ driver folder with non-ASCII characters is skipped with a note in the log, as it cannot be named in that script.
• A network path as work folder (\\server\share) now gives a clear message instead of an error from DriveInfo.
• A non-numeric image INDEX in autounattend.xml no longer aborts the check with a cast error; it is reported as a warning.
• The Defender marker file and the .sha256 next to the ISO keep non-ASCII characters in the path / file name (UTF-8; the .sha256 has no BOM, so sha256sum -c reads it).
• The launcher starts Windows PowerShell by its full path, so a powershell.exe lying next to the .cmd (the current folder is searched first) is never run with administrator rights.
• Redundant branch in the driver import removed.

Full Changelog: v3.3.0...v3.4.0

v3.3.0 — Windows 11 Support

Windows 11 support, and a switch on page 1 to choose between Windows 10 and Windows 11.

Upgrading from 3.2: replace Win10-ISO-Updater.cmd. Your settings, the signing folder and the work folder are kept. A Windows 11 ISO you unpacked with an older version is detected again automatically the next time you download updates (or press Re-read image info).

Added — Windows 11

• Windows version switch on page 1: Windows 10 or Windows 11. It sets the Download Windows 10/11 from Microsoft button, the hint under it and the title of the ISO dialog. When you unpack an ISO, it follows the Windows that ISO really is. If you pick the other version while an ISO is unpacked, the page says so.
• Windows 11 21H2, 22H2 / 23H2, 24H2 / LTSC 2024 and 25H2 (x64, ARM64) get automatic updates:
  • the cumulative update;
  • the Safe OS and Setup Dynamic Updates;
  • the .NET cumulative update;
  • for 22H2, the 23H2 enablement package (KB5027397).
• 21H2 is out of servicing and gets its last updates (2024-10). The Windows 10 ESU limit (2025-10) applies to Windows 10 only, so the Newest month box on page 3 is hidden for Windows 11.
• Windows 11 cumulative updates carry the servicing stack, so the 36-month servicing stack lookup is skipped. .NET 4.8.1 is built in, so it is not added.
• Checkpoint cumulative updates (24H2 and later): the catalog entry also holds the checkpoint update it builds on. Both are downloaded, and the checkpoint (the older KB) goes in first, for install.wim, WinRE and boot.wim.
• DISM for Windows 11 on a Windows 10 PC: Windows supports servicing an image only with a DISM of the same or a newer Windows.
  • When this PC's DISM is older than the image, the slipstream offers to install the Windows ADK Deployment Tools from Microsoft (signature-checked, the same installer already used as the oscdimg fallback).
  • The ADK's DISM is then used for that image. This PC's own DISM is not changed.
  • The background boot.wim / WinRE jobs and Clean up use the same DISM.
  • If you decline, the PC's DISM is tried, with a warning.
• The new ISO is named Win11_<version>_<build>_<arch>_<date>.iso for Windows 11, and its volume label starts with W11_.

Changed

• The family detection and catalog searches moved from the v1 engine into src/38_engine_windows.ps1. The Windows 10 in the catalog title patterns is now the image's Windows.
• The install check no longer says "Windows 10 Setup" for $OEM$ folders.

Tests

• The catalog suite covers:
  • every Windows 11 version and the old saved state without an OS;
  • the Windows 11 titles (24H2 vs 25H2 vs Server, ARM64 in lower case, .NET "Windows 11, version 24H2", Safe OS / Setup Dynamic Updates);
  • the 23H2 enablement package;
  • the checkpoint-first order;
  • the DISM choice (Windows 10 PC with and without the ADK, install yes/no, Windows 11 PC, version unreadable).
• The download suite covers Windows 11 24H2 (no SSU lookup, no .NET 4.8.1) and 22H2 (enablement package).
• The UI suite covers the version switch.
• In total there are 11 suites with about 350 checks.

Full Changelog: v3.2.0...v3.3.0

v3.2.0 — Faster NVIDIA Signing

Signing NVIDIA drivers on page 5 now gets the speed-up of New catalogs only for the INF files that need one, with the change from NVIDIA Modded Drivers Signer 1.5.0.

Upgrading from 3.1: replace Win10-ISO-Updater.cmd. Your settings, the signing folder and the work folder are kept. Sign your NVIDIA package again to get the faster method.

Faster — signing NVIDIA drivers (page 5)

• An edited INF whose catalog is shared gets a catalog of its own. NVIDIA's Display.Driver INF files share one catalog (nv_dispi.cat).
  • In 3.1, a new catalog had to cover every INF that named it. So for NVIDIA the whole folder was catalogued again, and the isolated copy gained nothing.
  • Now the edited INF's CatalogFile= line points at <name>_w10u.cat (for example nv_dispi_w10u.cat), and only that INF is catalogued. Nothing else in the INF changes, and its encoding (ANSI, UTF-8, UTF-16) is kept.
  • The shared nv_dispi.cat stays as it is and stays valid for the INF files you did not edit.
  • This change is made in the work copy only, and only once Inf2Cat has succeeded. If it fails, the whole folder is catalogued as before, and the INF is not changed.
  • When NVCleanstall signed the shared catalog with its own certificate, every INF needs a new one. Each INF then gets its own catalog, and they are catalogued side by side instead of in one long Inf2Cat run.
• Inf2Cat runs at the same time: the default is now the number of processor cores up to 8 (was 4), as in signer 1.5.0.

Not taken over from the signer

• Signer 1.5.0 backs up the original INF files before replacing them. Here only the work copy is changed; your original folder is never touched.

Code and tests

• Split-InfGroups (catalog groups) is replaced by Split-InfRuns, Get-OwnCatalogName and Set-InfCatalog.
• tests/sign-speed.tests.ps1 now covers:
  • NVIDIA's shared catalog with one edited INF;
  • a shared catalog signed by NVCleanstall (one run per INF);
  • the INF encodings.
• The stand-in signtool now reports an INF edited after its catalog was made.
• The suite has 60 checks; in total there are 11 suites with about 310 checks.

Full Changelog: v3.1.0...v3.2.0