Inferno OS (hosted)

G

gpatrick

Inferno OS was the commercial venture of Plan 9. It wasn't commercially successful but lives on with an open license and current code base changes.

There are some errors when using the current code https://bitbucket.org/inferno-os/inferno-os/ but not when using the tar file inferno-20150328.tgz from the Inferno website http://www.vitanuova.com/inferno/

To build the software extract the file to your preferred location. I use /usr/local which creates an inferno directory. I haven't been successful building on FreeBSD 10.x because of the use of Clang, although it builds successfully on FreeBSD 9.3 i386. I haven't tried to compile on x86_64, but with a few changes it may work.

cd /usr/local/inferno and edit mkconfig so ROOT=/usr/local/inferno and SYSHOST=FreeBSD and save the changes. Next edit makemk.shand change ROOT=/usr/local/inferno and save the changes. Then cd lib9 and cp setfcr-Linux-386.S setfcr-FreeBSD-386.S and edit setfcr-FreeBSD-386.S and change setfcr-Linux-386.S to setfcr-FreeBSD-386.S and save your changes.

Go back one directory and run ./makemk.sh and when that completes successfully set your PATH to include /usr/local/inferno/FreeBSD/386/bin and run mk install. set path = (/usr/local/inferno/FreeBSD/386/bin $path)

You now have built Inferno OS. Make sure your PATH is set to what it was before and you can run the emulator by issuing emu which will give you a prompt of ";" and if you want to run the GUI then type wm/wm .
 
Last edited:
Today I was able to build Inferno from the current updates for Inferno from https://bitbucket.org/inferno-os/inferno-os/
hg clone https://bitbucket.org/inferno-os/inferno-os

Or extract the original tar file and
hg pull -uv

Then copy the makemk.sh and mkconfig files from the original tar file, and also copy the original libmath/FPcontrol-FreeBSD.c file from the original tar file. Then proceed with the steps given above. This will build Inferno OS with the most up-to-date changes.

The change to make in libmath/FPcontrol-FreeBSD.c is to add a line #include "fpuctl.h" if you retrieve it using mercurial.
 
Last edited:
Cheers for this. Plan 9 is awesome. I actually use it as my "exotic" platform of choice to test my PhD project (Platform agnostic 3D engine). I think the C dialect on this platform is really cool in a quirky kinda way ;)

I might have to try your guide out though. Currently I actually run the original Plan 9 OS in a full VM (via VirtualBox) and serializing out the OpenGL commands but unfortunately it is getting harder and harder to run this OS on any hardware, virtualized or not :/.
 
kpedersen Your project sounds interesting, are there any pointers you might share about this?
Unfortunately, I have to agree to your part of the posting about finding it increasingly hard to run Plan9. I tried this some weeks ago, but could not get to a running installation - something did not work out in the end. Maybe it was a layer 8 problem, but a stock install should resemble what's printed on the box, so to speak, Should it not? I'm a bit sorry about this as it shrinks the number of alternatives further down.
 
Crivens said:
kpedersen Your project sounds interesting, are there any pointers you might share about this?
Click to expand...

In the name of portability and digital preservation, this project (and my PhD) goes under the assumption that a very portable software virtual machine like QEMU is fast enough to run games and simulations including collision, sound, input, etc. The main thing it cannot do is graphics. So this project is to test this theory by re-implementing (a subset) of OpenGL that forwards out commands from the VM (potentially running on Android or some other lame mobile OS) to WebGL in a web browser and have it run fast enough to be interactive. Modern retained mode (i.e not immediate mode) OpenGL has an architecture that can potentially work very well in a networked environment.

As it stands, I have Half-Life 1 running on Android by replacing the opengl.dll on Windows (in a BOCHS based VM) with my special modified one. Pretty cool. To the opposite of this, I am managing to create an implementation of OpenGL on Plan9 which simply renders on an external machine. So I can develop in the Plan 9 environment but the game can be accessible from any modern web browser.

Since my research is sponsored by a local game development company, their interests is in potential uses in multi-player. Basically the same game can be run but render to multiple connected clients whilst still sharing the same game world. Perfect for implicit multiplayer synchronization.

Ugh, now I am blabbing haha! I can talk forever on this stuff.

Long story short. Think of all the awesome software that the following archive preserves: https://archive.org/details/softwarelibrary_msdos_games. But instead for Windows 95 - XP era software. Virtualization like VMWare or VirtualBox is not really interested in preserving old software. Even running Windows 95 - 2000 is pretty tricky so hopefully the outcome of my PhD will be useful for people :).
 
This is one of the most interesting things I've read lately :D. I also find it interesting that this is really in the vein of Plan 9 thought. It fits like a glove on their idea of tightly-integrated services on networked and utterly heterogenous machines. It's a shame it didn't catch on, but now that we're done singing dirges to Moore's laws, I think we'll see more value to it in the coming decades than even Rob Pike would have dreamed.
 
I had some time today to try out the Inferno emulator and thought it was pretty cool. I did run into a few issues though.

On Windows 7, the 8c compiler ran but 8l linker would crash with a memory access error.
On Windows Server 2012 R2, the 8c and 8l programs worked but the emu program would crash.

Either way, its a bit of a shame that the compilers don't work in the emulator environment. Everything else seems to work and Limbo is cool but ideally I want to stick to C.

gpatrick, does the 8c and 8l programs work on FreeBSD? Can you run the output binaries from the emulator successfully?
 
On Windows, there are the binaries in inferno/Nt/386/bin but they are built as Windows executables and as such cannot run in the emulator environment. I assume this is the same for you (but FreeBSD binaries instead).

Yes, when run this way, you need to tell the 8c compiler where the system includes are. First lets try something simpler.

Code: 
void
main(void)
{

}

You might actually need an '_main' instead: i.e.

Code: 
void
_main(void)
{

}

then the usual:

Code: 
8c main.c
8l main.8

I honestly have no idea what this will create at this point. Will it be a binary that can run in the emulator or will it be a binary that can run on FreeBSD directly? Either way, if it can be run, the next step is the weird and wonderful <u.h> ;). If it works up to this point, I will give it a shot on my FreeBSD thinkpad.
 
Heh, yeah the same seems to be the case for me under Windows. I cannot seem to figure out how to run the output executable. But yeah, limbo works great.

Perhaps the output binary from 8l will run inside an actual Inferno OS (i.e in VirtualBox). Shame, the emulator seems to be more portable than full blown virtualization. Oh well, this is still cool for limbo development. Using limbo for GUI tools is quite nice too :)
 
Maybe this is a stupid question, but do file permissions (u+x) or absolute path names (./) change anything?
 
You must log in or register to reply here.
Back
Top