DiscWright 0.9.1

DiscWright used to stop at the ISO. It now prints the artwork and burns the disc.

Printing

Print artwork makes two things for the disc you have planned: a case wrap as a PDF at its true size with crop marks, and a disc face as a 300 dpi PNG with the hub left clear. A PDF because the page carries its real physical size, so "print at 100%, no scaling" is something a printer driver can honour. A PNG for the disc because that is what printer software for printable discs wants: you hand it a picture and it keeps the diameters and lines the tray up, which is the part that ruins discs when a tool guesses at it.

Artwork you already have is printed exactly as it is. People make covers for games and share them, and somebody who has found or drawn one does not want a layout imposed on it. Point DiscWright at one and it places it at exact trim, carries its own edges outwards to make the bleed it has not got, and puts crop marks outside that. Nothing is added, nothing is cropped off, and nothing is stretched: a cover whose proportions are slightly out is placed whole rather than trimmed to fit. With no picture at all you get a plain label with the title on it, which is still worth having on an unmarked disc in a stack.

Two boxes hold the pictures, one for the cover and one for the disc face, because a cover is tall and a disc face is a circle and one picture rarely suits both. Under them a line says what each picture will cost before anything is printed: a 16:9 wallpaper loses about 60% of its width on a cover panel, and being told that beforehand beats finding out on paper.

Burning

Burn to disc writes the ISO to a blank and then proves it. It asks first, and the question carries what is worth refusing on: which image, how large, which drive, what disc is in it and how much of it is free. It refuses by name rather than guessing when there is no disc, when the disc is not blank, when the media cannot be written, or when the image is larger than the space.

It burns below the drive's top speed, 16x on a CD and 8x on a DVD, because cheap media written flat out is the usual way to make a coaster and the minute saved is not worth a disc. Afterwards it reads every file back off the disc and compares it with what was built, by SHA-256, and says plainly if anything is missing, unexpected, the wrong length or the wrong bytes. A burn that ends without an error is not the same thing as a disc holding the right bytes.

Play from disc

A disc built from folders of game files rather than GOG installers used to grey Play out with "is not installed yet, use Install first" and offer Install, on a disc where nothing can be installed because the executable is the game. Such an entry now shows one button reading Play from disc, and no Install button at all. GOG discs are unchanged.

This was found by burning a disc and looking at the screen. Every menu test had been written around GOG discs, where the old behaviour is correct, so the suite was green throughout. The menu tests now walk both kinds of disc.

The installer may not run on a current Windows 11

Smart App Control blocks unsigned programs, and the installer is not signed. It refuses it with "An Application Control policy has blocked this file". It is on after a clean install of Windows 11 22H2 or later, in North America and Europe, and starts in an evaluation mode that blocks nothing before switching itself on. A machine upgraded from an older Windows has it off.

Correction, added after publishing. These notes first said signing would not settle it, because Smart App Control wants reputation as well as a signature. That is wrong. Microsoft's documentation says that where the app intelligence service cannot make a prediction, Smart App Control still allows an app signed with a certificate from a CA in the Trusted Root Program, with no reputation required. Signing would fix this; DiscWright has not taken that cost on.

The ZIP is unaffected, needs no installing, and is the download to use. This was measured rather than assumed: the same installer check passed in a Windows Sandbox on 27 September, when Smart App Control there was still in evaluation mode, and was blocked on 1 October once it had switched on. The installer is still attached for anyone whose machine will run it, and for winget later.

Why the version skips 0.9.0

0.9.0 was tagged and its build attached artifacts to a draft. Unpacking that draft showed the zip had no print\ or burn\ folder in it, so both of the buttons above would have been dead ends for everybody who took the main download. Released tags are protected in this repository and cannot be moved or deleted, which is worth more than a version number, so 0.9.0 stands as a tag that was never released and this is the first release of what it was meant to contain.

Checksums

artifact	sha256
DiscWright-0.9.1.zip	47459A50E039AAD2BFA106C141F53DBBF329FFE27BD34348E84831FCA04642B7
DiscWright-0.9.1-setup.exe	56E6501C1E260D9443E33845B16FB7F7F44486C83115F2044FAE2570C711BC14

What was tested, and where

651 logic tests and 108 window tests, both run on a real Windows 11 desktop rather than in CI, which does not run the window suite because a hosted runner has no desktop. CI ran the logic suite, the parse check and the analyzer on every push.

