COS Operating System

  1. Omega Contact Info
  2. MacWEEK articles
    1. Omega touts its OS
    2. air of mystery
    3. delivery postponed
  3. c't article (German)
  4. Test Delayed (c't, English, Oct. 6)
  5. COS description
  6. COS FAQ
  7. COS update (new URL, Nov. 12)
  8. Omega Letter
  9. Developer Claims
  10. One Assessment
  11. About Reverse Engineering
  12. Finder Replacement?
  13. AmigaOS
  14. Kernels
  15. Interview with Omega CEO

Contact Info

Omega GmbH
Brückenstraße 4
09366 Stollberg
Germany
Tel: +49 03 72 96 / 38 65
Fax: +49 03 72 96 / 38 68
http://www.agemo.de
cos@agemo.de

Developer Claims

MacInTouch reader in Germany
Sep. 29, 1997

"The rumors about a Mac OS8 compatible OS by a german company are true. I talked to one of the developers of the so called COS. It will have a different look and feel but it is compatible to system 8. All important productivity software (e.g. the Adobe stuff) runs on the system which needs 10 to 15MB disc space(!) and only 4MB RAM(!!). The system occupies about 500K of the RAM! It has memory protection, full multitasking, client/server server capabilities (clustering is possible!) and all the networking you can think of. It is about 5 times faster than system 8 (no wonder it's small...). The system will be presented on the mac fair in Frankfurt in November [...]. Last Beta testing is taking place right now. In the beginning there will be two localisations: US English and Japanese. Distribution will be via FTP from the website http://www.omega.de. It will cost about $100. More information about the new OS will be published on the website in a couple of days."

Omega Letter

Omega Response to People who Inquired about COS
Oct. 3, 1997

Hearty greetings to all Internet Users across the Globe, who have responded so rapidly to various articles in the Web stating that we, here at Omega, are in the final stages of Beta testing of COS.

To those surfers who have expressed doubt about the claims made for COS, we can confirm that everything stated on our Web site is true

We regret that the product will not be available for any independent testing but we will give a regular update to all interested parties via our Web site. Delivery will commence immediately at 13. November.

Please watch our server. We will try to answer all your questions on the faq-site.

We hope, this mail does not appear to be rude to you, because it´s a standardtext, but we are not able to answer all mails personally. We are only a little team and we prefer to finish our product as soon as possible.

Thank you very much for your comprehension.

Your Omega-Team

One Assessment

Date: Tue, 30 Sep 1997
To: Ric Ford
From: pseudonym@earthling.net
Subject: The COS operating system

Hi Ric,

For what its worth here is my assessement of the COS OS as described on their page, if I am wrong I will let them throw rotten eggs at me, but I doubt it will come to that :-)

We have traded emails about mac stuff on occasions, however my personal background is operating systems architecture. In fact I have been doing that for 11 years, before that I spent 10 years doing OS engineering (basically training for the architecture roles).

Althoungh (IMHO) it is actually possible to create a high-performance OS with modern features and still allow a lot of existing Mac programs to run in it (using those features), I dont get the sense that the Omega guys have done that.

Lets take each of their main points one at a time -

B2 security. First of all to pass a B2 review requires about 9-12 months of time with the DoDCSC, and a computer vendor can *only* certify a complete system. The OS cannot be certified without a specific machine (e.g. a 9500), that certification does not qualify say a 7200, or a 3400 and definitly not a powertower or something else. Certification testing must be done for each hardware/software combination. (So for instance the old OSF claim that their microkernel was certified for B3 was completely bogus, in fact no-one ever passed certification using a mach based system to date).

Next for a B2 ceritification to be granted a large amount of fundimental redesign would have to be done to the MacOS architecture, an amount of which would directly impact exisitng API's. However in reality none of the B levels of defined security are actually relavent to personal computers at all, they were designed for multi-user systems and impose almost unusable levels of restiction for the users of those systems. The last B2 system I personally designed was for the Air Force (obviously I cannot go into details here). The contract required a B2 certification so that the system could be used in "time of need" without being penertrated, however the Major in charge of the actual installation had made it clear that the system would normally operate at C3 with some 'B' features enables, because a lot of their applications would not run in a strict B2 mode (it is too tight to be useful). Therefore I had to design to pass certification, but still be useful to them.

