Talk:AmigaOS

From Wikipedia, the free encyclopedia

Contents 1 OS4 Final Realised 2 Can someone make a History section, please? 3 AmigaOS vs AmigaDOS 4 AmigaOS 4 5 PCMCIA support in Workbench pre-3.0? 6 My AmigaOS structure overview 7 Recoverable Ramdrive 8 Amiga OS 4.0 Question 9 Spelling error? Joilet vs. Juliet 10 Standard "OS Stats" infobox for AmigaOS? 11 Technical and stylistic improvements 12 Update to AmigaOS 4 13 exec.library, microkernel, etc. 14 Future 15 Kickstart disks 16 Freeing memory

[edit] OS4 Final Realised

Comment: Now, there shall be havy change to mainpage :-) Sources: Amiga World News Hyperion news

Leuven, Belgium, 24 December 2006.

Hyperion-entertainment is very pleased to announce the immediate availability (for registered AmigaOne customers) of Amiga OS 4.0, The Final Update.

Originally released in May of 2004, Amiga OS 4.0 (www.amigaos4.com) is the most stable, modern and feature-rich incarnation to date of the multi-media centric operating system launched by Commodore Business Machines (CBM) in 1985 with which it still retains a high degree of compatibility.

Amiga OS 4.0, The Final Update is the culmination of 5 years of development and takes the form of a stand-alone ISO image which contains a full installation of all Amiga OS 4.0 components.

A list of new features can be found here .

Availability of PowerPC hardware suitable for operation with Amiga OS 4.0 will be announced by third parties early 2007.

The Hyperion Entertainment management would like to take this opportunity to wish all our customers and supporters a pleasant holiday season!

Links: Amiga OS4 Hyperion Amiga section

--Rastavox 22:59, 5 January 2007 (UTC)

[edit] Can someone make a History section, please?

I think readers might be interested on the background of the AmigaOS. I'd write something myself, but I'm one of those that know little about it. --Saoshyant 17:09, 3 August 2006 (UTC)

Is AmigaOS versions what you were after? Cheers, CWC(talk) 19:58, 3 August 2006 (UTC)

[edit] AmigaOS vs AmigaDOS

When did AmigaDOS become AmigaOS? It's a long time since I used an Amiga and I'm sure it was AmigaDOS in those days. —The preceding unsigned comment was added by Mintguy (talk • contribs) 2003-05-11 00:47:24.

It was never really AmigaDOS, although some users called it that. AmigaDOS refers mostly to the DOS library, and device system. Most people called the operating system "Workbench", or when referring to requirements for games that didn't use workbench, "Kickstart" was used. AmigaOS became the prevailing term around the time that AmigaOS 3.5 was released. Lumpbucket 08:48, 12 Aug 2003 (UTC)

What about this then?

http://www.mtb.ee/~mac/museum/amigados.gif
http://www.nepots.org/~a-rec/shots/adosbeg.gif
http://www.amigahistory.co.uk/adosinout2bk.jpg (paste this into your browser, it doesn't allow you to go to this page via a hyperlink)
http://www.amigahistory.co.uk/adosqck1.jpg (paste this into your browser, it doesn't allow you to go to this page via a hyperlink)

Mintguy 09:29, 12 Aug 2003 (UTC)

Note that pretty much all of those (including the only official one) refer to the CLI, which is only a small part of AmigaOS. I'll gladly add the CLI to the "list of stuff" to which AmigaDOS refers up there, however it is not a "catchall" term, and does not cover Kickstart, Workbench, intuition, the graphics library etc. As I said though, some people did use AmigaDOS to mean the whole OS. Lumpbucket 09:44, 12 Aug 2003 (UTC)

I suspect that "DOS" was pretty much synonymous with "Operating System" for most people back then. If it manages files on disk, then it must be "a DOS". (an OS can print stuff to screen, a DOS can write to disk too, sort of.) Plus, of course the fact that when you booted a game from floppy you only saw the "AmigaDOS" window title might have contributed. You rarely saw much of Workbench if you had the machine mostly for games. Magetoo 13:33, 11 Nov 2004 (UTC)

