Date: 2026-08-09 Verdict: Two defects found. One fixed here, one left open as a design decision. Published startup figures corrected.
A direct continuation of report 04, same session. That pass ran from source only. This one rebuilds both packaged forms, runs them, performs the security pass the one directory build had never had, and generates the packaging images.
About this edition. The original record of this pass is an internal working document, in French. This is a full English edition prepared for publication, faithful to it and adding nothing. The original is archived unchanged, because a test report is a record of what was run.
Identical to report 04, and the processor is the same as report 03, which is what makes the timing comparisons meaningful.
| OS | Windows 11 Enterprise, build 26100 |
| Processor | AMD Ryzen 7 7800X3D, 8 cores |
| Memory | 8 GB allocated |
| Python | 3.12.10 |
| PyInstaller | 6.22.0 |
| Network | live and reachable, an external host answers |
| Build location | a genuine local disk, ownership verified |
Two of those rows are there for a reason.
The network being live is what makes a result of zero connections a measurement rather than an assumption. Testing for network activity on a machine with no network proves nothing at all.
The ownership check on the build location is there because confusing a host mapped folder with a local disk had already skewed two earlier reports by a factor of 2.7.
| Check | Result |
|---|---|
| Both packaged forms build | Pass. Single file 7.17 MB, one directory 937 files and 17.6 MB |
| The packaged build carries the two fixes from report 04 | Pass. Dark title bar, and the status message on three lines |
| Network machinery inside the one directory bundle | Pass. None of it present |
| Connections during a driven session | Pass. 83 samples over 40 seconds, zero TCP, zero UDP |
| Child processes | Pass. Zero |
| Registry writes across a full session | Pass, with a stated limit. 168 values watched, nothing changed |
| Excluded modules genuinely absent | Pass. 26 searched for, none present |
| Startup | Measured. Published figures need correcting |
| Packaging images generate | Pass. 31 images plus the icon file |
| The executable's icon | Fail, defect D12. It was shipping the build tool's default. Fixed |
| Icon legibility | Fail, defect D11. Contrast of 1.11 on a light background. Left open |
The build configuration passed no icon parameter, so the build tool applied its own. Extracted from the built executable: a blue floppy disk with a Python logo. That is what a user saw on their desktop, on the taskbar and when switching windows.
This had been carried as an open question about whether the icon was worth baking in. The answer is yes, without reservation. An application that ships somebody else's placeholder icon looks abandoned before it is opened.
The fix. The build configuration now resolves the generated icon file and passes it in both packaging modes. That file is generated rather than committed, so a missing one is not an error: the build warns on standard output and falls back, which keeps a fresh clone buildable without the image library installed.
Verified after rebuilding. Both executables carry the mark.
Mean luminance of the opaque mark: 250.1 out of 255. It is white.
Contrast against the two backgrounds Windows uses:
| Dark background | Light background | |
|---|---|---|
| The mark as it was, white | 18.92 | 1.11 |
| The mark in the accent colour | 7.48 | 2.28 |
| The glyph outline colour | 4.12 | 4.14 |
The accepted minimum for non text is 3.0. At 1.11 the white mark is not distinguishable from its background.
This is not theoretical. The asset generator emits unplated variants, and those are precisely the ones Windows places on the taskbar with nothing behind them. In a light theme the icon disappears.
Proportion of solid pixels, excluding antialiasing:
| Size | Total ink | Solid pixels |
|---|---|---|
| 16 px | 18.4 percent | 2.0 percent |
| 24 px | 17.4 percent | 4.5 percent |
| 32 px | 16.0 percent | 6.0 percent |
| 48 px | 14.6 percent | 7.2 percent |
At 16 pixels almost nothing is solid. The mark is a smudge. A mark drawn at 547 by 456 needs a simplified version at small sizes, which is exactly what had been anticipated.
Changing the colour or the shape of the mark changes the visual identity of the product and its Store presence. That is not a mechanical correction. Three options were rendered and measured, and the decision belongs to the maintainer.
It was resolved afterwards. The mark is now tinted with the accent colour, and the accent moved from orange to a vivid red at the same time, landing in the band that clears the minimum against both backgrounds at 4.92 and 3.47.
The one directory build had never had a pass of its own. It is the build that would go inside a Store package, so it is the one that matters.
A recursive search of the built application for socket, TLS, cryptography, compression, database and multiprocessing binaries returned no files at all. The no network property is structural in this build too, not merely true of the source.
The bootstrap module archive holds 155 entries. Searched for 26 excluded modules: none present.
A false alarm worth writing down. Four modules that the build configuration explicitly says must not be excluded are also absent from that archive, which looks alarming for a moment. The archive only contains the bootstrap subset. The real check is whether the executable starts, which it does, since the loader would otherwise fail outright. It started 22 times during the startup measurements.
The executable was launched and then driven: a tile clicked, the FAQ opened, scrolled with the wheel to the last entry, closed, and the display restored. Sampled every 400 milliseconds for 40 seconds.
83 samples
TCP endpoints owned by the process : 0
UDP endpoints owned by the process : 0
child processes : 0
Three new processes appeared at system level during the session. Two were the scripts driving the test. The third was Windows inspecting an unsigned binary on first launch, which is Windows doing something rather than the app starting something. The child process count is zero.
That third one is also the first direct observation of a behaviour earlier reports had listed as untestable.
168 values were recorded across the locations a resolution switcher would plausibly touch, before and after a session including three resolution changes and a restore.
before 168, after 168, added 0, removed 0, changed 0
A limit not to overstate. This is a targeted survey rather than a diff of the entire registry. More importantly, the sandbox driver never actually applies a mode, so this does not prove that a successful change fails to persist. What it shows is that the application writes nothing while it runs.
Method taken unchanged from report 03: launch, poll every two milliseconds for the first visible window, and separately record the gap between the launcher and its child for the extraction cost. Ten iterations after a warm up run, local disk.
| Build | median | mean | min | max | deviation | extraction |
|---|---|---|---|---|---|---|
| one directory | 158.3 ms | 157.9 | 149.2 | 165.9 | 4.9 | none |
| single file | 592.9 ms | 605.3 | 560.9 | 683.4 | 42.3 | 326.1 ms |
| from source | 166.6 ms | 172.0 | 158.8 | 206.0 | 13.9 | none |
| report 03 | now | difference | |
|---|---|---|---|
| one directory | 111.9 ms | 158.3 ms | 41 percent slower |
| single file | 490.0 ms | 592.9 ms | 21 percent slower |
| from source | 114.7 ms | 166.6 ms | 45 percent slower |
| extraction | 286.0 ms | 326.1 ms | 14 percent slower |
Extraction is pure loader work with no application code involved at all. Its 14 percent therefore measures how much slower this session is, same machine but a different sandbox instance. Correcting for that factor, one directory should have come out near 127 ms and source near 131 ms. The measurements give 158.3 and 166.6.
So roughly 30 to 35 milliseconds are attributable to the interface redesign itself. DPI awareness, the scaling layer, nine tiles drawn on canvas with their glyphs, the wordmark drawn character by character, and reading the current display mode. That is an estimate derived from a single indicator of machine speed rather than a direct measurement, and it is presented as such.
The structural result from report 03 holds. One directory remains indistinguishable from running the source, 8.3 milliseconds faster here against deviations of 4.9 and 13.9. The packaging adds no startup cost in that mode.
| Published | Measured here |
|---|---|
| 490 ms single file | 592.9 ms |
| 112 ms one directory | 158.3 ms |
| 7.2 MB single file | unchanged to the nearest tenth |
The report 03 values were not wrong when they were taken. The code has changed since. Reports are not rewritten, so this one corrects them.
The generator produced 31 images plus an icon file at seven sizes from 16 to 256 pixels. Every tile is emitted at 100, 200 and 400 percent, plus the target size and unplated variants from 16 to 256, which is what the package manifest asks for.
The content of those images is the subject of D11 above.
Beyond the seven standing limitations of the sandbox: