Implement makeWin2kImage

[io12]

I think this can be done without vncdotool, tesseract, or expect with Windows 2000's unattended installation feature, and this also makes it easier to configure the install from Nix. I just need to figure out how many times to restart dosbox for the install to finish. And also maybe there's a better way to specify answerFile than a path that is usually created with writeText "answers.ini" (lib.generators.toINI { } { ... })? Having answerFile be the set directly might be easier for the user to specify but less flexible.

[MatthewCroughan]

I see you're removing some comments like the link to some blog post you found in the process of making this, but I'd prefer to keep them since they're valuable, please do! 😸

[io12]

I see you're removing some comments like the link to some blog post you found in the process of making this, but I'd prefer to keep them since they're valuable, please do! 😸

I deleted that link because I'm using a different approach now, but I guess I can add it back and say that in the comment.

[MatthewCroughan]

Very impressive, this just works completely due to the unattended installation. I think we should probably still do tesseract OCR just to provide a log, since the installation takes so long.

[Luflosi]

What's the status of this PR?

[io12]

What's the status of this PR?

It worked on the latest commit when I last tested it. I don't know if there is anything blocking merging.

[MatthewCroughan]

Nothing really, I was just bike shedding on making docs and making the drvs more reliable, since there is an error rate for all of the Windows derivations that increases as you increase in Windows version.

So dos is pretty reliable, then win 3.1 is also reliable, but it gets bad after that. Some of that is related to dosbox instability in my testing.

Did you see https://github.com/ptitSeb/box86 is being maintained a lot lately? Maybe we could write a "NixThePlanet driver" for that, and get rid of dosbox as the builder.

[io12]

I've used box86 in the past. I think it doesn't do full-system emulation and is closer to qemu-user for emulating x86 linux executeables directly. It also can translate library calls so that the emulated program can call native ARM libraries, which is really cool.

[MatthewCroughan]

@io12 https://x.com/oerg866/status/1853402804297118197 found this very interesting, maybe we can apply some of it. Also, will you be at FOSDEM?

[io12]

https://x.com/oerg866/status/1853402804297118197 found this very interesting, maybe we can apply some of it.

Interesting. It looks like it needs an existing installation to build the installer ISO though, which might not be as pure.

Also, will you be at FOSDEM?

Probably not

[MatthewCroughan]

I was thinking, to make things more reliable we could probably use qemu/86box as the builder, rather than dosbox. And we can swap qemu/86box at will when running or building the image. In theory our OCR/vnc scripts can be made to work given the same framebuffer size, and would work on real hardware, qemu, 86box, it wouldn't matter.

[io12]

I was thinking, to make things more reliable we could probably use qemu/86box as the builder, rather than dosbox. And we can swap qemu/86box at will when running or building the image. In theory our OCR/vnc scripts can be made to work given the same framebuffer size, and would work on real hardware, qemu, 86box, it wouldn't matter.

Yeah, I think it might be a good idea to still have dosbox as an option though, especially since it's not as easy to install win2k and XP in dosbox so it's good to have a reproducible way to do that.

[MatthewCroughan]

@io12 Another thought.. we could train a neural net/model to perform this installation, where the loss function is governed by NixThePlanet exit codes.