AmigaDOS just kinda turned into AmigaOS during the nineties. They're both mostly the same thing, and the CLI window will say AmigaDOS, but calling it AmigaOS just kinda came into fashion at one stage. I don't think either are technically incorrect. --Jonathan Drain 02:54, 10 Jan 2005 (UTC)

More terminology: I don't believe the phrase "Workbench is the native graphical user interface for the Amiga computer." is correct. The Workbench is the desktop environment, to put it in standard terms. I have rarely, if ever, heard people who know anything about the Amiga call the GUI anything else than Intuition.

The part that without Workbench "...the application will lose the ability to multitask with other applications" is just plain wrong. It might be difficult to launch other applications though.

Oh yeah, and the IPC efficiency is more due to the lack of memory protection and nothing else. (you can pass around pointers to any area of memory as long as you can coordinate things somehow, so no need to copy memory.)

Comments? I assume the article is written this way for some reason, and I'd like to know it before I start changing things.

Maybe the article is written this way for a reason, but it must be a wrong reason, since it says false things ;-) I've noted your criticisms and changed the paragraph about Workbench accordingly, although I've left some big confusion between WB and Intuition untouched (for example, multiple screens are not a feature of WB, but of Intuition, of course!).

I'll probably rework the entire subchapter tomorrow or like that. Anyway, why are you afraid to edit? I'm new to Wikipedia, but from all the tutorials etc. I understand that you should not be! At least if you have valid reasons for editing. Which, in this case, you definitely had. —The preceding unsigned comment was added by LjL (talk • contribs) 2005-04-10 03:12:05 (UTC).

Some day I'd like to write something about the separation between kickstart and the disk-based part of the OS too.. Magetoo 13:33, 11 Nov 2004 (UTC)

---

Some explanations

---

No problem you too. There is a little confusion but I will try to explain it all.

AmigaOS was the original name of the OS.

Due to a mistake of marketing of Commodore in printing vaste amount of labels of OS disks, the first release of Disks were labeled just "Kickstart" and "Workbench" and so the OS was sold on the market. People who bought Amigas believed that the name of the whole AmigaOS was WORKBENCH because they read Workbench on the disk label. Other people referred to AmigaDOS 1.3, because unexperienced people beliee that AmigaOS WAS AmigaDOS, beacuse they were influenced by MS-DOS and its way to indicate releases. Even Commodore employees sometimes referred to the AmigaOS with same terminology. But to be correct in definitions, the AmigaOS is a well balanced mix of different components. All this common consents in using incorrect names ended when Commodore released AmigaOS 2.0 (and more 2.04) and decided to re-introduce proper names to any installation disk (Fonts, Kickstart, Workbench, Tools, Extras), and to refer to all OS with its right name.

@ Magetoo:

Workbench is the GUI of Amiga. Intuition is the ENGINE of this GUI. AmigaOS components are strictly tied each one and Workbench is strictly tied with intuition. With introduction of BOOPSI (Basic Object Oriented Programming System for Intuition) Object Oriented System, Workbench could be improved or replaced by other GUI interfaces such as ScalOS. AmigaDOS is only the part of entire OS which deal with filesystems and commands, and DOS commands of AmigaDOS can be accessed thru CLI or SHELL interfaces. Amiga CLI windows are always named with "AmigaDOS" on the titlebar of the windows. This explains one of the images that user Mintguy linked to. Hope I was plain clear and get you away of your doubts.

--Raffaele Megabyte 09:47, 11 March 2006 (UTC)

Well, I was mostly trying to put myself in the position of those who used the term "AmigaDOS" for the whole OS and think of a reason why they did that, I think it's pretty clear myself. And my shell windows are labelled "AmigaShell", by the way. :-)

