OSDev.org

Hello fellow OS-devers!

I am happy to announce, from Tokyo, the first (pre-release) Live CD of my OS.

This Live CD features the complete^ base image of とあるOS in a 64 MB ramdisk environment on a bootable CD.

Release notes and ISO download

Preview screenshot

This is a pre-release demo: there are still many unimplemented features in とあるOS. We appreciate well-researched bug reports, but be mindful of the myriad known issues and limitations with this release. The Live CD requires at least 256MB of RAM and a display setup that supports a 1024x768x32bpp mode through VBE (if you're using QEMU, that means you'll need "-vga std"). No permanent installation methods are offered at this time. The Live CD has been tested under QEMU and VirtualBox, but other emulators should work. If you wish to use the live CD on real hardware, you will need a PS/2 keyboard and mouse (or compatible configuration) - be aware that we have not had the opportunity to test とあるOS on a wide variety of hardware.

とあるOS contains some third-party software. For license information on とあるOS itself as well as software included in the source release, please see here. For license information on other included software, see here. Please note that documentation is not included on this release of the CD, but rather is distributed online at the links previously noted.

Random technical details:
- Kernel: toaru 0.11.1-d0518b1
- CD bootloader: GRUB 2.02~beta2-15
- ISO file size: 70.7MB
- Ramdisk size: 64MB (33MB binaries, 14MB fonts, 12MB wallpapers)
- Default user: local (password 'local')
- Included fonts: Deja Vu (family), VL Gothic, Symbola
- C library: Newlib (heavily patched)
- Bitcoin address for donations: 1BYbZvabmFZBzNVVb4AJfuGLeWRYywxAbk


^: Test binaries and a few extraneous demos have been removed to keep the ramdisk under 64MB. Additionally, vim and the GNU toolchain are not included on this release of the live CD, as they are not part of the "core" installation. We'll get them in a future, larger Live CD.

Hi! The OS is great, but there's a lot of issues. Graphical demos cause the system to slow down and "sudo cmd-that-does-not-exist" leads to an infinite loop of asking for a password (if it's right, otherwise "3 incorrect password attempts"). Tested in VirtualBox. Anyway, congrats!

Since you're using VirtualBox, I assume you have virtualization extensions enabled. Are you by any chance on a retina/hidpi setup? VirtualBox has an issue where guest scaling causes severe slowdown for mouse/keyboard input when receiving a lot of screen updates, and running on a retina display will force scaling. If that's the case, try to use a "normal" DPI setting. Interestingly, it doesn't seem to actually affect the guest performance (as indicated by framerates from `gears`), just the responsiveness of VirtualBox itself. On OS X, you can set the VirtualBoxVM binary to "Open in Low Resolution" which will also provide the desired effect, as it pushes scaling to the window manager, but that involves digging through Finder to get to it.


Oops, this is a pretty obvious bug looking at the code for `sudo`, it's missing a return from a loop... e: I'm uploading a fix for this.

So far I've tested it on two machines, and it didn't work too well on either of them.

One got as far as loading the RAMdisk, then rebooted. It only has 96MB of RAM, so I wasn't expecting it to work properly anyway, but it would be nice if it halted with an error message instead of rebooting. (Maybe this is a feature request instead of a bug report?)

The other also got as far as loading the RAMdisk, then stopped at a black screen. It has 512MB, so I was hoping to at least get an error message or something.

I'm going to dig up a few more machines later. Maybe とあるオペシス will work on one of the newer ones.

Is there anything I can do that would help you diagnose issues when it won't boot?

If you are on a machine with <=512MB of RAM, it probably doesn't have GPU support for the required display resolution and bit depth. You can use GRUB to query what display modes are available from VBE, but I suspect your machine may only support 24bpp modes, which will not work (the graphics pipeline in ToaruOS is not only optimized for 32bpp modes, it does not support outputting to a 24bpp mode at the moment). Either way, とあるOS does not have facilities for switching display modes on generic VGA/VBE hardware, so there's no way to visually display an error message in either of these cases. For the 512MB RAM machine, you can attempt to run the VGA terminal and see if that functions. When running the graphical environment, there are a few other things that とあるOS requires, such as MMX/SSE support. Thanks for trying it, though!

Now I'm getting a blinking cursor in the top left corner, but it still doesn't look like it's doing anything.


I guess I should've been using the VGA terminal from the start; neither of the machines I tested so far have SSE support.


You're welcome!

Awesome work klange! Love to play around with your programs. And mess with Yutani

There sure are some bugs, but thats to be expected. Your work looks very promising and really inspires me.

Hi,

I first tried ToaruOS in VirtualBox. I couldn't do much, because graphics were slow (don't worry, my OS was also slow in it). So I went ahead and copied your iso to a USB flash drive.

The GUI looks promising, but there are some issues.

• There is no option to resize windows.
• The windows that is newly opened is sometimes in an undesired position or/and not auto focused. Ideally, when we open a terminal, we want to type commands immediately, and not after clicking once again over it.
• You can't close graphical demos (for example gears). There is no x. I tried then Ctrl+C, Alt+F4, right clicking on the label at the topbar, and finally Ctrl+Q. It closed. You should consider make more obvious how to close some windows.
• There is no way to power off properly. The power button on the top-right corner was expected by me to draw a pull down menu which lists options such as logout, poweroff, reboot, etc (and not just reboot without prompting the user).

But overall, you have done a good work. Your OS is surely one of top ones and many can only dream of making such an advanced OS. I'm waiting for your OS to become a mainstream one.

Regards,
glauxosdever

Yes, Retina. Any chance for the OS to run on a MacBook Pro (via rEFIt)?

I said I would, and I did. This time the results are more positive.

Machine number 3 is an old Gateway laptop. Unsurprisingly, the GUI doesn't work (and even if it did, the LCD is only 800x600 so it wouldn't be too usable without an external monitor). The VGA terminal works okay, although the blinking would probably get annoying after a while. Many keys on the keyboard don't do anything: home, end, delete, and the number pad were all conspicuously nonfunctional.

Machine number 4 is... I'm not really sure what it is, but it runs 64-bit Windows 7 so it's definitely the newest test machine so far. It boots into the GUI, at which point I get stuck because I don't have a mouse connected and I can't figure out how to navigate the GUI without it. I'll probably try this again later after I've found a PS/2 mouse I can use.

Going through these one-by-one:
- There is an option to resize windows, it's Alt + Middle mouse button as in Gnome and Compiz. The tutorial will note that in the future. Pure mouse-driven resize with window edges is also in the works, I think I even have a ticket for it.
- WM focus stealing is something I should work on... Most apps try to open in reasonable places, but there's also not a lot of work done there.
- All of the random apps without window borders should take 'q' as a hint to get lost. Ensuring they all show up in the panel and adding a context menu there should help, and I've been thinking about standardizing Alt+F4 to close windows.
- The logoff/power button's behavior in the live CD is kinda specific to the live CD. In the normal environment, it returns you to the login screen. A future improvement will be to show a dialog instead. Actually shutting down is, as we all know, a bit more complicated (no ACPI in ToaruOS at the moment).



It's unlikely I'll get device drivers for the keyboard/mouse any time soon, but rest assured I'm at least working on getting things to boot on my MacBook.

Incidentally, the very-recently-released VirtualBox 5.0 has an option to set individual VMs to run without hi-DPI scaling. This produces a very small window, but it solves the scaling issue (just don't try to enable scaling manually afterwards). My other solution also still works, and I think it's a better solution (enable "Low Resolution" for the VirtualBoxVM binary, which you can get to from the context menu on the VM window in the dock -> Options -> Show in Finder -> Command+i).



There are two varieties of VGA text mode commonly available: One supports bright and dark backgrounds, the other uses bright backgrounds as a blink flag. I despise the latter. Not sure how much that affects - the VGA terminal isn't a major point of development focus.

Extended keyboard functionality is a known missing feature, definitely moving it up in priority since it seems to be something a lot of people notice.

Some of the GUI is currently inaccessible by just the keyboard (panel, mostly), but with Ctrl+Alt+T to open terminals and Alt+Tab to navigate windows, you should at least be able to do poke around without a mouse. USB HID support will happen eventually!

Hmm, what could this be?

For some reason, it only detected 1937 MB (1983780 kB) of usable RAM. I was hoping for more than that, but I don't know what the memory map looks like.

The latter is the default mode, but switching to the former is easy to do, and should only need to be done once during initialisation. I did that in some of my experimental kernels (before I went blind, anyway) because I wanted to use bright backgrounds.EDIT: I can't remember exactly how that code works. I remember hacking it together with help from something on this website http://www.osdever.net/FreeVGA/home.htm.

Reads from the status register 1 (port 0x3DA). This sets an internal flip-flop bit to 0 so that the next write to the attribute contoller (port 0x3C0) will go to the index register and not to the data register. The attribute controller is weird in that the same port is used for writing the index (for selecting a register) and the data (to the selected register).


Selects the index 0x10 in the attribute controller. What is actually sent is 0x30 because it's ORed with 0x20 (bit 5). This bit is 1 for normal operation (you can't access the old EGA pallete), and 0 for accessing the old pallette (no image is sent to the screen). After this write operation, the flip-flop is toggled so that the next write goes to the data register.


Reads the current value of this register from the data-read port (0x3C1), sets bit 3 to 0 to disable blinking (and enable bg colors 8..15) and writes the new value to the data-write port (0x3C0). The flip-flop is automatically toggled here too.

By the way, IIRC Bochs and other emulators (which use the same VGA code as Bochs) have a bug handling this. The correct procedure is to ALWAYS toggle the flip-flop in write operations to port 0x3C0, NEVER toggle it in read operations from port 0x3C1, and ALWAYS ignore it in read operations from port 0x3C0. The bug is that the bit is not ignored when reading from 0x3C0 and a 0 is returned instead of the correct value if the flip-flop is 1 when reading. So if you want to restore the previous value of the old pallete flag, you'll be writing a 0 instead of the correct value, therefore setting the screen in black. Now I reset the flip-flop even when reading from this port, which is not neccesary at all in real hardware or emulators without this bug, but it's needed in Bochs.

@Unsigned: Thanks for the explanation!