The XP era security was a joke. I used to open notepad, bring up the dialog to open a file, right click on an executable that was "blocked" and run it from there.

I was once using a public library computer that was loaded full of malware despite all of the "security" software, and I asked the library staff if they were okay with me working around it, to could uninstall the malware. I was expecting that they'd defer to some policy only allowing the county IT department to mess with the computers, but instead they were excited that I new how to do so and had no complaints.

I was in 10th grade in 2003. Time sure does fly.

To be honest, while KolibriOS is open-source, I wouldn't call it "active" that much. MenuetOS has progressed much further than KolibriOS over the years in both performance (it has SMP support!) and being 64-bit.

You can check the commit activity: https://git.kolibrios.org/KolibriOS/kolibrios/commits/branch... - last commit on the first page is already 10 months ago.

And compare it to "News" on the MenuetOS page: - 22.01.2026 M64 1.58.10 released - Improvements, bugfixes, additions

- 26.08.2024 M64 1.53.60 released - MPlayer included to disk image

- 24.07.2024 M64 1.52.00 released - Partial Linux layer (X-Window/Posix/Elf)

- 12.07.2024 M64 1.51.50 released - New graphics designs by Yamen Nasr

- 08.05.2024 M64 1.50.80 released - Fasm-G, many 32 bit apps & sources

I wonder why that is. I imagine there's a number between 0 and 1 that reflects how many people have an interest in stealing and commercializing this project.

I remember doing this too, a little bit later. It would churn on the disk for minutes on end, and usually fail. I think I got it to work once or twice.

Floppy disks and drives were plentiful, but scrap in those days. So of course those were the machines I got to play with as a kid at that time. Many of my disks were not in the best condition, or they were some of the post-2000s ones that were low quality to begin with.

I remember people were making various editions of "mini windows" 3.11 on a floppy disk around that time also.

I bought a USB floppy drive specifically to run MenuetOS on a floppy in like 2007, they still sell them.

i would say that some cd burning software has the ability to make the cd bootable by copying syslinux and whatever else you need - or a floppy image. So you could just use the boot part of the CD-R.

however, only one of my machines has a permanent optical drive, so even this is going by the wayside.

now-a-days if i'd personally use this sort of thing for thin clients, with bootp/etc https://www.kernel.org/doc/html/latest/admin-guide/nfs/nfsro... unsure if that guide is correct, i just skimmed it. I've done this before, but not for GUI, for compiler farms (distcc-pump, et al)

I'd assume you can get USB floppy drives for 3½" disks pretty cheaply. I think I might've even seen that in my BIOS settings as an option.

Where is the source? I only see driver and application source.

Is it still snappy when you're loading an 1Gb document though? And is it as secure as macOS when opening untrusted content?

Lots a bloat are caused by inefficient programming, but not all bloat is useless.

I doubt you’d wish for it if the price was the limitations and incompleteness of MenuetOS. While hobby operating systems are great for exploring possibilities, you quickly bump into an endless stream of tiny frustrating inconveniences.

Part of the skill and challenge of writing in Asm is knowing how to simplify your problem so that you don't need to write so much of it (and beneficially, so that the machine doesn't have to execute so much either.) For example, a typical programmer raised on HLLs would think nothing of allocating and freeing a string object, and then another, and then another just to concatenate them and pass the resulting value to another function, in a loop that processes some data. That's a few dozen bytes of source code that compiles into a few hundred or even kilobytes or more if you include the memory allocator. The Asm programmer would for instance realise that the first string is a constant and the second is only a single character, and just allocate statically a single buffer big enough for both, and only modify the single character in the buffer, turning what the HLL'er would need a few hundred instructions to accomplish into a single instruction; and then write the dozen bytes of source code for that instruction, compiling into a few bytes of binary.

Repeat this process for everything, and you can easily see how an OS that might contain 1GB of compiler-generated code could fit in 10MB of handwritten Asm.

I also wonder how adjustable MenuetOS is. It looks as if the default theming in all those screenshots is quite basic, always fitting to just one style only.

Early versions of Windows, even 3.x, were quite themeable, and the base OS was only around 10MB, mostly a mix of C and Asm; of course, the C parts occupied far more space, but it's not hard to imagine e.g. rewriting Windows 95 in pure Asm and having all that functionality including theming in 1/10-1/50th the space.

>"On the other hand ... to me it always felt as if I'd waste too much time writing assembler code. I like being able to express thoughts and ideas, via code, in a more easily manner, e. g. ruby"

Old fart here. Never mind assembler. I've started with machine codes directly. Anyway early on I'd written fairly big programs using assembly. Was not too difficult. First you developing little functions, like a lot of the, and then you call those and along with using macro facilities it looks almost high level.

Not even close.