My BoxOn PC

[b.zaar]

For those interested in an OS Box on another OS here is BoxOn.

It can be used in 2 ways. The first will be as an almost complete x86 emulator that a custom OS runs in and hosts applications. Your OS will run with a simple protected mode BIOS type firmware to access hardware. A simple interface will be provided to allow RPC calls so your OS can act as an RPC server to create and control windows* on the under lying OS.

The second method is to write your kernel as a library to be included by the emulator and any applications being hosted would run like a native app inside it's own environment. Your library OS then has direct control and access to the under lying OS and can create and control windows natively. The code is based on DOSBox so your library OS would act like DOS does currently in DOSBox

I'd appreciate any help with this project. The current dev version (not yet in the repository) has the firmware initializer, and a simple multiboot loader. There is currently no firmware to load only a dummy service call to log to the console from inside of the BoxOn environment.

* Windows refers to the windows manager on the under lying OS, not the Windows OS.

[embryo]

For those interested in an OS Box on another OS here is BoxOn.

Interesting work!

But what platform is the target for your OS? Or is it incorrect to call it an OS? May be the emulator will be better? It's not clean from your description, can you provide more information?

[b.zaar]

Interesting work!

Thanks, I had the idea of something similar when I first found andLinux and then forgot about it until I found this thread. DOSBox is basically a simple OS on an OS already and it's pretty handy as you can reach outside of BoxOn in a way that bochs or qemu cant.

But what platform is the target for your OS? Or is it incorrect to call it an OS? May be the emulator will be better? It's not clean from your description, can you provide more information?

The source should compile to any current OS like linux, windows, mac etc. It's definately not an OS, it's an emulator with added extras. The idea is to use it to run your own OS in a basic PC environment but also have access to outside libraries and resources provided by another OS. You can then run programs that are written for your OS as if they are running natively.

A simple use for it would be to boot BoxOn, load your OS, load your app and then read and write files without a working FDD/HDD/USB driver for your kernel. You could access the internet by asking BoxOn to open a http location and you read it like a local file.

BoxOn can create a native window outside of BoxOn and you can control the size, the title, read the mouse position or buttons like it's a window on your OS.

The way DOSBox exposes DOS to the emulated apps is through a system call that runs code outside of the emulator. Using this you could provide any function a normal emulator or PC couldn't offer. It's still very much just ideas floating around in my head so this still might not have cleared it up all that much. Over the next few days I'll add the boot loader and then it will be easier to get an idea of how to use it and what it can be used for.

I already have an idea for how to provide the interface between your OS and the outside OS but I'm open to suggestions about this part.

[SpyderTL]

Actually, most virtual machines have some sort of "extensions" that allow you to access some of the host's resources. For example, check out the page on virtIO devices.

Still, I'd like to check out your emulator when I get a few minutes.

Thanks.

[embryo]

It's definately not an OS, it's an emulator with added extras. The idea is to use it to run your own OS in a basic PC environment but also have access to outside libraries and resources provided by another OS. You can then run programs that are written for your OS as if they are running natively.

Does it mean that you have implemented emulation of a processor (x86?), IO space, devices and so on? Or the idea is to call some API provided by your system?

A simple use for it would be to boot BoxOn, load your OS, load your app and then read and write files without a working FDD/HDD/USB driver for your kernel.

It seems like I need to call your API. But I still have my OS compiled to the x86 machine code, then it is important to understand to what extent the x86 command set is implemented in your system. And where is the border between API and emulation? What I need to work with HDD, for example? Can I use IO ports or I should call your API?

I already have an idea for how to provide the interface between your OS and the outside OS but I'm open to suggestions about this part.

I suppose something like another device which I can write driver for. Then my code can communicate with the host system using a standard device driver. Also there should be some means to tell the emulator from hardware. But it will work only in case of a complete emulation with all processor instructions and many devices supported.

I still do not see if your system fits the "complete" case or is it something simpler with mandatory API usage just to be able being hosted under your OS/emulator.

[b.zaar]

Does it mean that you have implemented emulation of a processor (x86?), IO space, devices and so on?

DOSBox already emulates a 32 bit CPU with some simple I/O for devices like the video, sound, serial and network. The IDE/ATA interface doesn't exist, all read and write operations need to go through a BIOS service call. This may apply to other devices that I haven't looked into yet. I have not added or removed any of this functionally with BoxOn. Have a look at this to see it's capabilities.

