Announcing the first public release of: SOLO 0.96 A standalone shell and loader for protected mode 32-bit i386/486/Pentium microkernels, full operating systems, and standalone programs. ----------------------------------------------------------------------------- Available now in full source-code from: http://www.csh.rit.edu/~shaggy/software.html ftp://ftp.csh.rit.edu/pub/csh/shaggy (Floppy disk images are also available for a demo) ----------------------------------------------------------------------------- SOLO is free software, for non-profit use. SOLO COMES WITH NO WARRANTIES, EXPRESSED OR IMPLIED. Feature overview: o Loads 32-bit protected mode executables (ELF or a.out format) o Allows BIOS calls from 32-bit mode o Provides file access and console I/O from 32-bit mode o Statically mapped file system provides up to 32MB of startup files (depending upon block size and degree of fragmentation) o Built-in shell o Can run simple shell scripts (can provide menus, prompt for passwords, have timeouts, etc) o Can be booted from any partition (primary or extended) o Can be used to boot any partition (primary or extended) (thus, having SOLO on a floppy disk is great for booting from your hard drive if your master boot record ever gets damaged) o Uses only 32K total memory (which can be reclaimed if needed) o Can pass arguments to 32-bit programs o Can load Linux directly o Can boot other operating systems (and can stuff characters in the keyboard buffer before doing so) o Can co-exist with other operating systems on the same partition or floppy disk o Can scan and list all available text and graphics video modes and let you choose your preferred startup mode o Can redirect console I/O over serial port o Built in monitor for examining/changing memory and I/O o Built in "panic", with full register dump, for standalone programs and kernels that have not yet loaded their own trap or interrupt table - can even trap a CPU reset o Protected mode and virtual memory initialization, to allow kernels to actually start executing in the memory region they are expected to run in o Circular message buffer survives panics to save information that leads to system crashes o Great testbed for writing new operating systems on the PC platform, or for porting existing OS's to it o Extensible built-in "help" command, with descriptions of all built-in commands and other general information o 32-bit test programs included: solotest, hello, fdisk o Free for non-profit use (contact me for information about other uses) File System Details: o Device-independent I/O All I/O is done through file descriptors which can be opened from any file or device, including: Thus, the interface to the 32-bit program only needs open, close, read, write, seek, and tell to communicate. /dev/fdX - floppy disk devices /dev/hdXX - hard drive devices, along with all primary and extended partitions /dev/mem - physical memory /dev/port - I/O ports /dev/console - console I/O /dev/ttySX - serial ports (incomplete for 0.96) o File system Maps out all files that are available, on any disk that is accessible at boot time, meaning that your startup files could, theoretically, be scattered across multiple partitions or even physical disks. Even though it uses a static map, these files can be written back to as well, if configuration information, for instance, needed to be saved. (but there is a 'diskwrite' flag that must be enabled first, to prevent accidental writing to the disk) However, the length of these files cannot change, since this map has no real knowledge of the file system. o Flexibility Since SOLO keeps its own map format of the files you need when booting, it can work with any file system format. (currently, it must use a format supported by Linux, since the 'mksolo' program must be run under Linux, but it could easily be ported to other host operating systems) Library Details: o Small C library and I/O library Some basic C functionality is included in these libraries, libstdc, and libsolo. Libstdc is designed to be the standard portions that are not dependent on any OS features, and libsolo is the I/O interface for SOLO. o Standard libraries Of course, any other standard or custom libraries can be linked in too. Debugging Details: o Debugging Register dumps, examining and changing memory, and reading and writing from ports are all available from the SOLO shell, as well as full access to all boot files (hex/ascii dumps at any offset and of any length) o Kernel message buffer A circular message buffer is kept of all output, and designed to survive many types of system traps, including CPU reset in many cases. o Traps/Interrupts/IRQs/CPU Resets SOLO has default handlers for all of these traps (including serious cases that cause the CPU to actually reset!) Portability Details: o Could be ported to run under DOS/Windows as a protected-mode alternative OS loader Since it tells the program it loads what physical memory it can safely use, it can run well-behaved programs and still allow the programs to return back to the OS that called them. This is not, of course, its intended purpose, but the interface could support this if someone wanted to implement it. o Interface Portability SOLO was designed with portability in mind, to other host operating systems (for building it and the programs that use it), as well as to other architectures. SOLO itself is written mostly in assembly in order to be as compact as possible for the Intel architectures, however the interface it provides to the programs could be provided by boot loaders on other architectures, thus keeping system-specific boot code in the loaders rather than in the kernels, leaving the kernels (and other standalone programs) far more portable. o Elf32 The Elf standard is currently supported by SOLO, which should provide greater compatibility with other operating systems than the older QMAGIC and ZMAGIC a.out formats which are also supported. Booting Details: o Can save the old boot sector and still boot from it. SOLO can co-exist on the same partition or floppy disk as another operating system. This way, you can install SOLO on a disk that had, for instance, DOS on it already, and from SOLO still boot DOS, or load Linux (if vmlinuz was also on the disk), or boot Shag/OS or any other number of SOLO-bootable programs. o Can be booted from Master Boot Record or from a Partition. SOLO can become your new master boot record, and be used to boot everything else on your machine, or it could just exist in a partition, to be loaded when you select it from your main boot selection program. o Can be booted from a Floppy Or, if you prefer not to touch your hard drive, you could just put SOLO on a floppy, from which you can still use it to boot from any partition your hard drives. o Could be extended to allow booting from a network The existing interface to the programs being executed is flexible enough that underlying support could be added to load files from a network or through other means Shell Details: o Shell commands Lots of built in shell commands are available, such as: ls, cp, cat, set, echo, boot, lboot, man, reboot, vmode, vtest, timeout, stuff, redir, dump, write, reg, call, msg, pdir, etc... o Shell command-line editing (on current command, and callback of the last command, with arrow keys), environment variables, parameter passing to executables, through argc and argv[]. o Help Built-in help command with help available for all current features, and easily customizable and extensible. o Startup scripts You can write simple scripts that control the booting of your machine, such as what messages you want printed, what programs you want to run, offering the user a menu, verifying a password for an option, changing the default video mode, timing out after a certain period of time, etc... Protected-mode Details: o Protected mode (32-bit) Since your 32-bit programs start right up in protected mode, there is no need for your kernel or standalone utility to worry about the details of switching from real to protected mode. Also, paging is already enabled when the program starts, so that you can just link your kernel at the address you want it to run at, and SOLO will map it to that address before executing it. From there on, of course, your kernel can remap memory as it sees fit. Information about the program segments that were loaded for the kernel are made easily available. o File access from the kernel The BootParam interface provides console I/O, and file I/O, including open, close, read, write, seek, and tell, so that all boot files are accessible from your kernel before it loads its own device drivers, thus eliminating the "chicken and egg" problem that could exist otherwise. o BIOS access The kernel can make calls back to real mode to call BIOS interrupts, to, for instance, change the video mode, access a non-standard device, get configuration information, etc... Memory Utilization: o Small size SOLO itself is only 12K in size, and the entire memory space used by SOLO, BIOS tables, file maps, and buffers is only the low 32K of physical memory. This space can later be reclaimed by an operating system that no longer needs it after loading. Therefore, this makes it ideal for small systems as well as large ones, and could make it useful for embedded systems as well. Misc: o Linux-load ability SOLO can be used to load Linux kernels directly, and pass parameters to them o What's in a name? SOLO actually stands for the Shag/Os LOader, (Shag/OS is an object-oriented micro-kernel based operating system that is still under development) but it is designed to be flexible enough to handle a variety of kernels and standalone utilities o Demos SOLO comes with a couple small demo standalone 32-bit protected mode programs, including a simple 'fdisk' utility for printing information about fixed disk partition tables. This particular 'fdisk' is not complete enough to change the tables yet, however. These programs should give enough understanding of the interface for you to be able to write your own standalone programs and kernels. Eventually, when the first release of Shag/OS is made, a better example of how to write a kernel for SOLO will be available. o Testing from Unix/etc... A 'emsolo' library is available that standalone executables can be linked against to provide them a simulated version of the SOLO standalone interface. This allows for testing many types of well behaved programs (not including full-fledged kernels that play with system resources, of course) underneath the host operating system (Linux, etc) Sample Scenario 1: If you wanted to write a protected-mode 32-bit kernel for an Intel-based PC from scratch, you would have start with writing some sort of boot code (in 16-bit real mode) which dealt with loading the individual sectors of your kernel from the floppy or hard disk, and then went through all kinds of complicated steps to get your 32-bit protected mode program running, at which point your program could not call any of the BIOS functions, so it would be completely on its own to have device-drivers incorporated already to be able to load any more files it needed. Also, all code used for starting the system would probably permanently reside in your kernel (since it was linked together with it, and it's hard to reclaim parts of a single executable) even though you might never use it again. With SOLO, you just create what you want in your kernel, and let SOLO do the work of loading it for you, putting it in memory where you want it, and going into 32-bit protected mode. And if you need to call BIOS functions, no problem. If you want to load other files, or parts of them, no problem. You can change video modes with BIOS calls or do whatever else you need to do. Until you develop real drivers for the hard disk, you can call SOLO to read from the raw disks or from individual partitions, as well as from the boot files. And if your kernel reaches a point where it no longer needs the services of SOLO, its simple to reclaim all of the memory, leaving your kernel with only the code for the features it is now using. Sample Scenario 2: If you want to write some sort of system-level standalone utility, (or diagnostics, or even perhaps some sort of game or other such program) and you want everyone to be able to run it, you would have to either make versions of it for every operating system people are likely to be running (I know, that's somewhat unrealistic because almost everyone can run a DOS version of it, but just bear with me), or license an operating system to go on the boot disk, or develop your own. Well, with SOLO, you can just make your program use the SOLO BootParam interface, and you now have a program you can distribute on a bootable floppy disk for free, (for non-profit purposes) ------------------------------------------------------------------------- SOLO 0.96 is a pre-released portion of the full Shag/OS operating system distribution. However, it is meant to be useful as a standalone part, and will continue to be released as such even when full Shag/OS releases become available. The purpose of this "sneak preview" is to make this functionality and the knowledge of it available now to those who would find it useful, and to gather comments, suggestions (and even bug-reports) from others to aid in finishing the complete SOLO 1.0 release. SOLO 0.96 is *not* a finished a product, although it has most of the functionality most people probably need. As such, however, I can not and will not take any responsibility for any damages caused by this product. The risk is entirely yours. Therefore, back up all important data before running this program. If you are running SOLO off a floppy disk, you are probably safe as long as you avoid using the hard-disk devices, but it is still a wise idea to back up any important data on your machine. (or disconnect the hard-drive, just in case) To date, I know of no reason why this program would cause any damage to your system or your data if used sensibly, but with any new product on an untested system, it is better to be safe than sorry. Comes with: fconfig (a file configuration utility for incorporating source code for multiple platforms, and for keeping source and build areas separate and customizable) SOLO libstdc, libsolo, libemsolo fdisk, solotest, hello (test programs) Shag/OS License, version 1 various assorted documentation including this announcement Future releases will come with: Elf32