12 ms·

BootOS: Monolithic operating system in 512 bytes of x86 machine code

588 points by nanochess 7y ago

t3x4c0 7y ago
BootOS developed by a 10x Rockstar Ninja google dev! Oh no, wait...it's a mexican who works with his family at "Familia Toledo"... Guys, i think perhaps we got it all wrong.
ChrisCinelli 7y ago
It seems that this more than a OS is a minimal file system with a obvious limited feature set that relay on the https://en.wikipedia.org/wiki/INT_13H https://en.wikipedia.org/wiki/INT_13H - It assumes that a BIOS that contains a lot more machine code is available. For the new generations this will seem not to have any real applications beyond code golfing. But from a nostalgic point of view, it brings me back to the demoscene era. I still fell a wistful longing for the old days thinking to fr-041:debris ( https://www.youtube.com/watch?v=tq2llbP52Zo https://www.youtube.com/watch?v=tq2llbP52Zo ) 7:20 minutes of awesomeness in less than 199 Kb. BTW, I just google it and apparently there is plenty of events going on... Coming very soon: https://www.assembly.org/summer19/ https://www.assembly.org/summer19/
- kragen 7y ago
  A filesystem, a shell, a program loader, and a hex editor! Well, maybe "editor" is overselling it. But from my point of view, it's as much an "OS" as MS-DOS was. MS-DOS also depended on the ROM BIOS. I agree that it's probably not practically useful. But it's a brilliant hack!
  - devnulloverflow 7y ago
    Yes, BootOS very much in the same space as MS-DOS, although leaning even further on the "less-is-more" axis. It does the same basic things (though I suppose it doesn't do the BASIC thing). Interestingly, there is modern OS in the same space. That's UEFI. Unti I played with it a few months ago, I thought it was some mysterious firmware-adjacent black-box. But actually it's just an OS, very similar to DOS (though it runs in protected mode). It has a shell and some basic built-in commands including text editors and such. And most importantly it lets you run executables that a stored on a FAT (well, FAT32) filesystem. The name BootOS could very well describe UEFI. And equally, a slightly more capable version of BootOS could serve as (very underpowered) UEFI replacement.
    - kragen 7y ago
      I may be confused here, but I don't think UEFI includes a shell — although there's a shell called UEFI-Shell which you can install on your hard disk and run under UEFI — and I think UEFI doesn't have any way to enter machine code from the keyboard. In fact, I think even UEFI-Shell doesn't have any way to enter machine code from the keyboard; is that true? Also, am I mistaken about the status of UEFI-Shell? So, although I am not planning to switch my laptop to running BootOS, I think there are some significant things BootOS can do that UEFI can't.
      - deleted 7y ago
        [deleted]
    - acqq 7y ago
      > though I suppose it doesn't do the BASIC thing What's this then? bootOS programs: (Oh yes! we have software support) fbird https://github.com/nanochess/fbird Pillman https://github.com/nanochess/pillman invaders https://github.com/nanochess/invaders bootBASIC https://github.com/nanochess/bootBASIC And one can test the image: "find a pre-designed disk image along this Git with the name osall.img"
      - devnulloverflow 7y ago
        I meant that UEFI doesn't have a BASIC interpreter (though probably someone has written one). I did not know that bootOS had one, but it does not surprise me given everything else I read on this thread.
        acqq 7y ago
        > I meant that UEFI doesn't have a BASIC interpreter (though probably someone has written one). You wrote something else: > Yes, BootOS very much in the same space as MS-DOS, although leaning even further on the "less-is-more" axis. It does the same basic things (though I suppose it doesn't do the BASIC thing).
- caf 7y ago
  For me the nostalgia this brought back was a memory of boot sector viruses, particularly the way the 'format' command propagates itself onto the new disk.
