OSDev.org

Hello to you all, fellow OSDev-ing enthusiasts. I'm 17, and I've always been steered on by the image that I got of programming from my big cousin, a huge programmer. He visited us when I was small (about 7 years old). Ever since, I've been studying programming whenever, and wherever I possible can, and at 17, I can competently program in Pascal, C, C++, and HTML+JS+PHP. Not much.

But It's enough for me to want to move my skills on further. Being still a novice, who has only learned theory, and mostly written complex experimental programs, but never a whole software system, I decided to get into OSDev.

On to the topic: I've thought up an OS, which I will name Z-OS. What's so different about Z-OS?

I believe that Networking, as it is statically defined today, has become a non-flexible thing.

• Everyone uses the TCP/IP Suite.

That is extremely limiting. I mean: who says we can't just take up our tools, and make our own cables, and just BOOM, create a network from scratch? There's nothing stopping us.

Who says we MUST use TCP-IP for private networks? Ad-Hoc WiFi, and home, auxiliary networks can be simplified a lot more than they already are.

Why use a general-purpose Suite of Protocols, when you can create a mini protocol for immediate, custom use?

This is the most fundamental change in Z-OS. I will implement a NON-suite oriented network interface for Network Connections.

How? Simple. Instead of implementing the TCP-IP suite as a part of the driver for an NIC, I'll have it as a module. Then, there will be a wizard that can create pseudo-drivers (interpreted scripts in a Network-specific language I've planned out on paper), and load them for the Packet, and Transmission phase of the Networking. The Driver for the Networking will ONLY perform basic Open, Read, Write, and Close functions, and will as purely generic as your average *nix driver.

So: You connect a cable to your pc, and connect it to another pc. No problem. The system brings up a simple GUI prompt asking whether the new network should use the TCP-IP suite, or whether you'd like to create a pseudo-protocol for it. The wizard will guide you through the generic set of options (should the cable recieve Analogue, or digital signals? Should the device send? Or is it only to recieve? What kind of naming convention do you want?), And with that, you should have a working suite of your own, which, when ported to the other PC, will work perfectly.

A specialized, custom driver is less likely to drop connections, and, due to its completely purpose specific functions, it would be very easy to troubleshoot. Networking in a small environment made EXTREMELY simple. Any kind of network that doesn;t interface with the WWW can use it.

Then there's the other MAJOR networking catch:

The ability to utilize multiple networking streams simultaneously.

i.e.: You know how in Windows, Linux, and other OSs, you find that having the PC connected with one of its NIC, makes it unable to handle connections on any other, unless you're using another NIC to share the connection coming in on NIC #1?

Well, In my OS, any number of NIC can be connected at once. Applications don't connect to the hardware (obviously not), but rather to Hardware Resource Streams. A Hardware stream is a sort of...plug for an App to dip its tendrils into. Each NIC will have its own stream. You can have any number of concurrent network connections, even internet connections coming into the same PC, and applications wishing to connect will ust choose the Default device, OR you can specify a particular NIC connection for a particular group of Apps to use.

Total control of all networking on the PC.

There's lots more I've come up with, all due to that Hardware Resouce Stream idea I've come up with, where the OS doesn't provide an abstrction to an App, but provides a managed sort of ... lifeline to the resource requested.

I've ogt a great idea, that will take years to finish. LOL.

I just want some comments, and whatnot, and see if this is really that revolutionary.

Well, that is what the TCP part of TCP/IP *does*. Networks are horrendously unreliable - you can't just write to them and expect everything to come out in the same order, intact, or even at all. What TCP does is give you the illusion of a character stream, by various methods, which are inherently complex. I think what you are most angry at is the BSD sockets API. It would be entirely possible to make sockets look exactly like pipes, but you would have to have some sort of extra coordination on both sides to direct it to the right place. It also would be hard to do any sort of firewalling or routing if there was no port system - it would be possible, but you would have to make your own routers or somehow abstract things over the ports concept (which would be much easier). Take a look at Plan 9 - I believe they have made the network act like a file, like they do with every other resource.

Just remember: networking is like a transcontinental cannon-based freight service. You can never think of it as predictable.

About that thing you were saying with the impossibility of firewall installation:

Due to the way I intend to implement the entire Operating System, that won't be a problem:

Z-OS is like this: There are ONLY three levels of existence for any resource in Z-OS:

[Application Level.]
[OS Level]
[Hardware Level]