Actually, I'm not so sure about your divisions. Workbench is more like a "desktop environment", imho. It's basically an application like any other. Intuition is the GUI (and "widget toolkit", I suppose). I personally replaced Workbench with DiskMaster (a file manager) for a period; that didn't make the GUI disappear from all programs I used.
-- magetoo 21:14, 21 May 2006 (UTC)

People... Workbench is not the GUI and Workbench is not a "desktop environment" (besides, let's leave this term alone, since today it's mostly used as a catch-all term for just about everything that pops on your screen).

Workbench is a file manager, and it's also the default shell of AmigaOS. Just like Finder on the Macintosh. Just like Program Manager on Win16 (well, err, except that ProgMan is not a file manager because the filesystem structure was too encumbered for them to use a file manager as default shell). Note that the articles for all of these mention the term "shell" in the first sentence or so.

Don't be confused by the fact that "shell", on the Amiga, is traditionally used as a way to refer to the CLI ("AmigaShell"): the term "shell" itself doesn't imply a command line interface at all.

Adding to that: Intuition is the GUI (i.e. what in Unix and X11 terms would be called the window manager + GUI toolkit, examples of the latter being Qt and GTK). Except that, since OS 2.0 on, applications could use GadTools instead, a more advanced toolkit, which itself uses Intuition at a lower level. Then you have MUI, ClassAct and all that... but originally, the GUI was simply Intuition.

LjL 21:29, 21 May 2006 (UTC)

I agree. (I was even going to compare WB to the Win32 shell, but decided not to, since I wasn't sure about all the facts. What is/was it, "explorer.exe"?)

Still, the name "Workbench" was chosen to relate to "Desktop". Sure, for marketing reasons most likely, but still. I don't think I ever heard anyone call the Workbench a "shell" back then, but is was referred to as "a desktop" lots of times (a catch-all term even then). Terminology changes I guess...
-- magetoo 22:31, 21 May 2006 (UTC)

Yeah, I too avoided mentioning explorer.exe, as it's anything from a web browser to a file manager to a taskbar (though I "suspect" it's just a relatively small program that uses a lot of DLLs). But all in all, yes, explorer.exe is the Windows shell now: just open win.ini or system.ini, don't remember which of the two, and you'll see Shell="explorer.exe" (at least in Windows 9x).

As for the name "Workbench" relating to "Desktop", that's true. There's the "Workbench screen" too. But I think that was just Amiga's (or Commodore's) choice to let the user consider the Workbench program and the "workbench-as-in-desktop" as intermixed, for better user experience or somesuch. But that shouldn't distract us when we're trying to reason in more technical terms.

Also, technically the AmigaOS doesn't even have a "default" shell (like Windows with that entry in win.ini): after all, Workbench is simply loaded by a command in a very normal script (the startup-sequence). Just put in another command, and you get another shell. You could even argue that the default shell really is AmigaShell (aka CLI) -- since if you have no startup-sequence, what you get is a CLI window. LjL 23:59, 21 May 2006 (UTC)

[edit] AmigaOS 4

I reverted Lumpbucket's edit.

One of the main features of Amiga, Inc is that it's a software (and IP licensing) company, and one of the main features of AmigaOS 4 which ultimately is controlled by Amiga, Inc is that it's meant to run on third party hardware. Unless Amiga, Inc, who (allegedly) owns the "Amiga" trademarks, have ownership of or control over hardware development, it's not only entirely meaningless but also confusing and possibly dishonest to talk about "new Amigas". Amiga, Inc has no such control whatsoever.

The current marketing of hardware as "AmigaOnes" is a logical result of Amiga, Inc's third party hardware direction. The "AmigaOnes" may or may not be the only hardware to ever become licensed, Eyetech may or may not be the only hardware distributor that applies for and/or is granted a licence, and the Terons may or may not be the only hardware that this company decides to market under the "AmigaOne" label. There is no "official continuation of the Amiga line" of computers. "Amiga" today is the name of a corporation, and it used to be the name of a now obsoleted line of computers.

From Amiga, Inc's Guidelines For Third Parties Who Use Amiga Trademarks:

• Amiga trademarks must always be used as adjectives followed by a generic product name.
  • CORRECT: You?ll love the next generation of Amiga operating systems!
  • INCORRECT: You?ll love the next generation of Amigas!

• Do not use the Amiga trademarks in the plural or possessive form.
  • CORRECT: The new Amiga operating systems are more flexible than ever!
  • INCORRECT: The new Amigas are more flexible than ever!

Some of their own marketing material frequently shows inconsistencies here. But the purpose of Wikipedia is not to copypaste marketing material and pass it off as articles, even if that actually were consistent or even factually correct.

194.176.88.28 13:22, 22 Dec 2004 (UTC)

>it's not only entirely meaningless but also confusing and possibly dishonest to talk about "new Amigas"

The original article read as follows:

>AmigaOS 4.0 will run on Amiga 1200 and 4000 computers with PowerPC accelerator boards, and the new AmigaOne systems.

"AmigaONE" != "new Amigas". The AmigaONE is also new (at least compared to the rest of the hardware mentioned in the article) so I see no problem with that wording.

[edit] PCMCIA support in Workbench pre-3.0?

If PCMCIA support was only added in 3.0, as the article says, how come the 2.0-using A600 had PCMCIA slots? I used Workbench 2.1 with a PCMCIA CD-ROM device. --02:51, 10 Jan 2005 (UTC)

You're quite right. A600s shipped with 2.x and software for the PCMCIA slot. -Lumpbucket

I think 2.05 was the first revision to support PCMCIA. A typical design move by Commodore to put the interface on upside down to the correct standard, thus rendering most pc devices useless. McGonicle 12:01, 27 December 2005 (UTC)

[edit] My AmigaOS structure overview

Please keep an eye on the stuff I'm writing, with some particular attention of terminology (like my use of "specifier": is there a better, standard, AmigaOS term instead?).

Also, if you plan to add to it, please consider that in my view it should be an AmigaOS overview: a detailed overview maybe, but without going into details that are not strictly related to the OS. For example, I don't think one should talk about draggable screens there, because (besides the fact that it's mostly a hardware feature) it's not quite an inherent feature of AmigaOS -- and in fact, screens are not draggable on most today's screen. Should one even talk about screens (or stuff like that, of course this is just an example) at all? I'm not sure, but I think not. The concept of a screen is part of AmigaOS, yes, but it's more specifically part of Intuition, and for reason of length, it would possibly be better to talk about it in a separate chapter or in a separate article.

This is obviously all just IHMO since "anyone can edit", but my hope is to have an Overview section that's coherent, interesting and not unnecessarily long, and I'm sure that everybody agrees with this.

LjL 13:24, 8 Apr 2005 (UTC)

I feel I should add here that the latest beta of AmigaOS 4 has draggable screens :-) But yes, it's not really a Workbench feature.

/Johan Gill, not registered

Surely the Intuition and thus screen dragging and the concept of multiple screens is an inherent part of the AmigaOS. OS stands for Operating System and Intuition was intergral to the GUI of that Operating System. While the ability to see the screen below while dragging a screen was dependant on Amiga custom hardware, the actual concept was part of the OS. You can still drag screens with a chunky graphics card installed, and use the screen switching gadget, but you can not see the screen below (to the best of my knowledge). Prior to the use of the term AmigaOS, Kickstart refered to the OS required at preboot as held on chip or preboot disk, and Workbench the oeprating system as held on disk. The GUI was configured by elements of the Workbench disc so Workbench has to be considered part of the OS. McGonicle 12:12, 27 December 2005 (UTC)

[edit] Recoverable Ramdrive

I don't recall the recoverable ramdrive (RAD:) being dynamically sized. I know the plain ramdisk (RAM:) was, but not the recoverable. Am I just misremembering? -- I just checked, RAM: is dynamically sized, RAD: was of a fixed specified capacity. Dynamically-sized RAD: disks were available as add-ons (found some on aminet), but weren't included as stock.

