InformIT.com features two special articles (free registration required), excerpts from the “Modern Operating Systems” book by Dr. Andrew Tanenbaum (who is also the author of Minix – the ‘grandfather’ of Linux). This book is valued as the Bible of the operating system design and implementation and every serious OS designer/developer has by his/her side. The two free chapters featured, are “A History of Operating Systems” and “Operating System Threads“. A must read for everyone and if you are serious into operating systems, you should very well buy the book with no second thought. Our Take: It’s that good. Highly recommended by both myself and my husband (who is already largely involved in three operating systems so far).
Two Excerpts from “Modern Operating Systems”
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
but if you plan on reading Operating Systems: Design and Implementation, i recommend reading it first. both books share a LOT of code and its pretty boring to read the other after youve already read one.
Tanenbaum’s light and funny style can help, but doesnt change the fact that half the text in both books are exactly the same.
Tanenbaum’s the troll who told Linus his os was completely outdated, that he should go microkernel. That thing of Minix being “the grandfather of” must give Linus real fits, by jolly.
If you want to learn OS design I recommend an old book (1988) that still is one of the best for a coding start (just for a start):
“Operating Design, Volume I, the Xinu approach” by Douglas Comer/Timothy Fossum.
If you want to read Tanenbaum’s distributed oses, don’t buy it, get it for free on irc. Hate Tanenbaum, he hates you too.
Theres no point trying to read Modern Operating Systems if you don’t have a solid grounding in the theory first. Operating Systems Design & Implementation (Tanenbaum & Woodhill) will certainly provide the theory. Modern Operating Systems is a far more practical book; it includes case studies of Linux & Windows 2000, for example.
As for Anonymous there, I suggest you read up on a little history. Directly or not, Linux was born out of Minix. Linus was certainly using Minix & reading comp.os.minix before Linux 0.1 was written.
My first CS class was at the University of Michigan in the fall of 1981. The intro CS students had to punch programs onto cards and submit them at the desk to run them. There were interactive terminals at the computing center, but they were reserved for staff, faculty, and more advanced students (i.e. CS majors) because they were too precious a resource to squander on students in the first two semesters.
> Tanenbaum’s the troll who told Linus his os was completely outdated, that he > should go microkernel. That thing of Minix being “the grandfather of” must
> give Linus real fits, by jolly.
A troll for being right ‘eh, after all who writes books on how to write OSes for a living? And who has written a book that’s considered the bible for OS developers?
“Tanenbaum’s the troll who told Linus his os was completely outdated, that he should go microkernel.”
Did he really say that? Hmnm, well, actually i’d pretty much agree with it.
Just search for “Linus vs Tanenbaum” on Google.
The most famous is probably the “Linux is obsolete” thread. Here is one archive of it. http://www2.educ.umu.se/~bjorn/mhonarc-files/obsolete/
Water under the bridge… read it, enjoy it, but don’t fight over it 😉
sigh… As much as the material is very good, I wish we could break out of the time warp that the unix generation has forced upon us. I would not have thought 10 years ago that there had been so liitle fundamental progress from designs established at that time. Much of the Linux/*bsd oses that are widely popular are nothing more than embellishments on stuff at least 10 years old. While a strong heritage is good when it comes to stability and security, it is surprising to realize that possibly more innovation is likely to be happening in the Windows or BeOS camps. I remember when the unix systems were novel and a leap forward from the quaint OSes of the 70’s, and were a pleasant breath of fresh air. Now they feel dated and I long for something more novel. (I’m not bashing unix – I use several such machines daily) Even the development of languages seem constrained by this phenomenon – e.g. the step backward from algol/pascal nested block structured languages and their multiple lexical levels to C and its descendandants which only support a single lexical level.
Having said all that, I’ll now contradict myself and say that possibly the OSes we use at the moment are very likely constrained by the hardware that is commonly in use. What I think will be exciting is the 64 bit architectures coming out as they should provide new insights into applying the virtual address space in ways not thought of to date. There are quite a few things I’d like to explore with a 64 bit virutal address space at my disposal.
P
Have you used BeOS? It’s a unix-like no different than any other with a really really nice gui model instead of X11 crap.
Yeah, this is good solid stuff, my only complaint being that Tanenbaum is obviously Unix biased and so the book is a bit biased that way too. This isn’t necessarily a bad thing, but just be aware of it (though I do take umbrage with his attachment to case sensitive file names – this is not, and never has been a good idea).
The chapter on filesystems could also be a bit more in depth, but in a book this size, trying to cover everything in such a large subject isn’t practical.
And yes, Linux was inspired (at least) by Minix, though why Linus thought a monolithic kernel was a good thing… Probably was simpler to implement I guess, but… Well, as has already been said, ancient history.
Errr, yeah, uhuh. BeOS (like many OS’s) has many features that are Unix like (after all Unix was well designed at the time), but to call it just Unix with a better GUI… (that CAN be said of OSX).
When I took my OS classes at RIT, I was surprised to find out that they weren’t using Tanenbaum’s OS books as the texts for the class. They were instead using Nutt’s “Operating Systems: A Modern Perspective”. I actually ended up liking this book, but in retrospective (after reading the two Tenenbaum books) I think that Nutt might have been aiming a little lower… Definately check it out, though, because it certainly isn’t a bad book.
BeOS is a very different animal than UNIX. Maybe you should try it before you open your mouth.
-G
What I think will be exciting is the 64 bit architectures coming out as they should provide new insights into applying the virtual address space in ways not thought of to date. There are quite a few things I’d like to explore with a 64 bit virutal address space at my disposal.
It will be interesting. When the 8-bit days were over, we were using 10MB hard drives (if any) and 128k RAM (though my CoCo3 has 512k and OS9). When the 16-bit era ended, our desktop PCs were running WinDos 3.11, had 200MB hard drives, and had 8 – 16MB of RAM. Now our 32-bit systems, Intel or Mac, have 512MB and 60GB hard drives! What will 64-bit systems force us to spend our money on? Can we count that high? May I predict 8 – 12GB RAM and some storage medium holding 8TB??
I guess what P_Developer is wanting to do (and I *think* Tanenbaum does mention it) would be to kill the filesystem – imagine everything always in memory with the VM managing disk storage in the background… interesting things to come indeed… 🙂
May I predict 8 – 12GB RAM and some storage medium holding 8TB?
that sounds pretty sweet. maybe the memory will be holographic with a much higher bit-density, the chips will be optical and low power… higher res displays, flat panel, of course and fiber/3G high bandwidth networking. and all the size of a Palm/Psion
What I think will be exciting is the 64 bit architectures coming out as they should provide new insights into applying the virtual address space in ways not thought of to date
look at mungi (uhh…. university of new south wales… somewhere) which uses objects in memory, has no concept of filesystem and (in the future) shares them across the network. its fully persistent, using the hdd as a backing store.
it is surprising to realize that possibly more innovation is likely to be happening in the Windows or BeOS camps
certainly w.r.t. file systems. linuyx and the bsds have a fine file system, scatter-gather, soft-updates, etc.. are all good things, but i cant help thinking that microsoft’s idea of unifying the filesystem, registry and etc in a giant database with “meta atrributes” is a much more promising concept, going further than BFS and NTFS, if done right.
The book really is a great high-level overview of how different OSs work. I’d suggest it as a first reading if you’re in to operating systems. Then, you can follow it up with more specific books such as O’Rielly’s “Understanding the Linux Kernel” and “NT Internals.” Lastly, you probably want to look at some of the numerous papers about OSs available one citeseer, such as Charle’s Cranor’s UVM paper and Jeff Bostwick’s SunOS slab allocator paper.
I have the first edition of “Modern OS”, published in 1992. I also have Tanenbaums “original” OS book, complete the Minix listings (and on floppy). Tanenbaum also wrote one on Distributed OS’s (part of which was in the orignial Modern OS book), but expanded the discussion on case studies (he covers MACH, and Amoeba, another Tanenbaum creation). Highly recommended, even if some is a bit dated.
what i have been saying for a while, i personally want the os that was in wargames….
While i think that a filesystem based on a database could be handy, i dont think it would be suitable for slower machines. Which makes me ask myself “Are we going into an era of server computing or coming out of one?”. I love server computing, why not let the monster CPUs of our day actually work instead of do the so very little that they do nowdays (unless you let it chomp on a passwd file). I use my Alpha 500Mhz (not the fastest of beasts but it holds its own) as an XDM server and my P120 as the XDM client, and even then, its very rare that i see CPU usage go over 30%.
Even if the VM starts managing the user-level portion of the file I/O layer, there still needs to be a filesystem underneath managing that data on disk.
I had the rare experience of enjoying a CS lecture on operating systems without any reference to Tannenbaum at all. As long as you stick to the concepts presented in “Modern Operating Systems”, you can’t go new places. If you want to read something really modern on operating systems, look for Leslie Keedy and his Monads and Speedos projects.
During the mid eighties AmigaOS did not only integrate the best features found in prior operating systems, but also supported excellent pre-emptive multitasking, workspaces, autoconfig, long file names, shared libraries, stereo sound and alot of other novelties.
The http://www.haage-partner.de/amiga/CommodoreBillboard/Amiga1000Comme… (1985) for instance was the first computer to introduce a color GUI and was able to show photographs in up to 4096 colors simultaniously. You could also do many things simultaniously, like listening to music, drawing pictures and formatting diskettes without any slowdown and with an immediately responding user interface.
As I already mentioned workspaces I should add that you could not only have different workspaces but you could drag down screens as well, revealing the underlying workspace regardless of its resolution or color depth. This was sometimes usefull. This feature is still unique to classic Amigas and I believe if this functionality had continued to advance it would have allowed alot more flexibility as compared to the GUIs solutions available today.
As if this isn`t enough already, in the eighties Amigas were the first inexpensive solutions for video editors and graphic artists with which you could easily create subtitles for movies or http://www.haage-partner.de/amiga/CommodoreBillboard/AmigaAdCeleb.a… .
I still remember many so called “computer experts” at the time stating things like: “GUIs are only good for people who can`t type!”. Of course you could limit yourself to a Command Line Interface with AmigaOS as well, but unlike with other systems you could run countless CLIs simultaniously while allowing you to multitask between applications. Of course what these people said made no sense as there are tons of things that can be done faster in a graphical environment as compared to limited CLIs. (But for me personally a good CLI is a must have feature, but IMO of lesser importance compared to a well designed Graphical User Interface.)
> combine colorful graphics with movies.
I meant to link to http://www.haage-partner.de/amiga/CommodoreBillboard/AmigaAdCeleb.a… instead. 🙂
WARNING: THIS IS A LONG ONE
Ah, the hardware question, I’m so glad it was brought up, because now I can rant. The design of many, no, most OS’es was at least partially dictated by the limitations of the hardware it runs on. Oh, not just the main processor, you see. CPU tech marches quickly on, with limitations and barriers being broken faster than you can say “Moore’s Law”. I/O and storage, however, while there is invention and innovation, is more like a tortoise. For every new generation of processor, the I/O and storage can only exploit a fraction of that processor’s potential.
This is so important it’s not even cute. Most things computers do need input, output, computation, control, and storage. The main processor handles control and computation, and right now, and the tech behind them is screaming for the other 4 to catch up.
By the time your swanky 64-bit, 1 GHz dual AMD Hammers (like 8 Gigabytes/sec. potential throughput EACH) reach RAM, they’re only talking at 64 bits and 400 MHz (3.2 GBytes/sec., assuming God’s own I/O controller, otherwise, because each Hammer has to share, it’s 1.6 GBytes/sec. each). That’s not so bad, right? Well, by the time it hits the hard drive it’s down to PCI bus speeds: 64 bits at 66 MHz, ~536 MBytes/sec. throughput in NeverNeverland, much less in da real woild. Yes, I know there are solutions around the corner for this, but there will then be superduper new processors that will make the NEW new I/O and storage tech look weak.
Every programmer’s wet dream is for there to be an I/O tech and a PERMANENT storage media that can exceed the main processor in data throughput. Also, that neither be prone to failure (some permanent storage media are VERY prone to failure). Then there would be more than enough storage and bandwidth for anything the processor wants, and for all the other little coprocessors (sound, graphics, etc.) to play in too. This has not happened.
Until then, the truly great operating systems have fast, safe, secure, and efficient ways to juggle and use these limited resources without pooping all over themselves (stability, stability, stability). Some were painstakingly designed this way in the first place, others arrived there through trial and error. Many make sacrifices to fulfill a certain goal more completely. Some trade speed and efficiency for security and stability, or vice versa. A few have even figured out how to come very close to having your cake and eating it too.
Now, to amuse yourselves, imagine these spiffy new storage and I/O technologies retrofitted to processors with less raw power and throughput. If properly REDESIGNED, the older processors would suddenly have oceans of bandwidth and storage to play in, and would become super-efficient, ideally, but the trade off is ultimately not worth it. Yet, in the embedded space, a few niche computer systems, and in some video game systems, people do this, and efficiency does increase. In the supercomputer and mainframe market, they close the gap in other ways, usually involving leapfrogging current I/O and storage and inventing their own, and trading potential raw processor power for more efficient I/O and storage use.
Ok, I’m done. Most of you know this stuff already, including Mrs. Eugenia Loli-Queru. Some of you don’t, and I hope I’ve helped. I’m likely wrong about some things, or everything, and please correct me. That’s all. Bye.
J.M.
I suspect that hardware will be a limiting factor for quite a while yet, but yes, you have to design to your hardware (which is why h/w specific OSs are more efficient and more stable – you trade off against available platforms).
Someone else mentioned the Amiga, this is a case in point, the Amiga had no hardware MMU when first introduced so the OS doesn’t support protection or VM (though MMUs and VM came later, protection never did except in limited form, though this would catch 95%+ of programming errors, and supply feedback so the developer could fix things).
I guess all this would explain P_Developer’s issue with many so-called ‘modern’ OSs, most are rooted in the past and assumptions that aren’t always now relevant, whilst the boon and bane of backward compatability is ever present.
> The design of many, no, most OS’es was at least partially dictated by the limitations of the hardware it runs on.
Sure, for instance at the time of the development of the Amiga platform, there was no hardware available which could support multimedia. Without customly designed hardware AmigaOS could never have become the milestone multimedia operating system it is.
The one important feature currently missing in AmigaOS 3.9 is memory protection. Although AmigaOS has proven that there are many workaround solutions for this and also proven to be more stable as compared many memory protected OSes. We have seen developments of very solid and useful memory protection solutions (i.e. the memory protection in QNX RtP is most excellent. ) http://www.getboinged.org/roundup.asp?A=49“>AmigaOS for PPC will support optional memory protection.
Beware, saying “modern” operating system can be misleading. Modern refer to “present” or “contemporary”. Not to say that it’s not good to know what is currently done and the history of OS, just that modern is not cutting edge technology.
Personaly i see very few OS project that pass my test. The test is that the Moore law line should be parallely followed by productivity increase (at least). Since around the time of the amiga, it’s no more the case (tank you microsoft).
Now on the fact that the hardware play a role, you bet it does. I’m really sick of the PC architecture. Most of my OS idea just can’t be done on usual PC. Not because of processor speed but because of architecture. For exemple i always thinked it is impossible to have a real time system with less than 3 processor.
I also think that having base 2 number instead of base 3 is a big limitation. We are like the roman not knowing the zero.
Another common thread call is thread_yield, which allows a thread to voluntarily give up the CPU to let another thread run. Such a call is important because there is no clock interrupt to actually enforce timesharing as there is with processes. Thus it is important for threads to be polite and voluntarily surrender the CPU from time to time to give other threads a chance to run.
<p>
What is this article describing, Win3.1? Or more likely early unix user-library-sort-of-threads-but-not-really. In any case, any operating system worth its salt these days will pre-empt threads, just as it pre-empts processes. There’s no good reason not to.
BeOS is more like unix than MacOS, that is for sure, and much less than OSX (which is a mach micro kernel at one time, and now FreeBSD flavored on top). Linux is UNIX (gosh, maybe the name resembles it somehow also???), with not much else to offer IMHO other than a much less disorganized and overhyped (but catching up fine and dandy) community. One thing that BeOS is that many other OS’s aren’t, IT IS DEAD and the religious right have infiltrated its leftover rank (s).
Biggy
You get exactly what you want when you buy into .NET, and the whole M$ braindead arrangements on licensing, quality (lack of) and cost to consumer via monopolistic and preditary behaviours. Would you like CHEEZE with your World Of Prophecy in Redmond (WOPR).
BG’ez
I must admit that I was a big fan of BeOS all the way up until the company’s demise. I was wondering what made BeOS more like Unix that MacOS, preemptive multitasking and a decent virtual memory system? Anyway, what I was really wanting to find out was everyone’s thoughts on MIT’s and their helpers’ new concept of the exokernel.
Mach (which OSX is based on) is a Posix compatible microkernel, FreeBSD is a Unix clone. BeOS was developed from the ground up, so whilst elements of Unix design exist in it, it has no real connection to Unix (Has BeOS a Posix layer? I can’t remember). AmigaOS was also ground-up, but again, a Posix/Unix compatability layer was available (though this really just made porting easier, as the AmigaOS filesystem and structure is very unlike Unix).
Many current OS designs owe much to Unix, but that doesn’t make them Unix.
I think MIT’s exokernel is really interesting. I’ve downloaded the availble papers on and have read a some it sounds like a really good idea to me when I get FreeBSD running the way I want it I might atempt playing with it.
MultiVue for OS9 was a color GUI that predated AmigaDOS’s Intuition. Actually, most of the things claimed for AmigaDOS on a software level were done by OS9 a bit earlier and arguably better: not only was it a multitasking windowing OS, it ran in less memory, offered superior memory protection and was multiuser to boot
I’ve always wondered what would have happened if the pre-production Amiga had been bought by Radio Shack instead of Commodore; I’m sure the idea would horrify “Trash-80” bashers, but I suspect Tandy would have moved OS9 from the Color Computer onto the Amiga hardware.
WattsM…
MultiVue for OS9 was a color GUI that predated AmigaDOS’s Intuition.
MultiVue was released as an addon for the CoCo 3 (running OS-9) after the release of the Amiga in 1985. OS-9 was a very limited OS (compared to AmigaOS) in 1985, MultiVue was more within the ranks of 8-bit GEOS than the 32-bit pre-emptive multitasking AmigaOS.
MultiVue for OS9 was a color GUI that predated AmigaDOS’s Intuition. Actually, most of the things claimed for AmigaDOS on a software level were done by OS9 a bit earlier and arguably better: not only was it a multitasking windowing OS, it ran in less memory, offered superior memory protection and was multiuser to boot
I remember it well. Never crashed on my Coco3 512k.
I’ve always wondered what would have happened if the pre-production Amiga had been bought by Radio Shack instead of Commodore; I’m sure the idea would horrify “Trash-80” bashers, but I suspect Tandy would have moved OS9 from the Color Computer onto the Amiga hardware.
Tandy treated the CoCo and everything that ran on it as toys. They abandoned all of us who poured a lot of money into those systems instead of providing a path upward. We had an 8-bit *nix that ran reasonably fast and could mustitask all day, plus a decent language in Basic09. You could even chage the floppy drive step rate from the OS! RIP. I hate to think what they would have done to the Amiga.
The CoCo 3 was a nice machine for its time but was sadly eclipsed by the success of the Commodore 64. Amigas are within a total different level of computing. In the 80s Amigas were THE graphics workstation to own.
Nowadays OS-9 is solely used in embedded realtime environments, most notable the dead Philips CD-i platform.
Taken from Unitech`s website http://www.unitechelectronics.com/opsys.htm , it explains some basic AmigaOS 1.x features pretty well.
Learn about the unique Amiga operating system
What Operating System does the Amiga use and why?
The Amiga uses “AmigaOS”, a unique “OS” with very special advantages. It is extremely compact, highly efficient and still enormously powerful and thus resulting in being especially fast. It was the first Operating System with Multi-tasking and a GUI (Graphical User Interface) in full color for the mass market back in 1985, bearing in mind that most “other brands” still only had less than 16 colours in 1985.
The Design of the O.S.
AmigaOS is modularly designed and consists primarily of functional libraries. It’s opertional capabilities can be expanded at any stage by the user by adding in new libraries, these are often added when a new program is added to the hard drive, these libraries are very easily to install and update the AmigaOS in a totally system compliant way. This makes the AmigaOS extremely flexible !. AmigaOS has stood the test of time and has had over 14 years to mature and to be improved upon. During this time there have been several versions and upgrades to the AmigaOS , from the early days in of the first OS in 1985, to the current version V3.1 AmigaOS used in All AMIGA’s today .
The Old 1.1 A1000 system.
OS Version 1.1 KICKSTART 1.1® for the A1000 was originally written by Commodore-AMIGA, a little known fact ! and indeed within a short time, it was quickly replaced by a smaller, more efficient operating system 1.2, followed by 1.3 in August 1987 for the A1000 , The entry was made of the world’s first pre-emptive multitasking and multimedia Computer, a machine with 4096 colors out of a palette of 16.8 million colors.
A small piece of trivia, a Microsoft written program which was called AMIGABASIC ® was incorporated on the A1000
This phrase Multimedia, was first “coined” by the AMIGA Software Engineers, later to be “mimicked” and “imitated” by many others …. It is often said, that imitation is the highest form of flattery. The AMIGA Platform is pleased to say, “we were there first…in 1985 !”
The Old 1.3 system.
The V1.3 Operating System was then, too, improved upon by the original Commodore Software Engineers ,back in the mid ’80s , then newer upgrades progressed through V1.2, V1.3, V1.4 BETA which was a major step forward in which the screen progressed to displaying even more colors than was first envisaged , this transition took quite some time and emerged as the newer V2.0 of the AmigaOS. This was a milestone and was indeed a major enhancements of its functionality. But still the AmigaOS grew faster with every newer version because of increased efficiency in programming !.
Efficiency ? what’s that ?
Amiga Programmers are paid on efficiency, and it is said, anyone can virtually write heaps of machine code , but the challenge is to write it so that it works and works extremely well and is at the same time very effective, well presented, logical machine code .
In 1990 V2.04/05 was released shortly followed by V2.1 software. In 1993 Version 3.0 was released a vast improvement in speed and a highly adaptive GUI (Graphic User Interface) was refine and fine tuned to enhance what was clearly a innovative trend setter in operating systems. Following the successes of V3.0, 3.1 followed on with even finer refinements and enhancements in the AmigaOS!
Flexible, compact, fast – the attributes of a truly modern operating system.
What’s so special about the multitasking of the AmigaOS ?
AmigaOS features Pre-Emptive multi-tasking. This means any given program does not actaully need to be explicitly wriiten nor designed for multitasking and still it works highly effectively together with many others, all operating simultaneously. The reaction on user actions is virtualy instantaneous, the mouse pointer and cursor follows the mouse moves without any delay , no odd screen mouse drag that is on experienced on many other platforms.
What type of hardware demands are made on the AmigaOS ?
The AmigaOS is extremely efficient with regards to the very small of the amount of memory used and the computing time required. Typically with only 1 or 2 MB RAM, one can multitask a few programs or several full-blown application programs virtually without any noticeable delays, the delay will be in the fingers of the operator keeping up with the AMIGA . It is because of these efficiencies and the applications by good highly talented programmers, the Amiga’s Operating System takes up a mere 4MB and other typical applications need relatively little hard either drive space as well!, an example of a large program is LIGHTWAVE ® from NEWTEK ®, which incidentally owes its birth and life developement on the AMIGA, Full Lightwave and all its add-on properties will fit comfortabley on a 1GB Hard drive along with many other fine applications and programs
Why is AmigaOS considered a “Realtime OS” ?
Well, theoretically in reality, no OS is realtime, But!..having said that, lets consider for a moment reality. In practices the answer is an unequivocal YES!. If there is to be a so-called “realtime OS” you must be able to fully guarantee the maximal reaction times after external or internal signals are sent . For the AmigaOS, such guarantees are not given, but on the other hand it’s so efficient and fast in reaction time, that it is already used in many realtime control applications in the industry, Here in Australia, CLUB KENO ® , a game of chance, where selection by random numbers ( animation of colored balls within a glass sphere ) are displayed in Registered Clubs via TV, these are utilising only part of the Amiga’s full potential as a multi-tasking data input device with screen display for public viewing on Television screens throughout each Club and Hotel and Casino The same concept cannot be economically nor efficiently replicated on any other platform to Date, and the first generation of AMIGA’s , the humble A500 operating at 7.09MHz with only 1MB of ram still operates the CLUB KENO Today !, just as efficiently as ever, back when it started many years ago.
Why is the AmigaOS “Object Oriented” ?
The Amiga Operating System was created in a time when “OO” was not yet a hype term. But it is state of the art that incorporates many ideas from “OO” object oriented design and software philosophies. This is one of the reasons why the AmigaOS is so compact, efficient, and simultaneously very flexible indeed. Others have implemented this concept into their platform’s system .
Is the Amiga Operating System 16-bit or 32-bit or what ?
The AmigaOS has been since its first early days in 1985 a 32-bit OS, thanks to the internal 32-bit architecture of the Motorola 68000 series microprocessors. Also every application in software is thus fully 32-bit. So you do not need a new operating system and a completely new set of application software to exploit the 32-bit features of the current generation of processors, it happens automatically, software written back in 1986 under the developer guidelines still works today under the newest 3.1 operating at 66MHz on 68060 microprocesor in an AMIGA A4000 TOWER or Desktop.
What AMIGA programming languages are currently available ?
There are assemblers, Pascal, C, C++, Modula 2, Oberon, Fortran, Forth, Basic compilers, and several special or unique languages like BCPL, E, scheme, Cluster, ARexx, Lisp, or Prolog. For the most , a major part of the AmigaOS is written in C, the time-critical parts in assembler. For most languages there exist highly reputed commercial compiler packages, as well as ecellent Public Domain and Shareware versions that make it easier for beginners to enter the realm of the Amiga programming world. Programmers are supported by system documentation in book form, the AMIGA ROM Kernel Manuals, and in electronic form on floppy or CD with Autodocs, Includes, Tools, and examples, these are of course , available and ordered from Genuine Dealers or Amiga International under certain guidelines.
So, what’s so special about the Motorola range of microprocessors ?
The Amiga uses microprocessors of the 680×0 family made by Motorola, where the x stands for 0, 1, 2, 3, 4, or 6 currently eg: 2 in 68020 or 4 in 68040. Already the first member of this family is fully implemented with 32-bit width, though it appears more as a 16-bit type externally . This processor family is widely used in industry, stand-alone plant and machinery controls such as Programmable Logic Controllers or (PLC’s)as they are known, the 680×0 family is especially versatile and flexible to program and offers the programmer many possibilities to optimize his or her software. Key words for the expert are “Flat Memory Model without limiting segmentation”, a big number of internal, really general-purpose registers, and a “nearly orthogonal command set”, awesome stuff indeed !.
What is a GUI Graphical User Interface and why use it ?
Thanks must first go to Xerox ® in Palo Alto, where back in the early 1970’s their software engineers pioneered the first concept of a ” Mouse ” type of device that appears on our very own computer screens today. With the graphics on your screen, a normal, but of course abstracted bureau environment is displayed where e.g. files are kept in “drawers”. With your mouse you can mark and manipulate (or drag) these objects, you select items from menus or trigger certain actions by clicking on some graphical symbol (Icon).
Short bit of history
Now for a little bit of not so well remembered History. It is a little known fact that this “mouse driven” concept was in fact an optional extra on the old famous Commodore C64, through GEOS (Berkley Softworks) and also a ROM based Cartridge program called FINAL Cartridge for the C64, legendary in its time, with 16 screen colors.. A concept that was totally unheard of, back in 1983, other platforms were dreaming of the day when they too, could have such living colors gracing their screens. Today, thanks to the pioneers in design of those symbols, their function is immediately visible and you can work with high productivity without needing to learn much about it. That’s why the part of the AmigaOS which handles these elements of the GUI is named Intuition, very clever programming guys !
that sounds pretty sweet. maybe the memory will be holographic with a much higher bit-density, the chips will be optical and low power…
—-
If that means NO FANS, bring it on!
It is a little known fact that this “mouse driven” concept was in fact an optional extra on the old famous Commodore C64, through GEOS (Berkley Softworks)
All good and well but GEOS was released for the c64 in 1987. 2 years later than the release of the Amiga (so what`s the point?). BTW with the 1985 Amiga GUI you choose your workbench colors from a palette of thousands of colors.
WattsM:
I agree that it would have been better if I hadn`t said “color GUI” without further explanation. One could even say that a green monochrome GUI is in fact a “color GUI”. Although there was no GUI available at the time which could compare to AmigaOS` color GUI, I was wrong to say it the way I did.