Anyway B2 requires all sorts of strange stuff, including output labelling (levels of clearance forcablly printed on all sheets outputed by printers); complete prevention of 'object' reuse (including stale memory, stale disk files etc); device labelling (each peripheral must be logically marked to its level of sercurity and classification); complete process and data seperation; there must exist a formally specified, formal security model (using a recognized method of formal specification documentation to describe it), which permits for at least 16 different security levels and 32 classifications to augment those levels; there must be a formal model for binding any access to any piece of data (either on peripheral or in memory) to a running process; every user of the system and every file requires madatory access controls to be applied (unlike C levels of security that permit discrestionary access controls). And lastly (and probably the most difficult) is to provide a complete 'covert channel' analysis of all possible pieces of data that may be found by an unauthorized entity. There arnt that many of us out there that know this stuff, and very very few in europe.

(in fact when I lived in france I was designing a system there that required B1, I wasnt even supposed to talk about the system because the existance of such a system was a problem, and the french government consider the 'orange book' to be classified and I was forbidden to talk about it. I helped define it, and implemented the first 2 systems that got certified !!!....)

Anyway I digress. Based on my personal experience in this area, I think the claim of B2 is totally bogus, PGP of course has nothing to do with B2.

Secondly, for a third party company to have written an operating system (or ported one for that matter) onto a variety of apple hardware without either a) hiring a lot of apple engineers [as Be did], or b) get a lot of help and cooperation directly from apple [as we did, if you remember I work for Novell these days, we ported netware to all of the PCI and nubus PPC macs that exisited at that time] is highly improbable. There are a lot of hardware and firmware bugs in each apple machine, most of which never get documented in the developer notes, but are only discovered when trying to boot a machine yourself. We had a team from apple on site for over a year to help us, and we had an exisitng OS which was well understood, not a new one with its own bugs to find. Based on my experience in this area, I find great reason for suspisition in this general claim, usless they only run on top of the existing OS (such as MachTen does), but then they would not get any wonderful speed improvements or be able to implement hardware dependant features such as premption or memory protection.

Mac clustering is quite possible but the OS needs to provide some fundimental abstractions not currently there (these could be provided by extensions) and the programs would have to be modified to use them. Even if they have done this it probably wont be too useful. However clustering is my area of expertese these days, and I have seem no literature either industry, academic or proceedings to suggest this company is engaged in this work. Clustering makes more sense for server systems (which the mac is not on of -- unfortuanatly --)

Memory and storage usage is absurd. The mach microkernel takes about 1.5 mb of ram (on paper it takes about 750K, but that does not include tables build at boottime, thats where the rest comes from), but the core services it needs (naming, file system, protocols etc) take up another 4-6 mb. This would provide a system capable of doing running programs but includes no command interface (i.e. a CLI or a GUI) all this additional stuff takes space. At IBM we spent many years trimming the mach microkernel down to a usable size to no avail, in fact we dropped it.

Performance. There are only 3 commercially 'viable' microkernels out there, variations of Mach 3, chorus and spring. Spring was never really fully developed by sun labs, but never did run very fast, it spent too much time messaging itself within due to its object oriented design. chorus is far too slow based on our benchmarking, and mach was even worse. After more than 2 years, we could not get OS/2 to run even 80% as fast with the microkernel underneath as before without it. Frankly the microkernel was an evolutionary dead-end, an elegant design but without any performance potential at all. Therefore I must conclude that the performance claims are bogus.

MacOS 8 support. The api and feature set for OS8 only became final in the summer, i find it highly unlikely that they could have even got a OS8 emulation to alpha by now, highly suspect claim. They cannot be assuming that they can run apple's OS8 on top of their OS, MacOS8 expects to be on the hardware, and will not run that way.

A computer that does not crash !, well there are some but they dont allow users to login directly, and they never allow new programs to be run. Anything that does will crash sometimes, even with memory protection turned on. I obviously dont believe this claim; if I thought the rest of the story was real then I would put this claim down to 'marketing exsuberence'.

If they have enbeded Java in the environment then clearly it will not fit into 4 mb of memory !.

Multiprocessor. Well if they *have* done the rest then this would be fairly easy.

Network. This statement they make makes me believe they are B S'ing us. However if they are well financed then they could have licensed these pieces of software.

--

I can find no financial information about the company or other things they have done, again they could be a well funded startup spending Esprit money, so it is difficult to access them from that perspective.