kragen 7y ago
For those not aware of the background, the author is a wizard from a secretive underground society of wizards known as the Familia Toledo; he and his family (it is a family) have been designing and building their own computers (and ancillary equipment like reflow ovens) and writing their own operating systems and web browsers for some 40 years now. Unfortunately, they live on the outskirts of Mexico City, not Sunnyvale or Boston, so the public accounts of their achievements have been mostly written by vulgar journalists without even rudimentary knowledge of programming or electronics. And they have maintained their achievements mostly private, perhaps because whenever they've talked about their details publicly, the commentary has mostly been of the form "This isn't possible" and "This is obviously a fraud" from the sorts of ignorant people who make a living installing virus scanners and pirate copies of Windows and thus imagine themselves to be computer experts. (All of this happened entirely in Spanish, except I think for a small amount which happened in Zapotec, which I don't speak; the family counts the authorship of a Zapotec dictionary among their public achievements.) In particular, they've never published the source or even binary code of their operating systems and web browsers, as far as I know. This changed a few years back when Óscar Toledo G., the son of the founder (Óscar Toledo E.), won the IOCCC with his Nanochess program: https://en.wikipedia.org/wiki/International_Obfuscated_C_Code_Contest#Toledo_Nanochess https://en.wikipedia.org/wiki/International_Obfuscated_C_Cod... and four more times as well. His obvious achievements put to rest — at least for me — the uncertainty about whether they were underground genius hackers or merely running some kind of con job. Clearly Óscar Toledo G. is a hacker of the first rank, and we can take his word about the abilities of the rest of his family, even if they do not want to publish their code for public criticism. I look forward to grokking BootOS in fullness and learning the brilliant tricks contained within! Getting a full CLI and minimalist filesystem into a 512-byte floppy-disk boot sector is no small achievement. It's unfortunate that, unlike the IOCCC entries, BootOS is not open source.
- msla 7y ago
  > For those not aware of the background, the author is a wizard from a secretive underground society of wizards known as the Familia Toledo Wow. None of this is plausible.
- tcbawo 7y ago
userbinator 7y ago
The significance of 512 bytes is that it is the standard sector size for a PC storage device (the size seen by software; newer hard drives have 4KB physical sectors, but can still be addressed as if they had 512B "logical" sectors), and a traditional BIOS reads the first sector of the boot device into memory and jumps to it in order to begin the OS part of the boot process. A normal OS bootsector would then find and load the next part of the OS, which may involve things like understanding FAT or NTFS filesystems; here's a (rather enthusiastic) analysis of many boot sectors from different versions of DOS and Windows: https://thestarman.pcministry.com/asm/mbr/index.html https://thestarman.pcministry.com/asm/mbr/index.html Writing a tiny program that lets you modify memory, and more importantly execute it, is the first step in the "bootstrap pilgrimage" to creating your own environment and eventually OS, but this one seems deliberately limited; nonetheless, starting with this, one can use it to create the next stage of the bootstrap, 512 bytes at a time.
non-entity 7y ago
Wow this is really cool. I honestly expected this to be just a program that would boot to some text output and maybe a very simple shell, but it looks like this more than that.
bArray 7y ago
I have also developed a very small kernel in 512 bytes, it's a fun exercise [1] (this is a really old project that was uploaded to BitBucket long after it initially started). I quite like this BootOS project, you can of course see the compromises that any OS this size has to make. I would make a recommendation to the BootOS project which is to squeeze a function table as I have done in order to allow programs to call functions in the kernel. If not, you either end up re-writing these functions for each of your programs, you have to recompile your programs any time you change your kernel or you end up trying to maintain jump positions. For those still reading, I'm working on a large overhaul of saxos which includes very simple multi-tasking (currently working). The intention will be to have the kernel load a 512 byte GUI on top and then for the programs to have access to a terminal within the GUI. Once that's working I then want to move towards also allowing programs to draw to the Window, but that also brings its own issues. [1] https://bitbucket.org/danielbarry/saxoperatingsystem/src/master/KERNEL/KERN.ASM https://bitbucket.org/danielbarry/saxoperatingsystem/src/mas...
- nanochess 7y ago
  Cool! I didn't knew of your work. I've been working in the service table, just that it isn't ready yet because I want DS to handle filenames and ES the buffer but currently the segment mangling still is destroying the directory. Almost ready ;)
  - nanochess 7y ago
    bootOS now has a service table and an example program counter.asm to demonstrate it :)
    - bArray 7y ago
      Awesome! I thought about also using interrupts, how much did it affect timing and code size for you?
      - nanochess 7y ago
        Code size suffered because the need to sanitize the ES register to access the directories (PUSH CS + POP ES) but balanced because I made bootOS to call its own services (3-byte CALL is now 2-byte INT) and fortunately IRET is same size as RET. The most difficult thing was to return the carry flag, but the RCL instruction saved me, I'm glad the 8088 processor auto-uses SS when using BP addressing. At some point I was closer to write in paper the segment dependancies along code paths because it's pretty hard to track. Timing I think isn't so important at this moment.