The OS does not actually interfere with the applications as they access hardware. All it does is something like this: App#1 wants to access the HDD. It sends a request to the OS. The OS grants it a Hardware Resource Stream (think of these are air supplies, lol), and passes this stream directly from the HARDWARE to the APPLICATION, with the OS sitting passively by the side. there is very little abstraction. The Kernel will implement drivers as generically as possible.

In order for the OS to catch App exceptions, all it does is dip a finger into each stream allocated to each app, and scans the bits being transferred for things like Division by Zero, etc.

In other words, apps are granted an environment in which they sit as if there was NO OPERATING SYSTEM underlying. They gain unstunted access to hardware without any speed reductions.

Where does the Firewall thing come into this? Well when installing an app, if the application runs code that suggests that it needs Monitor Level (OS Level) privelidges so as to read other programs' data and resource streams, the user is prompted on whether or not they are installing a program that would need to monitor their system, for example, a firewall, or AntiVirus program. If so, the program is granted OS Level Monitoring privelidges.

Honestly, no program should ever monitor other programs' resouce streams and what they are doign with their resources, so the user should be easily able to tell if a program is doing nonsense. This is also useful in detecting malicious code.

Most of the really dangerous malicious programs need some level of high privelidge to operate properly. If the OS prompts any half literate user on whether to allow "ll32.dll" to monitor other programs' memory space, and read fro the keyboard, I believe he'd double check his installed programs list before clicking yes, LOL.

There's a lot of other stuff I've sketched out that stems form this concept of allowing the OS to sit back and just allocate generic hardware streams to apps.

Another benefit is the ability for the OS to EASILY just snip any Stream Supply line that has an app running suspicious code, via its monitoring backseat.

There's tons of stuff I can post on it, but it's kind of long, so...LOL

The problem with the micro-protocol idea you have outlined is interoperability. The way you have set up, you have to reinstall network comm software if ever you move a computer between networks; with a standard setup, you can pretty much plug-and-play. How would, for instance, a laptop running Z-OS connect to a public wi-fi AP, if its network comm software is all set up for some custom micro-protocol?

Theoretically, what your saying might be true, however, the thing with TCP/IP is that everyone uses it. If you create your own standard, and it works great, what will the use be? You cant have a network with one machine. If you want to do it for experimental purposes, go for it, but you will also learn a lot by just being able to have your OS implement TCP/IP and communicate over existing networks.

[yemista wrote]
Theoretically, what your saying might be true, however, the thing with TCP/IP is that everyone uses it. If you create your own standard, and it works great, what will the use be? You cant have a network with one machine. If you want to do it for experimental purposes, go for it, but you will also learn a lot by just being able to have your OS implement TCP/IP and communicate over existing networks.
[/yemista wrote]

I think the same way.
If you are gonna experence the program skill, maybe yemista is right.
Even though you wanna make a spec, you must have experience a lot.

Moved to design & theory

holypanl wrote:I just want some comments

You are 17. Just wait a few years, and things will calm down. Then, you'll look back at this as a funny episode.


JAL

I believe that, from what you've shown so far, that this might be possible for you do do if you devoted a LOT of your time into it, designing (which would be the most important aspect of it) and then implementing. However, you would need to research and design a lot, which would take time. If you are serious about pursuing this idea, work out a first design, run it past us, or some people you know who might be able to help, tweak it, and repeat. After your design looks solid to at least you and 1-2 other people, start working out how you will implement it. Once you've decided upon that, start doing it. After that, you should be around...25

Actually your time frame would depend on how fast you work. But don't expect for this to happen fast.

Also note that before you get into all of the fancy networking stuff and module loading and GUI, you're going to need a base OS to do it on. So create one (even a few, so you can experiment) before you get to far into the networking stuff, so you can understand how that all works too.

Good luck,
-JL

holypanl wrote:About that thing you were saying with the impossibility of firewall installation:

Due to the way I intend to implement the entire Operating System, that won't be a problem:

Z-OS is like this: There are ONLY three levels of existence for any resource in Z-OS:

[Application Level.]
[OS Level]
[Hardware Level]

The OS does not actually interfere with the applications as they access hardware. All it does is something like this: App#1 wants to access the HDD. It sends a request to the OS. The OS grants it a Hardware Resource Stream (think of these are air supplies, lol), and passes this stream directly from the HARDWARE to the APPLICATION, with the OS sitting passively by the side. there is very little abstraction. The Kernel will implement drivers as generically as possible.

In order for the OS to catch App exceptions, all it does is dip a finger into each stream allocated to each app, and scans the bits being transferred for things like Division by Zero, etc.

