для тех, кто не читает по-английски
|Realité||Josephine||iDesk!||Gardemarine||Z-Cash||RoomTeem||Phantom Operating System|
Why a new OS? →
Copyright © 2009 Dmitry Zavalishin,
+7 (916) 690 3208
Digital Zone, Moscow, Russia
+7 (499) 973-23-80
Why a new OS?
The most obvious questions: why new operating system? Isn’t Linux enough? Of course, Linux is not enough. Being a clone of Unix, Linux conceptually is a dinosaur. Don’t be happy, Windows guys, Windows is not really far away. Lets see, what is wrong with today’s popular operating systems.
As object-oriented programming became the most widely used paradigm, old plain-API based OSes became pain in the butt. To be used in OO environment plain system calls need to be “wrapped” by special OO code, or else OO program will need to handle them in a special way here and there. Either way, plain API used in OO code needs special treatment. Application code is getting bloated due to that, and debugging gets harder due to the fact, that programmer has to know peculiarities of both plain OS API and OO wrapper. Good example is Windows OO wrappers such as MFC, ATL, OWL, etc. The same problem persists with C#, because “native” C# library still has to be “thunked” into the classic Windows API calls.
Network friendly? No!
Network is an alien in today’s operating systems. Application which needs to use network must do most of the work by itself! Only file access is more or less seamlessly covered by OS so that application can work with remote files like with local ones. Remote object access is still not there (we’re in the 21 century, arent we?) – I mean, modern (huh?) operating systems do not offer such a service, application programmer has to use language-scpecific mechanisms, like RMI in Java, or OS tools, but such tools still need programmers support and not portable across even most widely used OSes.
Let’s put it clear: for most cases, socket level network programming today is not a less shame, than direct video card registers access in MS-DOS programs of the 20-th century.
How many kinds of name to object translation your operating system has among its APIs? One for files. One for network objects. One for drivers. One for devices. One for USB devices. One for fonts. One for link-time program elements (functions, labels, variables). One for users. One for IPC objects. You can give me ten more - just look in your include file directory.
They’re all different! Why the hell getting object by name is not done in the same way for all of them? What ‘System’ in “Operating System” term stands for? Should we better call them Operating Garbage?
Communication friendly? No!
Today’s world is a world of cooperation. Nobody tries to do everything himself now. Everybody knows, that to be successful you have to do your part of the project well and use other’s solutions where possible. No one writes own display driver today (it was quite common ten years before, by the way), no one wants to solve what’s already solved. Frameworks, libraries, toolkits – any program uses 10 to 100 times as more of 3rd party code, than has it’s own.
Does “modern” operating system help with that?
Well. Sometimes it tries. But if you really want to do something more fancy that use a shared library or DLL, you will run for your features, and run hard. OLE is not for a faint hearted, and how widely real object embedding is used in Windows? Twenty programs on the market? Thirty? Thirty five? Sold.
Situation is even worse in Unix: NO real OLE-like machinery offered at all. I mean – really working and widely used.
Future friendly? No!
Every programmer knows what “version” is. It is an unique state of software component, as Wikipedia just told me. Thank it for a definition.
Any program, tool, framework, library can exist in a number of versions. It is usual. If you’re on Windows, look in c:\windows\system32 and count all mfc*.dll files, for example. If on Unix, you know what I mean. :)
Now what kind of support for, at least, libraries versions your operating system has? None. At all.
Used for return and exception unwind purposes. This stack’s element has all the current executing method stuff: object, integer and exception stacks, ‘this’ object pointer, return address.