It seems like I need to call your API. ... And where is the border between API and emulation? What I need to work with HDD, for example? Can I use IO ports or I should call your API?

This is the part where the API sits, there is no access to files without BIOS calls and this includes when you mount an image file. I plan to create a simple firmware where you can use system functions after the boot process. This could be something like BIOS32, DPMI or something totally new. The API does not need to support anything more than disk access but it would not be difficult to add support for other hardware if it's a clean usable interface.

I suppose something like another device which I can write driver for. Then my code can communicate with the host system using a standard device driver.

The way BoxOn (and DOSBox) supports the BIOS services is different to a regular emulator. With Bochs the machine boots and then a BIOS is loaded and runs inside the emulator memory but with BoxOn the BIOS is outside of the emulators memory. The services are handled by a custom opcode call to the service area and then the function is performed by a BoxOn library not emulated BIOS x86 code.

The interface I'm designing is more about how to pass parameters to a service. This is currently where I'm heading along with using the custom opcode call that BoxOn already supports.

Code: Select all

mov	eax, 0x00000003		; Service number - Read device
mov	ebx, 0x00001380		; Device ID - first hard drive
mov	ecx, diskControl	; Pointer to a control structure similar to BIOS extended read
mov	edx, memPtr		; Memory pointer to read data buffer
CALL	0x0010			; The call to the firmware. The actual opcode is 0xfe 0x38 0x10 0x00 

This part at the very minimum will be required in some form to access the filesystem or disk image. If it works well it could be expanded to support video or sound without using regular hardware I/O.

Code: Select all

mov	eax, 0x00000000		; Service number - Set/Reset device
mov	ebx, 0x00001000		; Device ID - video card
mov	ecx, 0x00000008		; Mode flags - 8 bit color
mov	edx, 0x03200258		; 800 x 600 resolution
CALL	0x0010			; The call to the firmware

Or you could have done the same thing by searching for the VBE info block and setting the mode with a vm86 BIOS call.

Also there should be some means to tell the emulator from hardware. But it will work only in case of a complete emulation with all processor instructions and many devices supported.

This could be done by searching for an info block somewhere in low memory. Search for something like an 8 byte firmware name ('BIOS32BX') and a checksum and inside the info block will be the configuration to use. If the info block is missing it's not running on the the BoxOn/firmware combination.

I still do not see if your system fits the "complete" case or is it something simpler with mandatory API usage just to be able being hosted under your OS/emulator.

BoxOn is not a full emulator, it will not be used to test your OS it will be used to integrate your OS with the host OS.

[b.zaar]

I've added the Simple Multiboot boot loader to BoxOn so you should now be able to compile and test it with a multiboot kernel and 1 or 2 extra modules. Some limits are the multiboot header in the kernel must have valid load_addr, entry_addr etc values because there is no ELF support yet. You will also be running in text mode as the video support hasn't been added yet so don't request it in the multiboot header.

If you try to make a kernel work with this think of it like your kernel is running on a 486 machine without any disk drives installed. You can write to the screen using the memory at 0xb8000 but you wont be able to do much else yet. The keyboard should work too using the standard 0x60 ports. BIOS is available if you want to play with some vm86 code.

To compile the source you'll need to do the following:

1: run ./autogen.sh
2. cd to build
3. run ../configure
4. make

the executable will be build/src/boxon

The first time you run BoxOn it will create a boxon-0.80.conf file in your user config directory, like this on Windows.

c:\Users\username\AppData\Local\BoxOn\boxon-0.80.conf

It's a standard .ini file so edit the bootrc entry under [firmware] to any file you want. The sysrc entry is not used yet.

To run a kernel you will need to create a boot.rc file that is just a list of files to load.

Code: Select all

/osdev/mb-kernel/kernel.bin
/osdev/mb-kernel/initrd

Now to load your kernel at the Z:\ prompt type

Code: Select all

boot --sys

and it will load any files (limited to 5) in your boot.rc script.

The next step will be to add a console printing service call to the firmware. This will send '\0' terminated strings to the status window so you can see the kernel controlling something outside of the box.

It's still pretty much DOSBox but let me know if you can get it to work...

[embryo]

BoxOn is not a full emulator, it will not be used to test your OS it will be used to integrate your OS with the host OS.