kazz0302 7y ago
Pretty cool!
Eun 7y ago
What I am still looking for, is for a boot os that can boot a normal .iso/.img file from its own device. This will be the perfect usb boot stick. 1. Flash boot os on the boot sector, place any iso/img file on the stick. 2. Boot from the stick 3. select the iso you want to boot Don't know it this is possible though... (I know that there is a emulation mode for virtual cd drives in the bios but thats about it...)
- ComputerGuru 7y ago
  EasyBCD can give you that, but you must run it to update the boot code each time you add an ISO (ie no dynamic detection).
- wolfspider 7y ago
  It is possible with EFI based boot loaders from what I've seen. I was looking for something similar and ended up discovering rEFIt and rEFInd. Although it isn't technically an OS it can autodetect entries from the MBR. http://www.rodsbooks.com/refind/ http://www.rodsbooks.com/refind/
- arantius 7y ago
  You're looking for YUMI: https://www.pendrivelinux.com/yumi-multiboot-usb-creator/ https://www.pendrivelinux.com/yumi-multiboot-usb-creator/ It's not 100% compatible with every ISO, but it's definitely possible to boot more than one thing from a single USB drive.
- notpeter 7y ago
  I've seen various software that does this with multiple installer/liveCD ISOs for Linux distributions but none that could actually boot all arbitrary ISOs (Windows installers, DOS rescue disks) which need to be on a logical device partition. I used to have a 2.5 enclosure that supports this in hardware (Zalman ZM-VE300) but selection of ISO is done on-device before booting. I don't see any reason you couldn't build a hardware/software combo where selection on-screen made the USB hardware mount the selected ISO as a new logical device and then booted it. [1]: http://www.zalman.com/contents/products/view.html?no=212 http://www.zalman.com/contents/products/view.html?no=212

588 points by nanochess 7y ago

BootOS developed by a 10x Rockstar Ninja google dev! Oh no, wait...it's a mexican who works with his family at "Familia Toledo"... Guys, i think perhaps we got it all wrong.

ChrisCinelli 7y ago

It seems that this more than a OS is a minimal file system with a obvious limited feature set that relay on the https://en.wikipedia.org/wiki/INT_13H https://en.wikipedia.org/wiki/INT_13H - It assumes that a BIOS that contains a lot more machine code is available. For the new generations this will seem not to have any real applications beyond code golfing. But from a nostalgic point of view, it brings me back to the demoscene era. I still fell a wistful longing for the old days thinking to fr-041:debris ( https://www.youtube.com/watch?v=tq2llbP52Zo https://www.youtube.com/watch?v=tq2llbP52Zo ) 7:20 minutes of awesomeness in less than 199 Kb. BTW, I just google it and apparently there is plenty of events going on... Coming very soon: https://www.assembly.org/summer19/ https://www.assembly.org/summer19/