That's correct. However, the first recoverable RAM disk ever made for the Amiga (the ASDG one) was dynamically sized.

Another cool Amiga trick was that you could boot from a recoverable RAM disk. Mirror Vax 18:04, 17 November 2005 (UTC)

[edit] Amiga OS 4.0 Question

I have been reading a little about this AmigaOS 4.0. Is it available to normal non-computer people like myself? Is it free? How can I try it out?

AmigaOS4.0 is not free. It only works on AmigaOne systems or Amiga systems equipped with a PPC accelerator card. As stated in the main article here.

[edit] Spelling error? Joilet vs. Juliet

"New CDFilesystem with Juliet and HFS support, DVDRW support"

Should this not be Joilet?

Yep - have fixed this. Mdwh 16:58, 26 February 2006 (UTC)

[edit] Standard "OS Stats" infobox for AmigaOS?

Most all other articles on particular operating systems that I have explored include a right-hand infobox with standard infomation about the OS (developer, OS family, closed/open source, latest stable release, etc). Check out Mac OS, OS/2, Windows CE, etc. for examples.

Maybe I will get to this, but thought I would put up a proposal in case someone already knowledgable about AmigaOs or those other OS-info boxes could whip it out.

[edit] Technical and stylistic improvements

I made some technical corrections to the overview. Amiga libraries are dynamically loaded on demand and relocated - static libraries are "link libraries" and are not often found on users' machines, only developers' machines. They're not dynamically linked (SAS/C had an option to automatically work out the functions/bases you needed and open libraries as necessary, but this was not inherently part of LoadSeg()), but they are dynamically loaded.

I added an infobox.

What the article needs, imho, is a good overview that describes the main components (kickstart, exec, amigados, intuition, workbench, autoconfig), but without resorting to the deeply technical facts (which i renamed "technical overview"). It can then point down the page to explain the concepts of libraries, devices, handlers, amigados naming conventions and so on. I wanted to trim the amigados/handlers section because there's too much, but it's all great stuff and very relevant to AmigaOS.

[edit] Update to AmigaOS 4

Please see OS comaprison talk pageand add some more on AmigaOS4 here (last realise date,screenshot, feautures etc.). Great page! --Rastavox 11:05, 4 May 2006 (UTC)

[edit] exec.library, microkernel, etc.

I decided to undo (not quite revert) an edit made by Chris Chittleborough, because it, in effect, stated that exec.library is a microkernel. I believe this is not strictly correct. The old statement, "can be considered microkernel as well as a library" is probably not strictly correct in everyone's opinion either, but IMHO at least it comes closer.

Anyway. Are there any stong opinions on this either way? exec.library obviously is microkernel-inspired, and performs message passing, the mark of a microkernel. At the same time, though, I'm not sure you could say that AmigaOS really is MK-based, with the direct calling into various libraries, etc. But I'm no expert.

I believe the official documentation (RKRM:Autodocs? Libraries?) in at least one place called the operating system microkernel-like and nearly realtime, or something similar. Now people are calling it microkernel and realtime, without any real justification that I can see. And this seems like the best place to finally resolve the issue, so let's do that. -- magetoo 22:17, 21 May 2006 (UTC)

Please see my talkpage; I've discussed that a little there with CWC, the guy who originally added the microkernel mention. I did the edit that changed "is a microkernel" into "can be considered a microkernel" (or what the exact wordings were). LjL 23:46, 21 May 2006 (UTC)

To add my own views to this debate, exec.library can, for all intents and purposes, be considered a microkernel. Why is there debate? Because in operating systems, even pre-MMU pre-memory protection pre-virtual memory ones, there is a distinction is between "user mode" and "supervisor mode". The kernel derives its "authority" by forcing the system into supervisor mode to run any of the "kernel". Exec eschews this mechanism. Instead of using the INT instruction (like MS-DOS) or the TRAP instruction (GEM-DOS and SunOS), you just point at a list of functions and jump to the one you want. If they need supervisor mode, they'll use it, otherwise they wont. Any Amiga program can use the Supervisor(), SuperState() or AddIntServer() functions of exec to run arbitrary code in what's traditionally considered "kernel" mode, meanwhile exec very rarely runs in this mode itself, as it doesn't need it. However, the design of exec is entirely a microkernel design, with exec only covering the very basic system management. It leaves all else (device driving, maths, I/O devices, file systems and access, timers, etc.) to other libraries, devices and resources, which either run as seperate processes and talk via message passing, or as libraries which run under the context of the caller.

