In the beginning was CAOS - 500 Beiträge pro Seite

[DerStrohmann]

In the beginning was CAOS
by
Andy Finkel.
Copyright © 1988 by Andy Finkel,
Commodore-Amiga, Inc.

The very first issue of Amiga Transactor - spun off from the original Transactor - featured an article by Andy Finkel, then the Software Manager at Commodore-Amiga. Fortunately, the article survived, although Amiga Transactor didn`t. It`s interesting to contrast the state of AmigaDOS then and now, especially in comparison to the CAOS specs. Thanks to Andy - and an intrepid Amiga owner who typed in the text and sent it to Andy - ViewPort is able to reprint that article in its entirety. So set the WayBack machine for 1988, and read on...

As most of you know, AmigaDOS was not the first choice for the top-level OS/DOS on the Amiga computer. What we now call AmigaDOS was really the backup DOS, based on an already existing OS known as Tripos (developed at the University of Cambridge Computer Laboratory by the TRIPOS Research Group, and converted with amazing speed by Metacomco`s Dr. Tim King and his band of programmers). When the original, intended, designed-for-the-Amiga DOS failed to materialize (in what would no doubt be an interesting story in itself), the Amiga was launched with AmigaDOS, and the rest is history, so to speak.

Once in a while, someone suggests that the original DOS be written according to the original specs. This was even proposed by some members of the Amiga team, but Amiga management decided that it wouldn`t be possible to complete the DOS and still launch the Amiga on time, especially since the software guys had already given up weekends at home. And going home. And sleeping.

We`re left with a big question .. what would the Amiga have been like if we could have used the original DOS? What would the character of the Amiga have been? Would life have then been perfect?

There`s really no way of knowing, of course. But if I stopped here, this would be a really short article, right? So why not take a quick look at the specs, and maybe do a little comparison with AmigaDOS...

Because these questions greatly interest developers for some reason, a small mention of CAOS on USENET brought a flurry of electronic mail, all asking for more detail (all right, they wanted the specifications). So I decided to write this - it seemed like more fun than the article I was working on ("A Guide to DOSBase", or "Why is this library different from other libraries?") so I`ll save that for another time. Ideally this article should have been written by one of the Amiga people who spec`d CAOS (primarily Carl Sassenrath who also wrote Exec) way back in the dim reaches of time (1984). However, as they`ve been quiet about it all this time, and I have played with the prototype (do you know what a pain a Sage can be to set up?) it`s time. Anyway, the specs are from the CAOS draft document.

CAOS stands for the Commodore Amiga Operating System. Its purpose was (good place to quote from the draft specifications here):

"It is a small, full-bodied operating system, functioning on a small (but great) machine bound for the consumer market-place. Its primary purpose is not to provide a sophisticated software development environment - rather is provides a foundation for pleasant and useful application programs. This is not to say that it neglects the programmer`s needs. Externally it is meant for end users; internally, however, it is designed to support the complex demands of most applications. It provides extra rich functionality for an operating system of its class.

The goals of CAOS are:

functionality usability (easy to use at both outer and inner interfaces)
programability (interactive batch language, rich set of programmer functions)
extensibility (modular and extensible)
reliability performance
size (reasonably compact)
maintainability
CAOS was always meant to be built on top of Exec (in much the same way that AmigaDOS is built on top of Exec). Exec would provide the low level services. It would initialize the hardware, bring the system software up, handle interrupts and exceptions, do the low-level device control (like the trackdisk.device), provide system error-handling, supply the low-level timing routines and semaphores, provide some useful utility functions, and handle the basic multitasking.

This sounds familiar, right? Yes, it`s true. AmigaDOS depends on Exec for the same functions.

What would CAOS itself have given? How about multiprocessing, a file system, memory management, and commands? Basically, the same things that AmigaDOS gives us - not surprisingly, as AmigaDOS had to step into the shoes of CAOS. Both CAOS and AmigaDOS have their own special strengths, though. For instance, CAOS also did memory management to a greater extent than AmigaDOS, and would have had resource tracking.

There are three (well, at least three) general interesting areas to look at about CAOS: Multiprocessing, the File System and Memory Management. And then there`s also the projected commands (for fooling around with files and similar operations.)

We might as well start with the easy ones ... multiprocessing and memory management. You may wonder why multiprocessing is one of the simple ones. It`s because multiprocessing (at least in general outline) is much the same as multiprocessing under AmigaDOS.

CAOS processes are built around Exec tasks. CAOS depends heavily on the Exec data structures and control primitives for multiprocessing (sound familiar?) A CAOS Process structure is built on top of an Exec Task structure. Exec handles the context switching, inter-task communication, synchronization, queuing, and mutual exclusion. As with AmigaDOS, only Processes can talk to the file system.

The CAOS Process structure contains (along with the Task structure) information about its stack, the program data, resource tracking, and exception code. (Once again, except for the `resource tracking` area, it sounds much like the AmigaDOS process information, right?)

The resource tracking is a key difference. CAOS was intended to keep a linked list containing blocks of resources used by the process - file control blocks, I/O blocks, message ports, libraries, memory usage, shared data, overlays and so on. (This part of CAOS lagged behind the rest; which may explain why we don`t have even a semblance of it now.)

