OSDev.org

Hi,

Me and a friend had an idea a while back about starting an OS. We are currently outlining the basics of the system, and would like others to help us. Theres not much information available at the minute, but I'll update as soon as I can. If anyone would like to help with this, please reply to this post. Thanks.

I need a bit of info as far as the obvious basics like

is it 16 or 32 bit?
will it use paging or segmentation
multi tasking?
console, gui, or both
kernel interfacing(call gates,interrupts, other)
and other such things

32-bit, paging, multi-tasking, both (mainly GUI), kernel interfacing, networks, compayability with Linux/Windows applications. That's all the info I have so far.

Also, for anyone who wants to write a tutorial for the OS, just in case anyone who has'nt done this before wants to help, please e-mail it to [email protected]. Thanks.

OK, I have more news. We are aiming to make this a gaming OS for high end games. I have an estimated system requirement list here:

MINIMUM:
700MB RAM.
DVD-CD Drive (CD/DVD-RW/HDDVD-RW/BR-RE supported)
2.0GHz Processor
256MB Graphics
Internet Connection for MultiPlayer (56k minimum)
250GB Hard Drive

RECOMMENDED:
1.5GB RAM
DVD-RW/CD-RW/HD-RW/BR-RE Drive (For later versions these will be required, as games will proborably appear on these devices
2.5GHz Processor
2x 512MB Graphics Card
ADSL Connection to Internet for MultiPlayer (1MBps Minimum).
1TB Hard Drive

Support for Dual-Core processors, and support for Windows/Linux specific games. Also, a system like Microsoft's DirectX to offer support for multiple hardware would be a good idea, but may be too difficult to code.

More information soon.

Ben Clarke wrote: compayability with Linux/Windows applications

Ben Clarke wrote: Support for Dual-Core processors, and support for Windows/Linux specific games. Also, a system like Microsoft's DirectX to offer support for multiple hardware would be a good idea, but may be too difficult to code.

You should also make it hard-realtime, and have an AI that's able to guess your next move, at any time.

But seriously I hope you realize how *huge* an effort that will be. Reimplementing the Linux and Windows API set (and that is what you'll be doing) will take decades... and that's assuming they never change... don't forget that Microsoft has a 30 year head start...

--Jeff

Ben Clarke wrote:MINIMUM:
700MB RAM.
DVD-CD Drive (CD/DVD-RW/HDDVD-RW/BR-RE supported)
2.0GHz Processor
256MB Graphics
Internet Connection for MultiPlayer (56k minimum)
250GB Hard Drive

RECOMMENDED:
1.5GB RAM
DVD-RW/CD-RW/HD-RW/BR-RE Drive (For later versions these will be required, as games will proborably appear on these devices
2.5GHz Processor
2x 512MB Graphics Card
ADSL Connection to Internet for MultiPlayer (1MBps Minimum).
1TB Hard Drive

You are writing a multiplayer OS? You're going to write an OS that uses 1.5 GB of ram? And a TB of hard drive space? What for? This OS would be terrible for gaming. There would be no system resources available for the games. It's more bloated than Vista. The games are what need the hardware, not the OS.

Seriously though, why would you write hardware specs before any engineering, and before even writing a single line of code?

Ben Clarke wrote:... and support for Windows/Linux specific games. Also, a system like Microsoft's DirectX to offer support for multiple hardware would be a good idea, but may be too difficult to code. ...

Jeff is right, this is a task so immense that it is probably way out of your reach. The Wine Project has been working on this for 12 years, and they still haven't really produced something very useable.

250GB Hard Drive

some servers don't even have that

also 1TB harddrive setups are very rare(usually only in big servers and then most people split this between severs like 4 250gb servers


also there will be very few people using your OS because it most likely will not even get to hello world(unless of course you copy code, but then linking it and everything willl probably not even make that feasable)

rexlunae wrote:You are writing a multiplayer OS? You're going to write an OS that uses 1.5 GB of ram? And a TB of hard drive space? What for? This OS would be terrible for gaming. There would be no system resources available for the games. It's more bloated than Vista. The games are what need the hardware, not the OS.

Seriously though, why would you write hardware specs before any engineering, and before even writing a single line of code?

Ben Clarke wrote:... and support for Windows/Linux specific games. Also, a system like Microsoft's DirectX to offer support for multiple hardware would be a good idea, but may be too difficult to code. ...

Jeff is right, this is a task so immense that it is probably way out of your reach. The Wine Project has been working on this for 12 years, and they still haven't really produced something very useable.

No, the RAM and HardDisk arnt for the system. That is so that a large amount of games can be installed, and the RAM so that games can be played in high quality, with decent framerates. (I know what it's like to have bad framerates, try playing Doom 3 on 256MB RAM). The actual system, I hope, will use between 256MB and 380MB of RAM, and only 5GB HDD space.

Also, I was going to use coding for an emulation software for Windows/Linux, but I'll scrap that.

The OS won't be multiplayer, that's there for multiplayer games.

ok then those are what you recommend, not system requirements

Yeah, those are recommended, for maximum functionality. I have no idwea what the final system requirements will be, as we are nowhere near the finishing point (I only have a bootsector written at the moment), but I hope they'll be lower than that.

Also remeber, there are lots of job spaces that need filling for this. At the minute this only a two-man project.

Ben Clarke wrote:32-bit, paging, multi-tasking, both (mainly GUI), kernel interfacing

This spec is the opposite of a good game OS, take a look at the Xbox spec

While the Xbox kernel is based on the NT/Windows 2000 kernel, it's extremely lean. There's no virtual memory paging, and only a single process is allowed (though that process can spawn multiple threads). The entire kernel fits into 150KB--far less than the 1MB original goal.
The development library is polling-based rather than event driven (unlike Windows). This was due directly to feedback from game developers.
The game owns the hardware--it runs in ring 0, and has direct access to all hardware (including CPU and graphics).
Memory allocation is the responsibility of the app--there's no front-end memory allocation.
While the APIs were familiar (Direct3D, DirectSound), the back ends were different, and highly tuned to the Xbox hardware. However, the input API is different from DirectInput on the PC.

See here for more info: http://www.extremetech.com/article2/0,1 ... 116,00.asp
The Xbox spec is what Dex4u is based on, and is what a good base for games OS should be: http://www.dex4u.com/gui.htm
But i am biased .

Actually, I've been working on my own game os (codename: gos), which will differ radically from what you are proposing. gos is small (relatively), completely modular (there's the bootloader, and there's modules. the game is just a module or a set of modules). gos is meant to be booted from a CD or floppy, and it immediately initializes the game. Basically, people can just make their game, burn it onto a CD with gos, and it will run. But gos doesn't follow any current file formats, which may have to change if I want CD compatability.

I was thinking of making gos GPL'd or LGPGL'd, but it'd be hard to make source-code available with the binary, as the CD or floppy don't follow standards (to make gos more efficient). One possibility is shipping a src module that uploads every module's code onto a hard-drive. Of course, it's better just to add ISO compatibility and ship the source code in that. I'm not too worried about a licence yet.

In any case, gos is small, fast (no processes, no paging, no segmentation), uses very little RAM for itself, and gives the game ring 0 privilege. I didn't know about the xbox spec, but it seems to have similar goals (except for the modular kernel part).

I've found that modular kernels are really easy to develop, maintain and debug. You should give it a try, I reckon.

Hmm... OK, I may have a separate project for those two last recommendations, for lower spec users. Also, just so that you know, the GUI is for when a user does'nt want to play games. It's there so if someone wants to use the Internet, use chat rooms, do work, etc., they dont have to restart their computer and boot Windows.

something you may want to consider is like actually implement things like paging(to hdd) and memory management in the kernel but make it optional for use by the game, and give the game complete control over things like what pages to put on the hdd and such

Yeah, I was thinking that games install a separate module for the games use only, so that it can be used when necesary, and a main ione in the system.