Three CD-Rs were burned by this build on an ASUS DRW-24D5MT, because none of the burning or menu behaviour had ever been proved on anything but a mounted image. A 241.7 MB disc burned in 93 seconds and every file matched byte for byte. Windows offered Run DISCWRIGHT TEST on insert and the menu opened from the disc. A 120 MB program on the disc started in 8 seconds and reported its own path back from the optical drive. The third disc was built from loose game files and is the one that found the Play button defect above.

The zip was downloaded from this release, unpacked, and started: it reports DiscWright 0.9.1 in its title bar and carries both modules. The installer was run in a Windows Sandbox and was blocked by Smart App Control, as described above.

What is still unproven is listed in burn/README.md rather than claimed: a disc read in another machine, a multi-disc set, and the older-Windows filesystem option read on something old.

DiscWright 0.8.1

A bug-fix release, one fix, and it is about the installer rather than the disc. Project files and the on-disc layout are unchanged: a 0.8.0 project opens and rebuilds exactly as it did.

The Start menu shortcut did nothing on a Windows without VBScript

The installer pointed it at wscript.exe and DiscWright.vbs, the launcher whose whole job is starting the app with no console window flashing up first. vbscript.dll is not on a current Windows 11 image: VBScript became a Feature on Demand in 24H2, and Microsoft has said it will be disabled by default and then removed.

On such a machine the shortcut opened a Windows Script Host error box and nothing else, which is where DiscWright ended for anyone who installed it rather than unzipping it.

The installer now asks the machine and builds the shortcut to match:

• VBScript there: nothing changes, wscript and the .vbs as before.
• VBScript not there: powershell.exe with its window hidden, which costs a brief console flash. Worth accepting only where the quieter way cannot run at all, which is why it is decided per machine rather than for everybody.

All three places that start the app are covered: the Start menu shortcut, the optional desktop icon, and the tick box at the end of the install.

Why 0.8.0 shipped with it

Smart App Control blocks an unsigned installer on the machine DiscWright is developed on, so the installer had been going out having never been run. Windows Sandbox is a throwaway Windows without that policy, and packaging\sandbox\Test-Installer.ps1 now installs a release there, checks what Windows records, starts the app, uninstalls and checks it is gone. Running it against 0.8.0's own published installer is what found this, and it is a step in the release runbook from now on.

This release was tested that way before publishing, which 0.8.0 was not. Every check passed on a clean Windows 11 image.

What was never affected

• The zip. Run DiscWright.cmd calls PowerShell directly and never touches VBScript. Checked here too: it unpacks and opens as 0.8.1.
• Discs. The same sandbox run confirmed mshta, JScript and Scripting.FileSystemObject are all on that image, so a disc's menu has everything it uses.

Checksums

DiscWright-0.8.1-setup.exe  6300530B57241510EF20638E98FE2DDADF4C824042C3A8165181C0976D42F17B
DiscWright-0.8.1.zip        3572F96EBD228AD1ACC1119B2105EBF6138A17C8578F27691D04E2882DC25EE7

Tests: 478 logic, 92 window, plus the installer on a clean Windows.

DiscWright 0.8.0

A feature release. A game no longer has to be a GOG download, and GOG discs are byte-for-byte what they were — see below.

Project files move to schema 9. A 0.7.x project opens and rebuilds exactly as it did; a 0.8.0 project opens in 0.7.6 too, which ignores the new field.

Any folder of game files can go on a disc

Until now a game had to be a folder holding a setup_*.exe, and anything else was refused with No GOG installer in this folder. That ruled out an installed game, an unpacked archive, an itch.io download and anything portable. It was asked for publicly by somebody who had burned a 17 GB GOG disc with DiscWright and then wanted the same disc from files GOG never packaged.

No GOG installer is now a question instead of a refusal:

• every executable in the folder, largest first, because an installer is rarely the smallest thing in a game folder
• above them, No installer: put the files on the disc and let the menu open the folder — selected by default, since a wrong installer is a menu button that runs the wrong program while no installer is only one button fewer
• Cancel adds nothing, and stays distinct from no installer, so cancelling cannot add the entry you just refused

The whole folder goes on the disc with its subfolders intact. A GOG download is an installer and its numbered parts in one flat folder, so it has no shape to lose; a game whose data\ folder was flattened onto the disc root is a broken game.

A game with no installer gets Open Folder in the menu where Install would be, which opens that game's folder on the disc.