Processes run in user mode, using a single (user mode style) stack. Except for context switches, which run in supervisor mode (using the supervisor stack) and of course interrupts, everything was going to stick to user mode. OS system routines are well behaved (they don`t mess with the stack) and use well defined amounts of stack space (they don`t allocate large areas for local variables or recurse). Now, that`s a big difference. AmigaDOS makes extensive use of the stack for its operations. Oh well.

There are three ways to create a process: create it from scratch, allocating new data structures and code; clone it from the parent process, making new data structures, but sharing the parent`s code; or chain it from the parent, and replace it.

The general description of process creation is:

1) Allocate the process structure
2) Allocate the stack
3) Open standard in, out, and error
4) Load the code and make it ready to execute (relocate it)
5) Load static data
6) Translate the package file (if one exists), and create a package control block
7) Pre-load the package file
8) Initialize exception vectors
9) Add the task to Exec`s task list (with AddTask), which puts it on the queue to run

I mentioned the package files in the above list. What exactly are they? Simply this: a package file is a method used to describe the load and run time memory environment for an application by giving the user a way of binding application program and data files in an easy to manage form. This is something we lost when we went to AmigaDOS, and it`s something I think we should look at putting in.

Another important task (sorry) that CAOS was intended to perform was memory management. Looking at the current OS one may note that Exec has a rich set of primitives for dealing with memory. CAOS added some additional functionality that AmigaDOS doesn`t have (and some that it does).

CAOS basically provided well-managed regions of memory. Within this region of memory, the CAOS memory manager would reign supreme (somewhat like grabbing a portion of memory with the Exec AllocEntry call). CAOS would then manage the memory within that sub-region, allocating sections for code, data, program stack, and so on. Obviously, fragmentation could set in. Since scatter-loading was not (at the time of the spec I`m using) part of the CAOS design, the CAOS memory manager needed a way to cope with fragmentation. If a sub-region became fragmented, CAOS would attempt to perform a compaction and garbage collection of regions. First, it would delete sub-regions as volunteer overlay candidates. If this failed to regain enough memory, sub-regions with no users (libraries and devices with accessor counts of zero, for instance) would be deleted. If this failed, a special entry point would be called for relocatable and unloadable subregions. If this failed, the user would be treated to a Guru (or an out of memory requester)

When a program needed to manage memory within the CAOS-allocated subregions, the program would think of memory in terms of segments. Segments could be marked as relocatable or fixed, permanent or reusable.

The CAOS memory manager would attempt to compact relocatable segments and delete reusable segments when memory got tight. Non-relocatable segments would be kept together at either the top or bottom of a region, to avoid catastrophic failure of the relocation/compaction algorithm of the memory manager.

Segments also could undergo a crude form of swapping: they could be read in from or written out to a preallocated disk file.

Believe it or not, the AmigaDOS SegList gives almost as much functionality. Except for the relocation type of segment and the associated memory manager, you can pretty much play these same games with SegLists.

Now we get to the hard stuff - the file system. This is the area that should differ most from AmigaDOS. Providing a file system is the most important goal of a disk operating system.