kragen 7y ago
A filesystem, a shell, a program loader, and a hex editor! Well, maybe "editor" is overselling it. But from my point of view, it's as much an "OS" as MS-DOS was. MS-DOS also depended on the ROM BIOS. I agree that it's probably not practically useful. But it's a brilliant hack!
- devnulloverflow 7y ago
  Yes, BootOS very much in the same space as MS-DOS, although leaning even further on the "less-is-more" axis. It does the same basic things (though I suppose it doesn't do the BASIC thing). Interestingly, there is modern OS in the same space. That's UEFI. Unti I played with it a few months ago, I thought it was some mysterious firmware-adjacent black-box. But actually it's just an OS, very similar to DOS (though it runs in protected mode). It has a shell and some basic built-in commands including text editors and such. And most importantly it lets you run executables that a stored on a FAT (well, FAT32) filesystem. The name BootOS could very well describe UEFI. And equally, a slightly more capable version of BootOS could serve as (very underpowered) UEFI replacement.
  - kragen 7y ago
    I may be confused here, but I don't think UEFI includes a shell — although there's a shell called UEFI-Shell which you can install on your hard disk and run under UEFI — and I think UEFI doesn't have any way to enter machine code from the keyboard. In fact, I think even UEFI-Shell doesn't have any way to enter machine code from the keyboard; is that true? Also, am I mistaken about the status of UEFI-Shell? So, although I am not planning to switch my laptop to running BootOS, I think there are some significant things BootOS can do that UEFI can't.
    - deleted 7y ago
      [deleted]
  - acqq 7y ago
    > though I suppose it doesn't do the BASIC thing What's this then? bootOS programs: (Oh yes! we have software support) fbird https://github.com/nanochess/fbird Pillman https://github.com/nanochess/pillman invaders https://github.com/nanochess/invaders bootBASIC https://github.com/nanochess/bootBASIC And one can test the image: "find a pre-designed disk image along this Git with the name osall.img"
    - devnulloverflow 7y ago
      I meant that UEFI doesn't have a BASIC interpreter (though probably someone has written one). I did not know that bootOS had one, but it does not surprise me given everything else I read on this thread.
      - acqq 7y ago
        > I meant that UEFI doesn't have a BASIC interpreter (though probably someone has written one). You wrote something else: > Yes, BootOS very much in the same space as MS-DOS, although leaning even further on the "less-is-more" axis. It does the same basic things (though I suppose it doesn't do the BASIC thing).
caf 7y ago
For me the nostalgia this brought back was a memory of boot sector viruses, particularly the way the 'format' command propagates itself onto the new disk.

kragen 7y ago

For those not aware of the background, the author is a wizard from a secretive underground society of wizards known as the Familia Toledo; he and his family (it is a family) have been designing and building their own computers (and ancillary equipment like reflow ovens) and writing their own operating systems and web browsers for some 40 years now. Unfortunately, they live on the outskirts of Mexico City, not Sunnyvale or Boston, so the public accounts of their achievements have been mostly written by vulgar journalists without even rudimentary knowledge of programming or electronics. And they have maintained their achievements mostly private, perhaps because whenever they've talked about their details publicly, the commentary has mostly been of the form "This isn't possible" and "This is obviously a fraud" from the sorts of ignorant people who make a living installing virus scanners and pirate copies of Windows and thus imagine themselves to be computer experts. (All of this happened entirely in Spanish, except I think for a small amount which happened in Zapotec, which I don't speak; the family counts the authorship of a Zapotec dictionary among their public achievements.) In particular, they've never published the source or even binary code of their operating systems and web browsers, as far as I know. This changed a few years back when Óscar Toledo G., the son of the founder (Óscar Toledo E.), won the IOCCC with his Nanochess program: https://en.wikipedia.org/wiki/International_Obfuscated_C_Code_Contest#Toledo_Nanochess https://en.wikipedia.org/wiki/International_Obfuscated_C_Cod... and four more times as well. His obvious achievements put to rest — at least for me — the uncertainty about whether they were underground genius hackers or merely running some kind of con job. Clearly Óscar Toledo G. is a hacker of the first rank, and we can take his word about the abilities of the rest of his family, even if they do not want to publish their code for public criticism. I look forward to grokking BootOS in fullness and learning the brilliant tricks contained within! Getting a full CLI and minimalist filesystem into a 512-byte floppy-disk boot sector is no small achievement. It's unfortunate that, unlike the IOCCC entries, BootOS is not open source.

msla 7y ago
> For those not aware of the background, the author is a wizard from a secretive underground society of wizards known as the Familia Toledo Wow. None of this is plausible.
tcbawo 7y ago

userbinator 7y ago

The significance of 512 bytes is that it is the standard sector size for a PC storage device (the size seen by software; newer hard drives have 4KB physical sectors, but can still be addressed as if they had 512B "logical" sectors), and a traditional BIOS reads the first sector of the boot device into memory and jumps to it in order to begin the OS part of the boot process. A normal OS bootsector would then find and load the next part of the OS, which may involve things like understanding FAT or NTFS filesystems; here's a (rather enthusiastic) analysis of many boot sectors from different versions of DOS and Windows: https://thestarman.pcministry.com/asm/mbr/index.html https://thestarman.pcministry.com/asm/mbr/index.html Writing a tiny program that lets you modify memory, and more importantly execute it, is the first step in the "bootstrap pilgrimage" to creating your own environment and eventually OS, but this one seems deliberately limited; nonetheless, starting with this, one can use it to create the next stage of the bootstrap, 512 bytes at a time.