The question also reports what is about to go on the disc — the folder's file count and total size — and says so when the folder is where your downloads live rather than a game. Picking C:\GOG Games instead of one game inside it is the likeliest way to end up here by mistake, so it names the first download it found in there and suggests cancelling. A warning and not a refusal, because a real game folder can have a setup_*.exe buried somewhere under it too.

The bug a real game folder found

Built against a real 4.9 GB installed game rather than only against fixtures, which is how this turned up: the build clears stale disc icons out of the disc root by name, and a game folder carrying gog.ico or support.ico at its top level had them deleted from the disc straight after being copied there. Files the disc itself puts at the root are now left alone.

Nothing changed for GOG discs, measured

The same two-game disc — Hollow Knight with two of its patches as add-ons, and Dead Space with its .bin parts, from real GOG downloads — was built once with 0.7.6 and once with 0.8.0:

	0.7.6	0.8.0
Files on the staged disc	14	14
Files present on only one side	0	0
Installers and .bin parts	identical by SHA256	identical by SHA256
autorun.inf, disc icon, Linux icon	identical	identical
ISO size	10,002,694,144 bytes	10,002,694,144 bytes

The only file that differs is menu.hta, and its diff is the new code alone: every installer path in it is character for character the same.

Checksums

DiscWright-0.8.0-setup.exe  94CA86CCE67F244E8AB831986BFF2C3189F40C3C9221A4171AF61DB073DBF738
DiscWright-0.8.0.zip        FD192BBCCA0C5057A8F51635394444D782DC95D5DFE40A3C6A62E872CD3470A3

Tests: 468 logic, 92 window.

DiscWright 0.7.6

A bug-fix release, one fix. Nothing needs migrating: project files and the disc layout are unchanged, and a 0.7.5 project opens and rebuilds exactly as it did.

Rebuilding a disc you had reopened lost its icon and background

Open existing disc... points the icon, the background and the extra content at the files on the disc itself, which is where a built disc keeps them. Rebuilding renames that disc folder aside, because the build reads from it, and deletes it once the ISO is written.

The project file was saved in between, so it named files inside the folder that was about to go:

IconPath : ...\out\disc.previous-75c8a5b8\PROJDISC.ico

Reopen that project and the icon and the background were simply missing, and the next build quietly had neither. The disc just built was fine; what was lost was the ability to open it again and rebuild it.

Those paths now name the disc folder the build has just written, where the same files are. The games list was already handled; these were what was left.

Found while porting the project file to the Linux version of DiscWright, which is under way and builds the same disc, and measured here by running a build before the fix.

Checksums

DiscWright-0.7.6-setup.exe  31EC3BF618F18ACB449ADB1ABC29A5C507441E843FB09FD260B5F1D5516DCDAE
DiscWright-0.7.6.zip        94D78DBC9BB215D00413D719F55F448E2F48D62B6BCCD4AADBC850A4677B9FAF

Tests: 442 logic, 84 window.

DiscWright 0.7.5

A bug-fix release, all three fixes in the autorun menu. Nothing needs migrating: project files and the disc layout are unchanged, and a 0.7.4 project opens and rebuilds exactly as it did. Rebuild a disc to get its menu redone.

No more light line along the top of the button panel

The menu's background is darkened all over, and darker still behind the buttons. Both were drawn with smoothing on, and Windows' drawing library smooths a shape that starts at the very edge by covering only half of the first pixel. So the top row, the left column and the first column of the panel got half the darkening, and so did the top pixel of the divider. On dark artwork you could not see it. On bright artwork it was a thin light line along the top of the panel.

Those shapes are whole pixels, so they are now drawn without smoothing, and the divider starts one pixel above the picture.

A long title no longer runs off the menu

With title on artwork ticked, the title shrinks until it fits. It used to stop shrinking at 12pt whether it fitted or not. "Warhammer 40,000: Dawn of War - Game of the Year Edition" is 451px wide at 12pt, with 416px of room, so it ran under the button panel, or off the edge of the menu with the panel on the left. It now keeps shrinking down to 6pt when it has to. A title that fits comes out exactly as before.

A renamed game could stop the menu working

The menu is built from a template with a dozen placeholders, such as %%GAMES%% and %%BTNS%%, and they were filled in one after another. So text that had already been filled in could be filled in again. A game renamed Game %%BTNS%% Edition got the list of buttons pasted into its name, the menu's script no longer compiled, and the disc opened to nothing. GOG never names a game like that, but Name on the menu accepts anything. The placeholders are now filled in a single pass, and ordinary menus come out byte for byte as before.