Executive summary: exec is certainly a "microkernel", we're just not sure if it's a "kernel". 195.173.23.111 14:41, 22 May 2006 (UTC)

I couldn't have said it better. -- [User:LjL|LjL]

FYI, there are no mentions of "kernel" (except "ROM Kernel Reference Manual"s) or "realtime" in v40 autodocs, v37 RKRM Libraries and RKRM Devices. 195.173.23.111 15:02, 22 May 2006 (UTC)

Yeah, it's quite "microkernel-ish" but not very "macrokernel-ish". I think that section is perfectably acceptable as it stands (and better than either of my edits!). I don't know of any authoritative statements about whether exec.library is or is not a microkernel. Until such a statement turns up, "can be considered a microkernel" is true, informative and encyclopedic. Deciding for ourselves would be verging on Wikipedia:Original Research.

Cheers, CWC(talk) 15:32, 22 May 2006 (UTC)

Here's something interesting I just found: Linus Torvalds has written that AmigaOS

was not a microkernel. Exactly because it lacked the one thing that makes a microkernel: separate access spaces.

To understand what he is really saying here, you will need to read this comment to find out what he means by "access spaces". Linus's point, as I understand it, is that (1) AmigaOS differs from "real" microkernel systems by having only a single, shared access/address space and (2) that makes AmigaOS radically different. For example, Amiga tasks can exchange messages containing arbitrary pointers, whereas true microkernels have to serialize data and/or provide object references of some kind. (See Solaris doors for an excellent example; they're powerful, fast and (IMHO) much harder than Exec messages to program with.)

Linus is using a particular definition of Microkernel here, which not everyone would agree with, so I don't think we should change the article's description of exec.library. In fact, I would say that Linus has just agreed with the article as it stands. Cheers, CWC(talk) 18:54, 15 July 2006 (UTC)

Linus is absolutely correct. I don't see any way that Exec can be considered a microkernel. The features mentioned by some people above are shared by virtually all operating systems. What operating systems are not internally modular? What multitasking operating systems don't provide message passing or use threads for some things?

I guess a dog can be considered a cat, by someone who doesn't know what a dog is. But that fact is probably not worth mentioning. Mirror Vax 08:19, 16 July 2006 (UTC)

Linus's definition of microkernel involves multiple address spaces and memory protection, which is something the 68000 didn't even support. In this case, it's just his (wrong, IMHO) opinion. On modern CPUs, an MMU comes for free, which is why modern microkernels also implement memory protection. Does AmigaOS manage its address spaces? Yes, it manages its singular address space with AllocMem() and FreeMem(). Does it need to provide memory protection to be a microkernel? No. Linus presumes that memory protection is a necessary feature of any kernel, microkernel or otherwise. With that attitude, there were no operating systems on microcomputers until the 1990s (which I would disagree with - TOS, MS-DOS, MacOS and AmigaOS were all bona-fide OSes, despide the lack of virtual memory support)

Lots of operating systems aren't modular, for example MS-DOS. You call INT 21h, you get one thing. You call INT 15h, you get something entirely different. Internally, the entire operating system is one monolith hiding behind the INT call, and each section of the OS can look up the private state of other parts. This is not modular. By comparison, AmigaOS and MacOS were modular - you had to access different components, which couldn't see into the innards of other components.