In other words, apps are granted an environment in which they sit as if there was NO OPERATING SYSTEM underlying. They gain unstunted access to hardware without any speed reductions.

Where does the Firewall thing come into this? Well when installing an app, if the application runs code that suggests that it needs Monitor Level (OS Level) privelidges so as to read other programs' data and resource streams, the user is prompted on whether or not they are installing a program that would need to monitor their system, for example, a firewall, or AntiVirus program. If so, the program is granted OS Level Monitoring privelidges.

Honestly, no program should ever monitor other programs' resouce streams and what they are doign with their resources, so the user should be easily able to tell if a program is doing nonsense. This is also useful in detecting malicious code.

Most of the really dangerous malicious programs need some level of high privelidge to operate properly. If the OS prompts any half literate user on whether to allow "ll32.dll" to monitor other programs' memory space, and read fro the keyboard, I believe he'd double check his installed programs list before clicking yes, LOL.

There's a lot of other stuff I've sketched out that stems form this concept of allowing the OS to sit back and just allocate generic hardware streams to apps.

Another benefit is the ability for the OS to EASILY just snip any Stream Supply line that has an app running suspicious code, via its monitoring backseat.

There's tons of stuff I can post on it, but it's kind of long, so...LOL

There are a few misconceptions you are making.

First of all, having communication bypass the operating system has nothing at all to do with security. The kernel can never be infected by a packet with malicious information on it - the problem is the program that interprets the packet.

Giving control over the resources to the applications is not a bad idea - that's the essence of an exokernel, which it seems like you're designing. But you can't give *unmanaged* access, otherwise each resource is only usable by one program. Not to mention that you will have to implement something at least similar to TCP in order to do reasonable amounts of communication.

And having the kernel monitor all data streams for "errors" is impractical. You can handle things like division by zero using the processor's interrupt facility, and having the kernel figure out whether there is a bad output would be either impossible or impossibly complex.

Before you go designing entirely new and radical systems, try either implementing or thoroughly researching the successful designs that already exist. Don't try and change things just because you (think you) can - there are many places for improvement, but you have to know what you're doing first to see them well. Also, make sure you completely understand the limits of the hardware before creating software over it, especially on the OS level.

@NickJohnson: Thanks for your wisdom. I understand what you've said, and will take it to heart.

I suppose I DO have a lot of research to do still. ^_^;

Anyway, thanks to all of you, and soon enough, I should have a solid draft design to present for comments.

Thanks
-holypanl

When I was in the middle of designing my OS, I often had crazy design ideas like this. But this is not really a bad thing: although it may not ever end up being implemented, eventually realizing the impossibility of an overcomplicated design may lead to the creation of a really good one. I think this is part of a thing called the "third system effect". In essence, the "first system" is a design that is very simple, but lacks power. The "second system" is what occurs when the first system is added to, leading to massive unmanageable bloat and unreliability. If the second system survives long enough, it will collapse under its own weight, yielding a "third system": simple, elegant, and powerful. For example, UNIX was a third system, and it's predecessors were Multics and CTSS, in reverse order. I think Windows is a second system, although some may disagree with me. UNIX -> Mach -> L4 would also be a good example. Anyway, because I let my design ferment and evolve for a few months, it naturally began to bloat and bloat until it completely collapsed; afterward it made much more sense, because it had gone through a miniature version of this effect. You can't avoid it, and you need to learn by testing at each stage, so just let your ideas sit for a while - maybe you'll get a better design out of it.

And I would totally disagree with everyone who says you're crazy because you're 17. It doesn't have to take years for people to develop good designs, or matter what age they are - what really matters is attitude. Take what you wish from my advice - I'm only a journeyman as well (but a journeyman with a working kernel in two months btw.)

Oh! I just revisited this thread, and my oh my. Thanks a lot, berkus. That's an extremely interesting article, in fact.

-All the best in your own projects,
gravaera

Just re-registered to throw in my 2 cents from the network admin side of this.

Have you considered the actual network topology that this idea would create?
Will your network traffic be compatible (or be passed at all) by any normal switch/hub?
How do you traverse multiple networks to find a destination?
Is your system going to rely on the existing DNS systems for name resolution?
Are you going to implement something like WINS or otherwise?
Have you considered building a translator mechanism to run on the edge of your network to translate to/from tcp/ip?

This line of questions could go on forever.. but most importantly, make sure that you write something that's at least partially compatible with a switch/hub or your project will be completely pointless.

BTW - 17 and interested in this type of work is fantastic! Can't wait to see how you progress!