All three turned up while porting the menu to the Linux version of DiscWright, which is under way and builds the same disc. Its output disagreed with the Windows app's, and each time the Windows app was the one that was wrong.

Checksums

DiscWright-0.7.5-setup.exe  078FBB9F578DDE5C44E84ACE36C2DA76440D8F8272B6A801EA93756FAC2B26DC
DiscWright-0.7.5.zip        D89F7482F655F1889F76F9962A9FAE5763E3B3419CEEA2EF8908075480041983

Tests: 438 logic, 84 window.

DiscWright 0.7.4

A bug-fix release, both fixes in the disc's icons. Nothing needs migrating: project files and the disc layout are unchanged, and a 0.7.3 project opens and rebuilds exactly as it did. Rebuild a disc to get its icons redone.

The icon a disc shows on Linux was wrong for almost every icon

With named on Linux ticked, a disc carries a PNG copy of its icon for Linux desktops, made from the icon's largest frame. That frame was read through Windows' old icon class, which can't decode a frame stored as a PNG. Since Windows Vista, that's how an icon's 256px frame is normally stored.

What came out depended on how the icon was laid out:

icon	Linux icon on the disc, before	now
256px frame stored as PNG	the build failed	the icon
a real game's own icon (Alan Wake's)	random noise	the icon
the layout DiscWright itself writes	blurred, upscaled from 128px	the icon
plain bitmaps up to 256px	blurred, upscaled from 16px	the icon

So since 0.6.0, a disc named for Linux showed a broken, noisy or blurred icon there for almost any icon with a 256px frame. DiscWright now reads the icon file itself, finds the largest frame, and decodes it as what it is.

No more see-through rim

Scaling a picture, Windows' drawing library samples a little past its edge and blends in transparency. So the outermost pixels of every icon frame, and two edges of most menu backgrounds, came out partly see-through. On the menu's dark backdrop that showed as a thin line round the artwork. Every scaled drawing now mirrors the picture at its edges instead.

Both turned up while porting the icon code to the Linux version of DiscWright, which is under way and builds the same disc. Its icons came out right, so they disagreed with the Windows ones.

Checksums

DiscWright-0.7.4-setup.exe  40E092364D3CADABA0A3B32ECBE9BB280BFE521D3272FC41153E6F9FEC07DD34
DiscWright-0.7.4.zip        394DBC6C399D58B766AE3064F8F42AB0A55246A472023AF3E5FCC4FEC0C7E652

Tests: 426 logic, 84 window.

DiscWright 0.7.3

A bug-fix release. Nothing needs migrating: project files and the disc layout are unchanged, and a 0.7.2 project opens and rebuilds exactly as it did.

A game's Install button could point at nothing

On a disc with more than one game, each game gets a numbered folder named after it, cut to 48 characters. Only spaces were trimmed after the cut, so if the cut landed on a dot, the folder name ended in one. Windows creates a folder without its trailing dot and says nothing. The menu kept the dot, so that game's Install button led to a folder that wasn't there.

It needs a title whose 48th character is a dot, so it's rare. But the disc built without any warning and would only have failed in the drive. Dots are now trimmed after the cut too.

Nothing stores these folder names. They're worked out fresh on every build, so rebuilding an older disc gives exactly the folders Windows was already creating.

This turned up while porting the same function to the Linux version of DiscWright, which is under way and builds the same disc.

Also in this release

The window tests click through the menu. Until now they opened the menu preview and stopped. The new tests walk a two-game disc through the chooser, a game's own screen with its add-ons, Back, the other game and Exit, and count the buttons on each screen.

Checksums

DiscWright-0.7.3.zip        E0E339E69BC2AFD4B949CE16052F56775A200D8677E8FB4AAA76C49073B799B1
DiscWright-0.7.3-setup.exe  83484167DFD45CF49466A1910A9C99385896A6161F8FB044906583D46BA94849

Tests: 417 logic, 84 window.

DiscWright 0.7.2

A bug-fix release. Nothing needs migrating: project files are unchanged, the disc layout is unchanged, and a 0.7.1 project opens and rebuilds exactly as it did.

Readable on Windows XP and older now says no when the answer is no