AmigaOS was also entirely reentrant, whereas quite a lot of problems in UNIX stem from the lack of reentrancy. AmigaOS did not have the kernel-user distinction and the design laziness that comes with that basic principle. Operating systems with a kernel-user privilege mechanism often have a big sprawling non-reentrant mess in kernel-land, only made threadsafe by a global kernel semaphore - have you heard of the Big Kernel Lock (BKL) in Linux? AmigaOS didn't have this problem, it used semaphores and queues to service requests whereever possible. On occasion, it was used via Forbid() and Disable() to stop task-switching and interrupts, respectively, but only for microsecond-long periods of time defined in the documentation, because of the perceptible lack of interactivety and missed interrupts that could arise. AmigaDOS was completely seperate from the filesystem, which in turn was completely seperate from block device drivers. On occasion, I've seen filesystems (such as ARCHandler, the filesystem that treats archive files as directories) hang, and trying to access them hangs the current process, but opening a new process and going to a different filesystem is not a problem.

Anyway, if you don't realise how non-modular some operating systems are, and how little they use message passing, then perhaps you won't realise how distinctive the AmigaOS design was from its contemporaries. 195.173.23.111 11:20, 7 September 2006 (UTC)

In fact, if you read Linus's argument, he's disputing the claim that "microkernels are simpler", by stating that microkernels would be forced to provide finer granularity memory protection than a monolithic kernel and thus would be more complex than a monolithic kernel - this is a strawman argument. AmigaOS also has this "feature" (lack of memory protection) of monolithic kernels, it just doesn't need to jump into "kernel mode" to get it. 195.173.23.111 10:47, 8 September 2006 (UTC)

195.173.23.111 is correct. The Exec is a microkernel in the sense of the term as used at that time, and in the strict sense of the word. Since then, microkernel has gained some additional semantic baggage in some people's minds, mostly because the term has largely been used in reference to machines with MMU/VM support and as an alternative to large monolithic kernels on such machines. Exec is based on one of the classic textbook microkernels, Xinu. It is similar in philosophy to Minix. See the Tanenbaum-Linux debates[1]

[edit] Future

User 68.36.192.168 (talk • contribs) (thanks!) has added some interesting material under the heading "Future". Here's a copy (after I edited the last bit):

Since 2005, the AmigaOS has undergone rapid development, by a internet community of software developers & systems engineers who are dedicated to promoting the use of the OS. In many ways, due to the porting of common UNIX/Linux functionality, AmigaOS has become a new & extended type of UNIX, with new challenges & new potentials.

In 2006, the Amiga OS is uniquely poised to be ported to the Cell (microprocessor), the new CPU subsystem for the Sony Playstation 3, and IBM Blade Servers, which has been touted as the "New New CRAY" in supercomputing circles.

Individuals & corporations interested in bringing the AmigaOS & it's applications to Cell, should fully research the architecture (PowerPC, IBM Power, PowerPC 970), and should consider applying for compiler time on MareNostrum at the Barcelona Supercomputing Center, to speed development before the November 11, 2006 release of the Sony Playstation 3. Application guidelines can be found here.

Some thoughts:

1. We should provide sources for these statements.
2. Calling AmigaOS "a new & extended type of UNIX" is probably an overstatement. AFAIK, the unix emulators such as ixemul.library still don't fully support fork(2).
3. Has anyone started working on porting AmigaOS to the Cell? If so, can we have a URL? (That would be a really interesting project.)
4. The last paragraph is probably unencyclopedic.

Cheers, CWC(talk) 15:33, 22 May 2006 (UTC)

I removed it - for the reasons you give, and it seems unlikely to me to be true. If someone has a source for any of this, feel free to add it back. Mdwh 00:09, 23 May 2006 (UTC)

[edit] Kickstart disks

The current article states 'subsequent Amiga models all used ROM chips' [following the A1000] in relation to Kickstart.

However, I remember that the Amiga 3000 also required such a Kickstart disk. Can anyone confirm? Thanks!

