Sanos is a small 32-bit x86 operating system kernel for jbox appliances. A jbox is a JavaOS server appliance running on standard PC hardware. This enables you to run java server applications without the need to install a host operating system. Only a standard Java HotSpot VM and the sanos kernel are needed.
The kernel was developed as part of an experiment on investigating the feasibility of running java server applications without a traditional host operating system only using a simple kernel.
Sanos is an abbreviation of Server Appliance Network Operating System. It is also the Spanish word for healthy. Sanos tries to stay healthy by being simple and not implement unnecessary features to avoid feature bloat. It is focused on being a server appliance operating system. sanos does not come with a huge array of standard applications. It only provides the kernel which supports the basic operating system features. This allows you to write server applications which execute in a controlled and predictable environment.
The basic idea is that using a minimalistic operating system kernel, only implementing the most basic services, will reduce the total system complexity. This allows you to build more robust and predictable systems. These systems will be easier to deploy, install and maintain. This will lower the total cost of ownership (TCO) for such devices. A sanos based web server can be installed in just a few minutes, and does not require a lot of configuration.
See here for a description of the jbox concept.
The sanos kernel runs on standard PC hardware. For a list of supported hardware see here. Hopefully, it will work on any standard PC. For now sanos does not support SCSI disks, so it only runs on machines with IDE disks.
Network drivers are another problem. You can use sanos without network, but in most cases, a network server appliance is no good without network support. The most common network cards are supported by sanos, but there are many different types of network boards.
If sanos does not recognize your network card it may be because the network card is not supported by any of the network drivers in sanos. It might also be because its PCI ID is not listed in the [bindings] section in krnl.ini. If you have a network card that should be supported by one on the network driver but is not recognized by sanos you can try to find the PCI ID for the network card. Use the 'more /proc/units' command on the shell prompt to find the PCI ID and add it to the [bindings] section in krnl.ini.
If you network card is not supported by sanos you will either have to write a driver or buy a new network card. You can buy a RTL8139 based 10/100 Mbps PCI network card for less than $10, so this may be the simplest solution.
Most of the network card drivers in sanos have been ported from Linux. The rtl8139, sis900, and eepro100 driver are ported Linux drivers. It is a relatively easy process to port these drivers. It takes 1 or 2 days to port a driver. Please contact me if you need help on porting a driver.
The sanos kernel implements the basic operating system kernel services like:
Please see here for a more complete list of features in sanos.
You can get the latest version of sanos from the download page. Both source and binaries are available. Older version can also be downloaded from SourceForge.
No. There is a native sanos API. You can develop applications in C using Microsoft Visual Studio. The native sanos API resembles the standard POSIX Unix API, with functions like open(), close() etc. There is also an implementation of the ANSI Standard C library routines. See here for a brief guide to building a simple hello world application in C for sanos.
The source code distribution of sanos comes with project and solution files for Microsoft Visual Studio version 7. It can be compiled with Visual Studio version 6 by converting the project/solution project files in the build directory to version 6 project/workspace files. The prjconverter utility in the tools directory can be used for converting the project. This is a modified version of prjconverter by S. Rod. Alternatively you can use the patches provided by Skyson Zhao.
You can also use Microsoft VisualStudio .NET 2003 to build sanos. When you load the sanos.sln file DevStudio 2003 will automatically convert the project files to the new format. You can then compile and build the kernel, but it will not boot. It will hang in the boot loader saying 'Loading kernel' and then get stuck, or alternatively trap in os.dll after booting. The problem seems to be a "feature" in the project converter in DevStudio 2003. The following compiler options are not converted: /GF, /Oi, /Ob1, and /Gy. If you set these option in the 'Additional Options' under the section 'Command Line' it will work again. Thanks to Mario Smit for providing this information.
If you want to use the project wizard for creating sanos projects under Microsoft VisualStudio .NET 2003 you need to change the second line of sanoswiz.vsz to:
Wizard=VsWizard.VsWizardEngine.7.1
Thanks to Reuven Yagel for providing this information.
Microsoft has made their Visual C++ compiler available for free. It can be downloaded from Microsoft. You can use this compiler to build sanos. The sanos source distribution contains a Makefile which can be used to build sanos using the Visual C++ Toolkit 2003. However, some necessary tools are missing. The following files are missing:
All tools but the MASM assembler (ml.exe) can be obtain freely from the Microsoft Platform SDK February 2003. MASM can be obtained from the Visual C++ 6.0 Processor Pack. If you place these files in the bin directory of the VC Toolkit you should be able to build sanos by opening a "Visual C++ Toolkit 2003 Command Prompt", go to the sanos directory, and type nmake sanos.
You can use windbg (in Debugging Tools for Windows) to debug sanos. It can be downloaded from Microsoft. You need a null modem cable between you target system (running sanos) and you development system (running Windows). Build sanos in debug configuration and install it on the target system.
To use the remote debugger you need the remote debugging gateway (dbggw.exe). This tool can be found in the sanos tools directory. You can find the source code for dbggw in the utils directory. Start the dbggw program from a command line on the development system:
c:\sanos\tools> dbggw com1
When sanos hits a breakpoint the remote debugger is activated. You can use several methods for generating a breakpoint exception:
After sanos has hit a breakpoint (or any other exception) you can start the debugger (windbg):
c:\Program Files\Debugging Tools for Windows> windbg.exe -premote tcp:server=127.0.0.1,port=24502 -n -p 1
The first time you use the debugger you must configure your paths. Set you symbol path to c:\sanos\dbg\symbols (in File->Symbol File Path) and source path to c:\sanos\src (in File->Source File Path). You can now inspect the call stack, local and global symbols etc.
The dbggw utility is based on a reverse engineering of the DRPC protocol. Only a subset of the protocol is yet handled by the dbggw utlity, so please be careful when debugging. Not all commands in the debugger can be used. Single stepping does not always seems to work correctly. I mostly use the debugger for analyzing snapshots situations. I have used windbg version 4.0.0018.0 for debugging. If you cannot find windbg 4.0.0018.0 elsewhere you can download it from here.
Yes, JDK 1.4 is supported from sanos version 1.3.1.
Most of the source code for sanos is under a BSD license. However, some of the network drivers, which have been ported from Linux, are under a GNU public license. The sanos kernel supports dual licensing mode. Because the BSD license is GPL compatible, BSD code can be re-licensed under GPL without problems. This means that the kernel as a whole can be re-licensed under GPL. If you re-license the kernel under GPL you must comply with the GPL conditions, including source code availability etc.
This dual licensing is necessary in order to use the Linux based network drivers, because they explicitly requires that the kernel is GPL, even though the network drivers are separate modules. These network drivers checks the kernel licensing mode at runtime and issues a license violation warning if the kernel license is not compatible to the driver licensing requirements.
The kernel license mode can be set by setting compile time defines (-D GPL or -D BSD). If the kernel is compiled with GPL license the /proc/copyright changes the copyright notice to the standard GPL copyright (i.e. copyleft) notice.
It is my hope that this dual licensing mode will give maximum flexibility in using the code while still complying with the license conditions for the original source code.