0.7.0 added a box that writes ISO9660 and Joliet filesystems beside the UDF one, so a disc can be read on Windows XP, 2000, ME, 98 and 95. The box greyed itself when a file was too big for those filesystems, using ISO9660's own limit of 4 GiB minus a byte.

That limit is wrong. IMAPI, the Windows image writer that builds every disc DiscWright produces, stops at 2 GiB exactly. So a disc could pass the check and still fail, and it failed late, after staging the whole payload:

Adding ISO9660 and Joliet beside UDF, so the disc reads on Windows XP and older.
ERROR: Data file is too large for 'ISO9660/Joliet' file system.

Found on a 7.79 GB game whose largest part is 4,294,040,574 bytes, a byte under 4 GiB and nearly twice what the writer accepts. The ceiling is now the measured number, and tools\Measure-IsoFileCeiling.ps1 measures it again on any machine: it takes a file of exactly 2,147,483,648 bytes and refuses one byte more, with or without Joliet, and Joliet cannot be requested on its own.

What this costs you. GOG splits its installers into parts just under 4 GiB, to stay under the identical FAT32 ceiling. That is twice this limit, so a game that arrives in parts cannot have the older filesystems at all. Those discs stay UDF only, which needs Windows Vista or newer. A game that arrives as a single installer under 2 GiB can still have it, and so can a disc of manuals, patches and extras.

The box greys itself and names the file that is the problem, rather than letting you find out several minutes into a build.

If you built a disc with that box ticked and it worked, nothing about it changes. If you built one and the build died, this is why.

Thanks again to u/kelphelpOG on Reddit, whose Windows XP and 98 testing prompted the feature in the first place. This narrows it, and it is better to know the shape of it than to have a box that sometimes throws a build away.

Also in this release

The window tests can walk a folder dialog. The test harness has always taken arguments for stepping through a folder tree, and they had never moved anything: Browse For Folder opens with the keyboard focus on its OK button, so every arrow key went to a button and OK returned the folder it started on. Nothing caught it because every test so far picked the folder the app had already seeded.

The demonstrations in the README were re-recorded. Both still showed 0.4.0, three releases back. The new ones show the compatibility row, including the XP box greying itself for a game that came in parts, and the one-game demonstration still ends on a real build of a real 7.79 GB disc.

A skill that records them, by driving the window rather than filming it, so the next time they go stale it costs ten minutes and nobody has to touch the machine.

Checksums

DiscWright-0.7.2-setup.exe  E15AC76905D62A84A7914248CA9CBA584DE0756389CC8042A8269BD0025665C1
DiscWright-0.7.2.zip        09441179982CB95809EA355737623D1B6EDEDBF921746EC66A92D3A62D8DF359

Tests: 415 logic, 78 window.

DiscWright 0.7.1 - the menu's buttons work on Windows 98

A patch release, a day after 0.7.0. Nothing needs migrating: project files are unchanged, the disc layout is unchanged, and a 0.7.0 project opens and rebuilds exactly as it did.

The menu's buttons work on Windows 98

0.7.0 made the disc readable on Windows XP and older. Thanks to u/kelphelpOG on Reddit, who went and tried it on real Windows 11, XP and 98 machines:

I tried the ISO on Win11, WinXP and Win98, and they ALL autorun and work great except for Win98... None of the buttons work on the interface BUT the DVD or CD is explorable and able to be read, and on Win98 that's what counts!

The buttons had a single cause. The menu opened everything through Shell.ShellExecute, and that method needs shell32.dll 5.0 - Microsoft documents it as Windows 2000 or newer. Windows 98 has the Shell.Application object and not that method, so every button threw and nothing happened.

Opening now goes through one helper that tries ShellExecute first and falls back to WScript.Shell, which has been there since Windows Scripting Host shipped with 98. The modern call is tried first, so on Windows 2000 and anything later the fallback is never reached and nothing changes.

What that is worth on a 98 machine is the half of the disc that works there. A GOG installer will not run - they declare Windows 2000 as their minimum in their own headers - but Manual and Extras open, which is what a 98 box actually wants from one of these discs:

the fact that I CAN put old game patches and other content and use it to open via extras is fantastic!

Play still will not work on 98, for an unrelated reason: it searches the registry through WMI, which 98 did not install by default. Left as it is, since a GOG game cannot install there for Play to find.

This has not been tested on Windows 98. There is no 98 machine here, and the tests only prove the code is shaped correctly - that every button routes through the one helper, and that the fallback exists in the right order. If you have the hardware and try it, I would like to know either way - and thanks again to u/kelphelpOG, who has offered to.