So I come down on the side of this being a scam, the troubling thing for me is *why*. To do this for fun to P. O. the mac users of the world -- not likely. To try and make Apple think they have something so Apple might try and buy them -- maybe but they must realize that no one would buy a company or technology without a technical due diligence, they would be exposed. Perhaps just a scheme to persude local investors to get involved, I would not want my money in those mutual funds !!.

None of these ideas make sense to me, so I am still stuck with the why question.

anyway, I hope I have given you some useful information to help evealute this "technology" with.

(and of course, if they ship th 'wonderOS' in a month and change the face of mac computing, then I will start eating humble pie -- i am just not sure where to buy it around here :-)

About Reverse Engineering

Date: Wed, 01 Oct 1997
From: Joseph McConnell <jmcconel@slip.net>
To: MacInTouch
Subject: The Omega / COS MacOS clone

Hi Ric

I also checked out the COS site last night and my take on it is that it is not a fraud but just a gross overstatement of what they may have. It does not sound like a real System 7.x clone, i.e a complete reverse engineering of the commonly used System 7.x traps (around 1150 in number), but just a set of software that patches out the Process Manager, Memory Manager, Event Manager, Device Manager, and Appletalk. If you patched out these manager it would be possible to support the functionality claimed by COS. My guess is what they have is exactly like VirtuaMac that ran on BeOS, a collection of hacks that requires an Apple MacOS ROM and a System 7.x System file to work.

Of the 20 odd MacOS clones I have seen or heard of since 1987 none were real clones. Half of them were nothing more than apps that ran illegally copied ROM images, the other half were either partial demos, or else 80% clones with massive compatibility problems.

Its not that the MacOS is inherently difficult to reverse engineer, it isn't. It's that the ease of reversing the large majority of the traps lulls the wannabe MacOS cloners into a false sense of security about the difficulty of reverse engineering completely the 50 odd traps that are vital if one wants to have 100% compatibility. Of the 1150 traps one needs to support (out of the 3600 that have been released) 600 are easy to reverse, 350 are fairly easy, 150 are difficult, and 50 are very difficult, if not impossible, to reverse unless one has a very detailed knowledge of how the MacOS works internally.

How do you deal with the machine specific B*Tree nodes in HFS? How do you deal with compressed regions inside PICTs without infringing the region patent? What exactly are the above A5 Quickdraw globals, and were any of the fields obsoleted by the MacII ColorQuickDraw? Do you have a complete list of the low memory globals, and I mean complete, and do you know what they do?

There are several dozen questions like the above that have to be answered correctly before one can have any real chance of producing a 100% compatible clone MacOS. Otherwise one just has something like Ardi?s Executor, an interesting hack but which is actually quite useless because of its compatibility problems. And I strongly suspect that COS is probably less complete even than Executor.

- Joseph McConnell

Finder Replacement

From: "Trey Harrell" <trey@huskjennings.clrs.com>
Subject: COS
Date: Fri, 3 Oct 97

My personal take on the COS is that it is a Finder replacement and nothing more.

A percentage of the performance gains they are speaking of can be made by simply taking another application, changing the name to "Finder" and the type and creator codes to "FNDR/MACS".

This allows the system to boot directly into that program bypassing the Finder, and giving back a decent amount of RAM while loading all Inits.

As an aside, this is a particularly effective way to double the performance of VirtualPC.

As a programmer, having a true MacOS system suitcase load at boot is the only way I can imagine true OS8 compatibility.

My belief is that COS is the 1997 equivalent of the "Mini-finder" we used to use on floppies on our Pluses and SE's. Just a new interface (one that could be written in just about any program) on top of the Mac System. It's conceivable that they could patch the open/save routines to add some type of security, but almost definitely in software only--not driver-level.

I don't believe that this would violate any Apple copyrights. Saying it's MacOS 8 compatible can also mean that it's MacOS 7 or 8 required minus the Finder, that way they wouldn't have to distribute the System files.

Bottom line: is it possible to achieve the claimed performance gains?

Yes...to a degree. VirtualPC without the Finder generally doubles the speed of Diablo on my PowerCenter 150. Six times? I dunno...

The product may very well be quite useful for high-performance apps that you need to squeak every bit out of (3D Rendering/VirtualPC etc.), although I think a $100 tag is a bit steep.

You can write a hack that gives you a program "open" box instead of launching the finder in about 10 minutes, including the resedit work.

In any case, I'd be interested in seeing their work and interface design.