Most A3000s used ROMs, but some (like mine) had a small "Super Kickstart" in ROM which read Kickstart from floppy or hard disk. (Super Kickstart was based on AmigaOS 1.4, which never appeared anywhere else.) IIRC, only the machines manufactured in Europe had "Super Kickstart", but I may well be wrong on that detail. I do know that I never got my machine to boot a v3.x AmigaOS :=(. Cheers, CWC(talk) 02:41, 6 August 2006 (UTC)

[edit] Freeing memory

(This is relevant to a different Wikipedia article). I have the statement in front of me that, when a program terminates in AmigaOS, memory assigned by the program is not freed, and that it is therefore vital for the program to release all memory that it asked for, otherwise it is permanently "leaked". Is this the case? Notinasnaid 10:48, 23 October 2006 (UTC)

Memory that is not freed before termination of a program in the Amiga OS is leaked (assuming it was supposed to be freed - in some cases a program may have allocated structures and attached them to system objects, such as a device node). One of the most common modes of testing on the Amiga was checking free memory after program exit; there were many tools that automated that. Normal behavior of a program was to free all memory, and all malloc'd memory was automatically freed via exit-time hooks. (I.e. leaking memory typically only happened to memory obtained via AllocMem() and the like.) jesup 12:02, 23 October 2006 (UTC)

Indeed. AmigaOS does little to no resource tracking in order to save the memory overhead that it costs to include tracking. There was also a third-party program that patched many allocate/free resource functions (e.g. AllocMem/FreeMem, OpenWindow/CloseWindow) and added resource tracking to them, however this would break any software that deliberately allocate memory then exited, for example programs which installed patches on system functions. Programs assume the responsibility for freeing all allocated memory. The standard C library implementation in most Amiga C compilers used an onexit handler that freed any memory allocated with the malloc() implementation, but if the program crashed or the AmigaOS memory allocation routines were called directly, memory allocations were not freed. Other languages had varying degrees of support for tracking memory, usually (like C) only if you used the language-specific memory allocators. 195.173.23.111 13:50, 24 October 2006 (UTC)

Thank you for your replies. The reason for the question relates to a discussion I've been having on memory leak. I'm going to post a question which is very subjective, but maybe there's a consensus. The article includes "In modern operating systems, normal memory used by an application is released when the application terminates". Part of the debate is over whether this is really true, and whether it should say "In some operating systems...". The leading question is: is AmigaOS a "modern operating system"? A supplementary dispute, where it says "The application assumes that the request for memory has succeeded, and continues on this basis. This will typically result in an access violation but in some cases may result in damaging information belonging to this or (in primitive systems) some other application." Should this have "some systems" in place of "primitive systems"? Thanks in advance. Notinasnaid 19:44, 24 October 2006 (UTC)

The amiga would be included in "modern operating systems", and it does release "normal memory" (i.e. malloced) when the application ends. Program crashes on an Amiga do not release memory, so you could say it leaks on process crash. And a program that uses things like OpenFile() instead of open() will leak a filehandle (and some memory) if the program calls exit() without closing the file. As for your second question, the answer would be "some systems" - many "modern" embedded systems (including running unix variants like uclinux) do not have memory protection, and can read (and possibly write) structures using NULL as a pointer without an access violation. Personally, I HATE programs that don't check malloc (or any other calls) for failure. Good programming practice on the Amiga (due to the lack of VM) was to test programs and the OS against random memory allocation failures to see if they recovered cleanly or not. All allocations (and all system calls, etc) should be checked for failure and proper rollback/error-recovery done, unlike the typical Unix/Windows/etc method of "if (NULL == (foo = malloc(N)) exit(1);" or equivalent. But that's another rant.... :-) jesup 19:59, 24 October 2006 (UTC)

I would say "in most operating systems". Only (1970s/80s/early 90s) microcomputer operating systems and some embedded systems, especially those running on hardware without an MMU, would have no resource tracking. The number of such operating systems is quite small. I wouldn't use "modern", because almost all "old" (since late 1960s) operating systems running on expensive minicomputers or mainframes definitely had resource tracking, and some modern embedded operating systems don't have resource tracking. 195.173.23.111 13:21, 25 October 2006 (UTC)