I see it fits the need for legacy OSs to be run on modern OSs. And it may be used by osdevers as a sand box to implement and debug some new functionality in short time without writing complex drivers.

If you try to make a kernel work with this think of it like your kernel is running on a 486 machine

It's a serious restriction. My OS uses MMX registers, I suppose many other OSs also use more than 486 supports.

Any way - your attempt is interesting and may be some time osdevers will benefit from using it

[Combuster]

It's a serious restriction. My OS uses MMX registers

There is a large list of core feature updates from 386 to 486, which makes supporting the former a pain. From 486 to the pentium there's only one such candidate that makes further compatibility downwards a pain: cmpxchg8b (unless you count the guaranteed FPU as two).

Particularly, MMX was designed to work with the existing FPU saving and restoring functionality so the kernel has no need to know them, and getting it to work on a 486 should be equivalent to a compiler flag change.

[b.zaar]

it may be used by osdevers as a sand box to implement and debug some new functionality in short time without writing complex drivers.

This is one of the main goals.

If you try to make a kernel work with this think of it like your kernel is running on a 486 machine

It's a serious restriction. My OS uses MMX registers, I suppose many other OSs also use more than 486 supports.

I was erring on the side of caution, just letting people know it is a 32 bit emulator only. The offical DOSBox doc says

At present, DOSBox running on a high-end machine will roughly be the equivalent of a Pentium I PC

And that was last updated about 3 years ago. I haven't checked what instructions it does and doesn't support.

[embryo]

Particularly, MMX was designed to work with the existing FPU saving and restoring functionality

It allows to use 64 bit integers or packed types when there is no need for FPU.

so the kernel has no need to know them, and getting it to work on a 486 should be equivalent to a compiler flag change.

The compiler flag support should be implemented first. If it is implemented in GCC it doesn't mean it is implemented in other compilers.

[Combuster]

Particularly, MMX was designed to work with the existing FPU saving and restoring functionality

It allows to use 64 bit integers or packed types when there is no need for FPU.

In other words, you either did not read or you're posting an irrelevant argument for the sake of it.

so the kernel has no need to know them, and getting it to work on a 486 should be equivalent to a compiler flag change.

The compiler flag support should be implemented first. If it is implemented in GCC it doesn't mean it is implemented in other compilers.

You are implying here that there exist compilers with MMX support and no option to disable it, while In fact, all of the 486s, 586s, and even 686s started without MMX support and such a compiler would have been too specific to a particular CPU to be able to gain any decent acceptance.

In other words, show me the broken compiler in question, otherwise I'd appreciate it if you kept your imaginary problems for yourself. Hint: it's not gcc, icc, msvc, llvm, turbo c or pcc.

[embryo]

Particularly, MMX was designed to work with the existing FPU saving and restoring functionality

It allows to use 64 bit integers or packed types when there is no need for FPU.

In other words, you either did not read or you're posting an irrelevant argument for the sake of it.

Your message was about needless MMX registers and as one of the arguments about needlessness you have posted the words about saving and restoring functionality. My response was about usefulness of the MMX. Is it really irrelevant?

You are implying here that there exist compilers with MMX support and no option to disable it, while In fact, all of the 486s, 586s, and even 686s started without MMX support and such a compiler would have been too specific to a particular CPU to be able to gain any decent acceptance.

Anyway, it is still possible to find a compiler without the option.

In other words, show me the broken compiler in question, otherwise I'd appreciate it if you kept your imaginary problems for yourself. Hint: it's not gcc, icc, msvc, llvm, turbo c or pcc.

The imaginary problems are very helpful in implementing support of 64-bit integers in Java. And while it is not C (or gains decent acceptance among C-programmers) it still very useful thing. And my OS uses MMX. And I suppose that many OSs use MMX or even more of the late x86 functionality. And if you think they all are compiled using gcc, icc, msvc, llvm, turbo c or pcc, then you are wrong.

[Combuster]

The imaginary problems are very helpful in implementing support of 64-bit integers in Java.

You're apparently trying every fallacy in the book to get your right, aren't you? Go find your 64-bit add and subtract. MMX doesn't do it..

[embryo]

You're apparently trying every fallacy in the book to get your right, aren't you?

Not much different than others.

Go find your 64-bit add and subtract. MMX doesn't do it..

You can read about PADDQ.