Let's hope the English in the OS is better. ;)

Cheers,

Trey Harrell

AmigaOS

Date: Wed, 01 Oct 1997
From: James Greenidge <JimWG@Techie.com>
Organization: Small Wonder Tektykes & Gynoids
Subject: A forgotten advanced OS

Greetings:

The article on COS was excellent and well-rounded, however the author's incredulousness of the size of COS seems to totally forget one operating system whose various incarnations took up only 325k of RAM, only .7 megs on disk, had fully preemptive multitasking with crash isolation of each task, and dual GUI/CLI interfaces and had more than respectable performance on mere 68000s. I'm speaking of AmigaOS, which everyone in the Mac universe seems to love to overlook mentioning.

James Greenidge
www.SmallWonder.Simplenet.com

Kernels

Date: Wed, 1 Oct 1997 13:59:28 -0400
From: faisal@visionfoundry.com (Faisal Jawdat)

A couple of notes on the "One Assessment of COS Claims" article:

First, to back up what was said about B2 security, an example of the sort of difficulty involved in doing this is that NT is not even C2 certified if the network is turned on (it's certified for specific configurations if the network is *off*), and it was built from the ground up to have multi-user security in mind. [...]

Memory and storage usage is absurd. The mach microkernel takes about 1.5 mb of ram (on paper it takes about 750K, but that does not include tables build at boottime, thats where the rest comes from), but the core services it needs (naming, file system, protocols etc) take up another 4-6 mb. This would provide a system capable of doing running programs but includes no command interface (i.e. a CLI or a GUI) all this additional stuff takes space. At IBM we spent many years trimming the mach microkernel down to a usable size to no avail, in fact we dropped it.

At CMU we had 386's running full production Mach systems with 8 megs of RAM and no serious difficulties. A lot depends on what you're doing with the system though. Also RISC binaries are a lot bigger than CISC binaries. MkLinux for PPC runs on the Mach kernel and does fine on a 16 meg system.

This is not to disagree with his general point - their usage claims (500k?) are absurd.

There are only 3 commercially 'viable' microkernels out there, variations of Mach 3, chorus and spring.

There's QNX, which is fast, small, and lightweight. However it's also x86 specific assembly and way too expensive for end user use.

Frankly the microkernel was an evolutionary dead-end, an elegant design but without any performance potential at all.

Wow, those IBM guys really are bitter... :-)

Regarding the memory claims v. the issue of protected memory and pre-emptive multitasking. One of the reasons Apple hasn't been able to just outright implemented protected memory and pre-emptive multitasking like MS did with win32 is that the Mac OS still relies on a lot of non-reentrant code and on things like system global variables which are expected to be changed by applications but set correctly before a waitNextEvent(). In order to handle protected memory and pre-emptive multitasking and still maintain compatibility all accesses to these functions and variables need to be trapped, handled, passed through to the new API's, then passed back looking like the original API's.

Doing that means that you essentially have to duplicate large parts of the OS and toolbox *once per running application*. (ie several megs of runtime overhead per application). Also these issues are all over the OS (QuickDraw, for instance, is a big one, which is one of the reasons apps in the Rhapsody blue box have to run within a blue box window or full screen - the tricks necessary to get Mac OS apps to run fully side-by-side on the same drawing "layer" as Rhapsody apps are pretty hairy. (that's a non technical description).

Another place where this becomes a problem is inter-application communication. How do you get applications to talk to each other if you have just set up an OS to isolate them from each other? AppleEvents would essentially have to be rewritten from scratch, to work around protected memory (certainly possible, and one of the less complicated tasks, but it's a lot of work). Even then you wouldn't be guaranteed success.

-faisal

MacGadget Interview Summary

MacGadget Interview (German) with Manfred Schmitz, CEO and Chairman of Omega in Stollberg, Germany.

Translated Summary:

Date: Wed, 01 Oct 1997
From: Stefan Wunner <swunner@ba.blitz.net>
Subject: MacGadget has new information about the Mac-compatible OS by Omega

MacGadget, the German MacOS Newspage at http://www.macgadget.de, had a very interesting interview with the CEO of German based Omega:

If you have any questions about this information, please feel free and contact me at macgadget@ba.blitz.net

With the best regards,

Stefan Wunner
Freier Journalist und Internet Publisher

Copyright 1997 by Ric Ford. All rights reserved.