CAOS used a file concept just like AmigaDOS - a file being an abstract data object, with a set of access methods, that appears to the user to be a consistent data stream regardless of its underlying storage form. Many, many computer systems have happened on this concept.

CAOS supported four types of files: ordinary files, directory files, image files, and special files.

An ordinary file is used for data storage. The data can be anything - ASCII, binary, whatever. There is no system-imposed structure on the contents of an ordinary file.

Ordinary files are typed as well, to aid CAOS and the user in understanding the files` content. An ordinary file might be typed as containing special graphic information, text, program code or program data, for instance. In the case of an ordinary file of text type, the only limit imposed is that no text line shall be longer than 512 bytes.

A directory is a file used to map file names to actual data. They are treated differently from ordinary files in that there is a system-imposed structure for their contents, and they are protected against overwriting. A directory may contain the name of another directory file, and so on - a tree file system is supported.

Image files provide a symbolic method of binding to system internal data objects. CAOS would use these files to give file system-style access to internal system objects like libraries, devices, interrupt chains, etc. This would have allowed a standard high-level method of dealing with these low-level objects. The file system would have acted as a symbolic address space.

Image files were considered an `option` - special pseudo-device files might have been used instead. I really like the concept, though. It`s one of the clever things I wish we had with the current DOS. (Fortunately, I think I`ve got a way to retro-fit this onto AmigaDOS.)

Special files are treated just like ordinary files, but don`t generally represent an interface to a storage device. They are used to provide standard access to I/O devices.

CAOS allows file names of up to 30 characters. A path can be specified using the `/` character. Both absolute (from the volume root) and relative (to the current directory) paths are supported. The reserved file name `:` refers to the current directory. The reserved file name `..` refers to the parent of the specified or current directory. A path (including file name) couldn`t be longer than 255 characters.

CAOS supports both hard and soft links. A hard link is just a pointer to the internal data structure of a file (actually, a directory under CAOS would be an array of hard links). A soft link references a file by using the file name and doing text substitution. (For example, if the file system was asked by a user program to Open a file called "library", which was actually a soft link to "/exec/lib/library", the file system should substitute the name "/exec/lib/library" before doing the Open.)

CAOS maintained useful file information, like a description field (up to 255 characters of information for reference purposes), creation time, update time, link count, permissions (read, write, execute, locked), type (directory, printable, non-printable, and so on), user ID, size, and blocks allocated to the file. Image and special files might not maintain all of the information; defaults - you know, lies - are returned when an application program interrogates the file system about one of these files.

Files may be opened for read, write, or append operations. Block and character operation may be supported. You can also seek to any particular byte in an ordinary file. Image and special files disallow this, though.

System directories, like / (the root), /dev, and /Exec are special directories where the system generally keeps its special files, image files and so on.

Let`s go right to the proposed limits on the CAOS file system (always a popular means of comparison). Maximum file size is one megabyte; maximum name size is 30 characters. Maximum path size (including name) is 255 characters (but may have been increased to 512 with enough demand). Maximum number of files would have been one quarter of the number of blocks (about 440 on a floppy); maximum number of open files would have been 16 per process, and the maximum length of softlink text substitution would have been the same length as a path.

There are three types of file operations: high level (safe, simple) file access, low-level file operations, which work directly on the file control block (the higher level functions devolve into calls on these low level routines), and support/maintenance operations (i.e. utilities). Naturally, all file functions are called through the CAOS library interface.

Descriptor-based file operations are the easiest means to access the file system. You Open a file using a name (and path), and in return get a descriptor, which you use for all subsequent file operations.

The functions are Open, Close, Read, Write, Seek, EOF (test for EOF), Size (return the size of the file in bytes), Truncate (I miss this one), Update (write out all dirty buffers to the device associated with the file), Name (return a pointer to the file name), Options, Lock (prevent simultaneous access), Unlock (unlock a previously Locked file), LastError, and Control (miscellaneous file access control).

The high-level file access methods described above are based on a lower level file control block access method. Functions using the file control block are: MapFile (go from a descriptor to a control block), OpenFile (given a name, return a file control block), CloseFile, ReadFile, WriteFile, and Update.

By the way, it was considered possible that the low-level access to files would be removed if all operations were possible using high level calls.

Essentially the programs would be quite similar to the ones we have now (except, of course, Unix-like syntax would have been used). We`d have Link, SoftLink, Remove, Rename, FileInfo, SearchDir, CurrentDir, ChangeDir, MakeDir, and so on.

As with AmigaDOS, CAOS supports volumes to logically map disks, partitions, devices, file networks, and structured memory. Volumes can be accessed when they are online. Disk and network volumes go online once their volume ID structure has been read and verified. (For floppy disks, this happens automatically when the disk is inserted.) When access to a volume is ended, the volume becomes either absent, offline, or critical (as in, You Must Replace Volume...)

CAOS maintains volume identification information, like name (up to 40 characters), description, time stamp and write protection status. By using the "special" type of file, it is possible to get direct access to a volume. In the case of a floppy, the special file would give the same type of access (but in a file-system standard manner) as if the trackdisk.device were used directly.

This then is a quick overview of CAOS. Let`s say it was available now ... What would we have gained? Personally, I think the main thing would have been a much more integrated system. From these specs you can see that AmigaDOS is really as powerful as CAOS was intended to be. The problem is that AmigaDOS is different from the rest of the Operating System. CAOS would have used the same type of data structures as the OS, the same type of stack, the same languages (C and assembler), and would have made understanding the system easier.



--------------------------------------------------------------------------------


This article was found in the online magazine ViewPort, Oct 1993 issue.

Carl Sassenrath made the following comment about CAOS at the AmiWest IRC conference:
CAOS was contracted out, for the most part, to a company that felt Unix was a better choice and didn`t buy into my design. They became history when they started using their Sun development systems for other projects, not the Amiga higher level OS functions.

http://www.thule.no/haynie/caos.html

[DerStrohmann]

Hat ja nix mit met@box zu tun...

[jacop]

#2
Trotzdem Scheissthread!

[DerStrohmann]

#3 You don´t speak English, do you?

[jacop]

#4
I speak english very well.
But i think ,you are a very cheap "farmercatcher" ,who wants the money from the other people!!!

[DerStrohmann]

#5 Of course I want, everyone wants to make money at the stock exchange. Are you an exception? What are you doing here? But what do I do, that you call me "a cheap farmercatcher", whatever that may mean. Everyone is free to decide, which stock to buy, hold or sell, isn´t he? And I don´t want to manipulate the other marketmembers for my effort or elsewhat, because everything, that I do, is only to spread information, so I can see, what they think of these and share my opinion with them. Every information I do spread hear, can be controlled by source. But even if I did want to manipulate someone, I would do so damn bad in your eyes, that I couldn´t happen to be a danger for the other marketmembers.

So what the hell you want, dumbass?

[DerStrohmann]

#5 No Reply is as good as one.

[DerStrohmann]

In the beginning was Amiga

http://www.amiga-magazin.de/magazin/a05-96/domeyer.html

Amiga und die Zukunft
Die CeBIT `96 stand für Amiga-Fans ganz im Zeichen des neuen Amiga-Modells »Walker«. Wir haben die Gelegenheit vor Ort genutzt und Stefan Domeyer über die aktuelle Amiga-Situation und besonders über die Pläne mit dem Walker befragt.

Auf der CeBIT traffen sich auf dem Escom-Stand viele Amiga-Händler und User. Dabei standen immer die gleichen Themen im Mittelpunkt: Wie sieht es um die Zukunft von Amiga aus und ist der Amiga-Walker das Gelbe vom Ei? Stefan Domeyer gibt uns Auskunft.

Wie hat sich aus Ihrer Sicht der Amiga-Markt seit der Wiedergeburt letztes Jahr entwickelt?

Der Amiga-Markt `95 hat sich de facto sehr gut entwickelt. Wir haben aber feststellen müssen, daß wir zu optimistisch geplant haben. Gegenüber diesen Planungen war das Ergebnis `95 natürlich enttäuschend. Wenn man das Ergebnis aber isoliert betrachtet, wieviel Computer wir nach einer sehr langen Dürreperiode, in der es praktisch Amiga nicht gegeben hat, verkauft haben, sind wir trotzdem sehr stolz auf diesen Erfolg.

Wie kam dennoch das Absatzloch im Januar/Februar `96 zustande?

Das Loch Januar/Februar `96 ist zunächst einmal ein saisonales Loch. Zum anderen ist das Weihnachtsgeschäft der Händler und Distributoren nicht mit leeren Lagern abgeschlossen worden, sondern es gab Bestände, die zunächst einmal verkauft werden mußten. Wir beobachten aber jetzt wieder Auftragseingänge. Die Lagersituation bei den Händlern und Distributoren scheint sich bereinigt zu haben.

Wieso sind die Amiga-Händler momentan etwas verärgert?

Die Distributorensituation ist zur Zeit etwas unübersichtlich. Wir haben Distributoren, die sehr klein und spezialisiert sind und wir haben sehr große Distributoren, die ein reines Waren-Handling-Geschäft betreiben, die also für ihre Dienstleistung nicht so sehr auf eine hohe Marge angewiesen sind. Diese unterschiedlichen Profile bei den Distributoren sorgen natürlich für Verwirrung im Amiga-Markt, weil auch der Händler nicht weiß, wo er seine Ware beziehen soll. Wir werden die Situation genauer betrachten und haben bereits mit Distributoren Vereinbarungen getroffen, um eine Klärung der Situation schnell herbeizuführen.

Welche Vertriebskanäle wird es zukünftig geben?

Zum ersten gibt es Distributoren. Dies ist eine kleine Anzahl und zwar diejenigen, die sich wirklich bemühen, ihre Händler zu unterstützen.

Zum zweiten haben wir direkt neue Händler aufgebaut. Wir haben mit unserem Vertriebsleiter Stefan Haas in Deutschland eine Händler-Kampagne gestartet. Die Aquisition dieser Händler hat natürlich vor allem zum Ziel, nicht nur ehemalige Amiga-Händler zu generieren, sondern zusätzlich EDV-Händler, die sich für das Thema Amiga begeistern lassen. Wir schließen an diese Händler-Aquisition auch intensive Händlerschulungen an. Damit verbunden ist die Auszeichnung »Amiga-Certified-Dealer«, so daß der Kunde auch eine gewisse Sicherheit hat, daß er bei diesem Händler Kompetenz und Beratung vorfindet.

Der dritte Vertriebskanal ist das Mail-Order-Geschäft. Mit Quelle sind wir sehr zufrieden. Wir haben auch einige andere große Mail-Order-Kunden, die sich sehr gut entwickeln, die vorsichtig angefangen haben, z. B. Conrad, und kontinuierlich aufsteigende Zahlen vorweisen.

Als viertes sind die »Ketten« von großem Interesse für uns. Bei Media Markt haben wir momentan noch enorme Widerstände, aber wir arbeiten daran, daß Amigas dort künftig angeboten werden. Wir sind auch immer wieder in einigen Karstadt-Häuser vertreten, aber wir haben keine kontinuierliche Listung bei Karstadt. Es ist natürlich unser Ziel, daß die Häuser, die mit Amiga gute Geschäfte machen, die Konzernzentralen soweit überzeugen, daß wir in allen Karstadt-Häusern präsent sein werden.

Welchen Stellenwert hat das Amiga-Surfer-Paket bei AMIGA Technologies?

Das Amiga-Surfer-Paket ist ein Produkt, das eigentlich nicht für die typische Amiga-Gemeinde gedacht ist. Der Ansatz war, das in der Öffentlichkeit sehr stark beworbene Thema »Internet« auf den Amiga zu transportieren. Wir konnten und wollten das Thema nicht ignorieren. Es war aber auch klar, daß ein erfahrener Amiga-User kein Problem hat, ins Internet einzusteigen. Der Surfer wendet sich vielmehr an potentielle neue Kunden, die die Internetlösung als Einstieg in die Amiga-Welt auffassen können. Das ganze Paket ist gekoppelt mit einem sehr attraktiven Preisangebot und dem Provider IBM, der uns erlaubt, dieses Konzept weltweit durchzuziehen.

Warum werden die Stärken des Amiga, Grafik und Video momentan nicht forciert?

Das liegt an der heutigen Konstellation unserer bestehenden Produkte. Wir haben noch das Produktprogramm von Commodore, so wie wir es übernommen haben. Diese Produkte haben Limits. Heute ist ein Computer mit 2 MByte Hauptspeicher, sowie ein Tastaturgehäuse und eine eingeschränkte Ausbaufähigkeit eine starke Limitierung. Genau diese Limitierung gilt es zu sprengen. Das Ergebnis wird der Amiga-Walker sein.

Bei Grafik/Videoanwendungen wird sich auch was tun, jedoch auf einer anderen Vertriebsschiene, da die Video-Freaks klar eingrenzbar sind. Diese Zielgruppe ist durch sog. Value added Reseller zu bedienen, beispielsweise durch Electronic Design. Es gehört wesentlich mehr dazu, so ein System zu verkaufen als ein Amiga-Surfer bzw. Amiga-Magic. Das Fachwissen muß also in die Händlerschaft hineingetragen werden. Erst wenn wir diese Infrastruktur geschaffen haben, lohnt es sich auch werblich in dieses interessante Thema einzusteigen.

Der Walker-Prototyp

Wird das Amiga-Modell »Walker«, das hier auf der CeBIT Premiere feiert, einen neuen Meilenstein setzen?

Es besteht die absolute Notwendigkeit, einen signifikanten Marktanteil im Konsumer-Bereich zu erlangen. Wenn dieser Anteil zu gering ist, ist unser Produkt Amiga nicht attraktiv genug, um Software zu generieren. Von daher stehen wir unter dem Druck, Marktanteil zu generieren, evtl. unter Inkaufnahme geringer Margen evtl. sogar Verlusten. Dazu gehört aber auch eine Vision. Wir meinen, die Vision besteht darin, daß Amiga-User kreativer sind als PC-Anwender. Sie geben sich nie mit dem zufrieden, was sie haben, sie sind immer auf der Suche nach neuen Wegen. Dieses Gefühl hat der Amiga dem User immer gegeben und das muß so bleiben. Amiga-User gehören zu den letzten Home-Usern, die noch programmieren. Das wird man auf Windows-Ebene kaum finden. Der Amiga muß also eine programmierfreundliche Maschine bleiben. Das Thema Spiele trägt zum Image des Amiga als Spielecomputer bei. Wir wollen von diesem Spiele-Image weg, aber der Amiga muß immer ein Computer sein, auf dem es Spaß macht zu spielen.

All diese Ziele wird der Walker erfüllen.

Warum sieht der Amiga-Walker nicht wie gewöhnliche Computer aus?

Wir sind davon ausgegangen, daß wir mit dem A 1200 nur eine begrenzte Zeit am Markt agieren können. Wir haben das klare Ziel, den Power-Amiga (Amiga inkl. PowerPC) zu integrieren, aber wir wissen, daß so ein Entwicklungsprojekt zwar planbar ist, aber Zusagen bzgl. Lieferbarkeit sehr schwer sind. Wir sprechen also davon, ein neues Betriebssystem zu generieren und die Identität des alten Betriebssystems praktisch zu erhalten. Da wir aber ein neues Produkt brauchten, analysieren wir also die Schwächen des Amiga 1200 und bringen eine Maschine, die diese Schwächen des A1200 beseitigt.

Das Ergebnis ist der Walker in seiner jetzigen Variante. Es ist ein vollkommen neues Board integriert. Es ist zwar ein 680x0-Prozessor implementiert, eine Generation, die wir hier noch fortführen werden. Allerdings haben wir die Limitation auch gebrochen. Wir wollen einen Computer, der nicht den Weg ins häusliche Arbeitszimmer findet, im Büro hat er auch nicht viel zu suchen, sondern einen Computer, den man in den Wohnraum stellen kann. Das Designbewußtsein ist in unserer Kundengruppe sehr groß. Wir wollten nicht erreichen, daß die Leute vor dem neuen Amiga stehen und sagen: »Ja, das ist ein neuer Amiga«. Wir wollten erreichen, daß die einen sagen, »ja wir lieben ihn« und die anderen mögen ihn nicht, weil er aussieht wie ein VW-Käfer oder wie ein Staubsauger«. Denn auch bei diesen Leuten erreichen wir, daß über den neuen Amiga diskutiert wird. Der Walker soll auffallen, polarisieren und sich klar von den gängigen PCs abheben.

Ist die Technik beim Walker nicht veraltet?

Die Technik ist überhaupt nicht veraltet, da wir ein offenes Konzept verfolgen. Wir müssen hier unterscheiden zwischen der Boardtechnologie und dem grundsätzlichen Design. Das grundsätzliche Design wird durchgezogen, auch beim Power-Amiga. Das ist die Basis der neuen Maschinen, d.h. wir haben eine modulare Struktur. Der Kunde kann dieses Gehäuse scheibchenweise bis zu einem Big Tower erweitern, in Schritten, die er selbst definieren kann. In diesen Schritten sind dann Slots für weitere Erweiterungen vorgesehen. Wie die Slots aussehen, diskutieren wir momentan mit unserem Partner phase V. Zorro mit Sicherheit, ob es Zorro IV geben wird, ist noch in Diskussion, PCI wird stark kontrovers diskutiert, weil es unendliche Möglichkeiten bietet. Allerdings baut PCI eine Brücke in die PC-Welt.

Wie sieht der Preis aus für den Walker aus?

Wir wollen unter 1600 Mark bleiben. Wir planen einen Ladenpreis von ca. 1500 Mark, allerdings inkl. CD-ROM und wenn wir es von den Design-Kosten her schaffen mit einem internen Modem. Unserer Meinung nach muß es mindestens ein 28800-Modem sein. Es ist nur die Frage, ob es technologisch noch in dieses Preisgefüge paßt. Wenn ja, dann wird es in die 1500 Mark mit integriert sein.

Eine Kaufentscheidung für den Amiga-Walker, der ab Anfang September `96 lieferbar sein soll, muß dem Kunden garantieren, daß ihm die Welt des zukünftigen Power-Amiga offensteht. Daher die Definition eines offenen Buses, der es erlaubt, durch ein Upgradeboard aus dem Walker einen Power-Amiga zu machen. Dies ist ein gemeinsames Projekt mit phase V. Die Hardwarevoraussetzungen werden mit Verfügbarkeit des Walker erfüllt sein. Das begrenzende Merkmal ist das Betriebssystem. Wir haben Hoffnungen, es ebenfalls im Lauf dieses Jahres fertig zu bekommen, wir wissen es aber noch nicht. Wenn das OS 4.0 dann lieferbar ist, gibt es das für den Walker-Besitzer zu einem Preis, der nicht höher ist, als wenn er sich im Frühjahr `97 den endgültigen Power-Amiga kaufen würde. Es lohnt sich also nicht, auf den Power-Amiga im Frühjahr `97 zu warten.

Handelt es sich beim Walker um eine Eigenproduktion?

Der Walker wurde komplett von uns selbst konzipiert. Die Hardware ist mit großer Unterstützung von Motorola-Ingenieuren entwicket worden. Dieses Konzept gilt auch für den Power-Amiga, ein gemeinsames Projekt mit Motorola unter unserer Federführung. Hardwareseitig führt Dave Haynie und softwareseitig Andy Finkel Regie, beides Bekannte aus den guten alten Amiga-Zeiten. Die beiden sind seit November `95 für uns tätig. Wir sind jetzt in der konkreten Design-Phase, d.h. daß Architekturfragen im Betriebssystem zur Zeit definiert werden: Welche Module des bestehenden Betriebssystem sind in welcher Reihenfolge zu portieren, welche müssen ersetzt werden, welche müssen hinzukommen? Die Portierung des »exec« ist bei phase V soweit fortgeschritten, daß wir in den nächsten Tagen eine Evaluierung durchführen werden, ob dieser Kernel der zukünftige native Kernel sein wird, oder ob es eine komplett neue Entwicklung geben muß.

Im Bereich der Hardware-Entwicklung haben wir keine Probleme. Es wird ein vollkommen neu designter Power-Amiga werden als Nachfolger des Amiga 1200. Der Preis für den Power-Amiga soll bei 1000 Mark liegen, wobei dieses Einstiegsmodell in der Grundversion nicht mit allen Komponenten des Walker ausgestattet sein wird, wie 28 800-Modem und CD-ROM-Laufwerk.

Wird es auch einen PowerPC-Nachfolger auf Basis des Amiga 4000 geben?

Unsere Aufgabe ist es ebenfalls, eine Maschine zu bringen, die als High-End-Maschine verstanden werden kann - auf Basis des Walker-Konzeptes. Wir wollen hier das Preissegment unter 3000 Mark nicht verlassen. Wenn der User eine High-End-Maschine haben will, also eine Maschine die Silicon Graphics Konkurrenz machen kann, dann wird er das durch Produkte unserer Partnerfirmen erzielen können, die Erweiterungskarten bauen werden.

Wird es Kompatibilitätsprobleme beim Schritt zum Power-Amiga geben?

Wir wollen unsere Historie nicht abschneiden, aber sie wird uns einige Steine in den Weg legen. Es gibt zahlreiche Applikationen im 68k-Bereich, die uns jetzt schon Probleme bereiten. Wir werden im ersten Zuge die Developer-Guide neu überarbeiten, um eine klare Grundlage für Entwickler zu bieten. Außerdem wird der erste Release des neuen OS, nicht der Version 4.0, sondern 3.2 bzw. 3.3 aus einer stabilen 68k-Emulation bestehen. Wir wollen unsere Software-Potentiale nicht abschneiden. Wir wollen auch native-Applikation haben, wenn der Power-Amiga verfügbar ist. 68k-Software muß auch auf dem Power-Amiga lauffähig sein. Es wird aber dennoch Applikationen geben, die diese Meßlatte nicht erreichen werden, besonders im Spielebereich.

[DerStrohmann]

Postbank bekam Computervirus „Sasser” zu spüren

Bonn - Die Geld­auto­maten der Post­bank sind von den Sicher­heits­vor­keh­run­gen der Deut­schen Post beim Com­puter­virus „Sas­ser” nicht betrof­fen. Das sagte ein Spre­cher der Post­bank am Diens­tag in Bonn.


Der Com­puter­wurm Sasser hat sich schnell ver­brei­tet und welt­weit Com­puter infi­ziert.


Kunden müssten nur bei Bar­aus­zah­lun­gen in Post- Filia­len geringe Zeit­ver­zöge­run­gen auf Grund von Über­prü­fun­gen in Kauf nehmen. Das gesamte sons­tige Geschäft der Post­bank an Geld­auto­maten wie auch das Tele­fon- und Online-Ban­king laufe unein­geschränkt.

Zur Abwehr des Computervirus „Sasser” habe die Post am Montag ihre Sicher­heits­stan­dards erhöht, bestätigte Post-Spre­cher Jürgen Blohm. Von einer großen „Com­puter-Pan­ne” könne keine Rede sein. „Das System hat funk­tio­nier­t.” Berichte, rund 300 000 Post-Com­puter im Bun­des­gebiet wären betrof­fen, seien falsch.

Auch im Kun­den­bereich habe „alles funk­tio­nier­t”. Der Kunde habe sämt­liche Bank-Dienst­leis­tun­gen erhal­ten, sagte Blohm. Nur bei Aus­zah­lun­gen habe er in Filia­len auf Grund von Off-Line-Bear­bei­tung über eine Hotline warten müssen. Die Höhe der Aus­zah­lun­gen am Schal­ter sei auf 500 Euro beschränkt worden. Die ver­schärf­ten Sicher­heits­stan­dards seien noch in Kraft, würden aber im Laufe des Diens­tags über­prüft.

dpa


--------------------------------------------------------------------------------

http://rhein-zeitung.de/a/comscience/t/rzo52752.html
Dienstag, 04. Mai 2004, 11:38 © RZ-Online GmbH (NewsDesk)

---------------------------------------------------------------------------------

Microsoft ist eine tolle Firma mit tollen Produkten.

[DerStrohmann]

@w:o könntet ihr bitte diesen Thread nach 692120 verschieben? danke!