Checksums

DiscWright-0.7.1-setup.exe  70A4788B2C18306F27B3B599B4EFA7DCA900079153571530D7F338FB1DD87DC3

Tests: 413 logic, 76 window.

DiscWright 0.7.0 - a disc Windows XP can read

A minor bump rather than a patch, and the rule at the top of the changelog says why: below 1.0.0, minor is reserved for a change to the project file format or the on-disc layout. This release changes both.

Nothing you already have breaks. A 0.6.0 project opens exactly as it did, and rebuilding it produces the disc it produced before.

A disc Windows XP can read

New checkbox, off by default, beside the Linux one:

Also make the disc:  [ ] named on Linux   [x] readable on Windows XP and older

DiscWright writes the ISO as UDF 2.50, and Windows Vista was the first version that could read that. So on Windows XP, 2000, ME, 98 and 95 one of these discs could not be mounted at all. Not a missing menu, not a broken autorun: the drive letter appeared and the disc would not open.

Somebody trying exactly this described it better than I could:

If its WinXP, it sees the Drive and Drive Letter, but unfortunately does not say anything. Disc is not explorable, autorun does not work, nothing.

Tick the box and the disc carries ISO9660 and Joliet as well. Every system takes the newest filesystem it understands and ignores the rest, so a disc built with it ticked behaves on Windows 11 exactly as one built without it. That was checked by building the same disc both ways and comparing every file by SHA256, not by reasoning about it.

Old DVD players and other appliances that only speak ISO9660 benefit from the same box.

Two things that were supposed to make this impossible

Neither survived being measured.

Joliet holds filenames to 64 characters. It does, but IMAPI writes long names into the ISO9660 tree regardless. A real 96-character GOG patch filename comes through intact, and there is a test using that exact name.

ISO9660 keeps a file's length in 32 bits, so it cannot describe a file of 4 GiB or more. True, and GOG already lives with it: its installers split at 4,294,967,294 bytes, one byte under, because FAT32 has the same ceiling.

Where a file really is too big, the checkbox greys itself and says why. If something added in step 5 slips past that, the build re-checks the finished disc folder and falls back to UDF alone rather than write an image that has lost a file to a 32-bit field.

Reading a disc is not installing from it

Joliet long filenames go back to Windows 95, so the disc itself browses a long way back. The games do not. Every GOG installer checked declares Windows 2000 as its minimum in its own PE header, and Windows 9x refuses to load a program asking for 5.0.

So on 98 and 95 the disc opens and reads correctly and nothing on it will install. XP and 2000 are the oldest versions where the disc is genuinely useful. That still has a use: an era-correct patch sitting in step 5 beside an installer 98 will not run.

Confirmed on real hardware

This shipped saying it did not claim to fix autorun on Windows XP, only the disc being unreadable there, because nobody had tested the rest. Somebody has now, on the machines themselves:

I tried the ISO on Win11, WinXP and Win98, and they ALL autorun and work great except for Win98.

So Windows XP autoruns and runs the menu. Thanks to u/kelphelpOG on Reddit, who went and found out on real hardware, which is not something I could do from here.

Windows 98 reads and browses the disc, which is the part that matters there, but the menu's buttons do not work. That is a version floor rather than a bug in this release: the menu launches things through Shell.ShellExecute, which needs shell32.dll 5.0 and is documented as Windows 2000 or newer. Windows 98 has the object and not the method. Being looked at for the next release.

Documentation

Two things a disc costs to learn, now written down.

Burn the ISO, or the disc folder's contents - never the folder itself. Burning the disc folder puts everything one level down, so the disc carries E:\disc\autorun.inf rather than E:\autorun.inf. AutoRun only ever reads the root, so one level down it is an ordinary file nothing looks at. The disc still opens and the menu still runs when double-clicked, and autorun is simply dead, on every version of Windows.

What step 5 is for. It was described as somewhere to put loose files, which says nothing about why. A GOG installer will not run on Windows 98, but an official patch from that era will, and a disc is the easiest way onto a machine that has no business being online.

Project files

Schema 8, which adds one field: whether the disc should also be readable on older Windows. Absent in anything older, where it reads back as off.

Checksums

DiscWright-0.7.0-setup.exe  4C9F220AD0160B31A2D9368FC295D6897BA7E2B38925D625118FAE10F924142F

Tests: 409 logic, 76 window.