non-entity 7y ago

Wow this is really cool. I honestly expected this to be just a program that would boot to some text output and maybe a very simple shell, but it looks like this more than that.

bArray 7y ago

I have also developed a very small kernel in 512 bytes, it's a fun exercise [1] (this is a really old project that was uploaded to BitBucket long after it initially started). I quite like this BootOS project, you can of course see the compromises that any OS this size has to make. I would make a recommendation to the BootOS project which is to squeeze a function table as I have done in order to allow programs to call functions in the kernel. If not, you either end up re-writing these functions for each of your programs, you have to recompile your programs any time you change your kernel or you end up trying to maintain jump positions. For those still reading, I'm working on a large overhaul of saxos which includes very simple multi-tasking (currently working). The intention will be to have the kernel load a 512 byte GUI on top and then for the programs to have access to a terminal within the GUI. Once that's working I then want to move towards also allowing programs to draw to the Window, but that also brings its own issues. [1] https://bitbucket.org/danielbarry/saxoperatingsystem/src/master/KERNEL/KERN.ASM https://bitbucket.org/danielbarry/saxoperatingsystem/src/mas...

nanochess 7y ago
Cool! I didn't knew of your work. I've been working in the service table, just that it isn't ready yet because I want DS to handle filenames and ES the buffer but currently the segment mangling still is destroying the directory. Almost ready ;)
- nanochess 7y ago
  bootOS now has a service table and an example program counter.asm to demonstrate it :)
  - bArray 7y ago
    Awesome! I thought about also using interrupts, how much did it affect timing and code size for you?
    - nanochess 7y ago
      Code size suffered because the need to sanitize the ES register to access the directories (PUSH CS + POP ES) but balanced because I made bootOS to call its own services (3-byte CALL is now 2-byte INT) and fortunately IRET is same size as RET. The most difficult thing was to return the carry flag, but the RCL instruction saved me, I'm glad the 8088 processor auto-uses SS when using BP addressing. At some point I was closer to write in paper the segment dependancies along code paths because it's pretty hard to track. Timing I think isn't so important at this moment.

kazz0302 7y ago

Pretty cool!

Eun 7y ago

What I am still looking for, is for a boot os that can boot a normal .iso/.img file from its own device. This will be the perfect usb boot stick. 1. Flash boot os on the boot sector, place any iso/img file on the stick. 2. Boot from the stick 3. select the iso you want to boot Don't know it this is possible though... (I know that there is a emulation mode for virtual cd drives in the bios but thats about it...)

ComputerGuru 7y ago
EasyBCD can give you that, but you must run it to update the boot code each time you add an ISO (ie no dynamic detection).
wolfspider 7y ago
It is possible with EFI based boot loaders from what I've seen. I was looking for something similar and ended up discovering rEFIt and rEFInd. Although it isn't technically an OS it can autodetect entries from the MBR. http://www.rodsbooks.com/refind/ http://www.rodsbooks.com/refind/
arantius 7y ago
You're looking for YUMI: https://www.pendrivelinux.com/yumi-multiboot-usb-creator/ https://www.pendrivelinux.com/yumi-multiboot-usb-creator/ It's not 100% compatible with every ISO, but it's definitely possible to boot more than one thing from a single USB drive.
notpeter 7y ago
I've seen various software that does this with multiple installer/liveCD ISOs for Linux distributions but none that could actually boot all arbitrary ISOs (Windows installers, DOS rescue disks) which need to be on a logical device partition. I used to have a 2.5 enclosure that supports this in hardware (Zalman ZM-VE300) but selection of ISO is done on-device before booting. I don't see any reason you couldn't build a hardware/software combo where selection on-screen made the USB hardware mount the selected ISO as a new logical device and then booted it. [1]: http://www.zalman.com/contents/products/view.html?no=212 http://www.zalman.com/contents/products/view.html?no=212