Feelin has been ported to AROS. Feelin is an object-oriented system for AmigaOS as described on their website. It provides a GUI toolkit that looks polished (screenshot). The AROS Archives is up and ready to accept your files. This web site will be the main repository for all AROS software.
That does look nice. I will have to load it up and try it out on a project of mine that I started working on, yet another media player.
I am still fascinated with Amiga after all these years. I wish AROS all the luck.
I don’t code so I wouldn’t know, but is it resource friendly?
Looks great!
Seems that people behind AROS have decided to show muscles. I am very happy that they decided to do this. May be this is time for me to code again for a platform I programmed for the last time 10 years ago. Viva Amiga !!
Aros would be so cool if only they had enough devs. There is just so much that needs to be done and they just plain don’t have enough people.
It’s not that AROS doesn’t have enough devs, it’s that the devs don’t have enough time. AROS is something (most) devs do in their spare time. Other than some small bounties, no one is paying AROS devs to work on AROS. Most are just old-time Amiga programmers who enjoy working on code in their spare time.
I don’t see any reference to AROS on Feelin’s website. Only AmigaOS is mentioned so it seems the binary release would be for Amiga hardware. Does it compile for AROS or is there a modified version somewhere else?
The screenshot you saw WAS running on AROS! the website of Feelin is just not updated with the AROS binary yet (and yes Feelin already runs on AmigaOS3.x).
That would be nice.
Yes there is a TCP stack now and a handfull of drivers.
Well if I were rich I would sponcer the devlopent of Aros full time. Problem is I have to work for a living just like everyone else. Aros would make a cool desktop OS.
I don’t like it at all, it looks rubbish to me. What’s special about it ? I’m not trolling, just genuinely interested is why someone would want to use it over the “official” gui toolkit for AROS that I thought looked better.
Times change… Have you ever heard about XML applications ? Feelin is somehow what MUI should have been. And if you don’t like the look of it 1) it’s fully customizable. 2) I await your guidance to make it as you whish.
Respect.
Mr. Gofromiel wrote:
> Have you ever heard about XML applications ?
> Feelin is somehow what MUI should have been.
> And if you don’t like the look of it
> 1) it’s fully customizable.
> 2) I await your guidance to make it as you whish.
Well, if Feelin is fully XML compliant, I wonder if its classes could be used as engine to render XML-XHTML-HTML pages.
Is it possible to have as standard feature in Feelin a minimal browser as utility?
It should be obviously bundled with its sources, in order to let it be expanded by users who are also programmers and acquire new functions.
Sure, maybe you had not thinking about it, but with a little browser program based on Feelin, you could win the “Amizilla” bounty prize of 8500 US$ that is now open to any functioning Amiga project browser related.
Ciao,
Raffaele
It is always good to see a lone programmer come up with something as slick as that. This Feelin looks really nice and thought-out.
Please, are you going to introduce the same toolkit chaos that Linux now is struggeling so hard to rid itself of? A desktop that looks like a mish-mash of several OSes in one? 🙂
I don’t get it.
With so many choices of very good open-source toolkits like Qt, why the amiga community insist on using outdated stuff like MUI, or reinventing the wheel like feelin, instead of porting some of the modern toolkits and be done with it ?
The only reason I can think of is that the amiga community suffers from a bad case of “not invented here”, and as far as I remember when I was part of that community, they always prefer some half-assed closed source solution originating from the amiga community rather than some well built and complete open-source solution.
That’s why, for instance, they don’t have anything like a remotely decent web browser.
Of course, if they are happy that way, it’s not my problem. But still, it barely makes sense.
Mr. Morb wrote:
>I don’t get it.
>
> With so many choices of very good open-source toolkits like Qt,
> why the amiga community insist on > using outdated stuff like MUI,
> or reinventing the wheel like feelin, instead of porting some of the modern toolkits
> and be done with it ?
There are many problems in porting other toolkits.
1) Amiga graphic engine systems deal mainly on the necessity for AmigaOS to use fixed libraries.
For example:
Workbench.library, Gadtools.library Intuition.library
These described standard Amiga interface; arbitrates collision of sprites, icons and mouse; describe how OS must move windows and redraw them; deal with icons (Amiga has 5 different icons types: programs, projects, drawers, disks and special icon type trashcan); these libraries also describe gadgets and their look&feel appearance, etcetera).
Toolkit GUI’s from other OSes must be translated to accomplish Amiga unique system of dealing with libraries. That requires *enormous* effort.
We must had had dealing with new library object files like GTK.library, Cairo.library, Qt Library, etc., etc.
2) Amiga is not Posix complaint and has not proper “fork()” function. Instead of it it uses sort of “vfork()” (if I remember well).
This fact requires that alien toolkits, before they could be ported on Amiga, they need a vaste process of rewriting. Another *huge* effort for the coders.
Actually there are well functioning O.O. systems like MUI or Reaction, and there is a work-in-progress project to build a wrapper for GTK main functions.
For example to port Firefox on Amiga only 77 funcions of GTK are required, from a total of more than 2500 functions which GTK actually counts.
BUT… to port vaste majority of programs using GTK, a very extended subset of GTK functions must first be implemented into Amiga.
But this is not in any way involved with Feelin.
You missed the point that Feelin for Amiga is something completely NEW.
Also it is not only a rewriting of MUI. BUT it could be considered a MUI better than MUI itself…
To quote from its own site these are some of the functions Feelin has:
It supports XML extensively (a very strong point of interest actually), it has a memory management of its own and non centralized ID allocation system, a crash-free object invokation mecanism, even an advanced logging system… also it has an open and efficient preference system.
Feelin can creates objects as well as complete applications from XML sources. It has a beautiful and powerful GUI (color, font and background inheritance, window border customization, HTML markup recognition).
More over, Feelin is incredibly light (low memory usage and cpu load).
Feelin it is not involved with standard BOOPSI for Amiga. It was written from scratch. No legacy anymore.
I think that an O.O. system like Feelin is strongly needed at this moment into Amiga, because it has noteworthy features, that even GUI toolikts into other OSes lacks of.
> The only reason I can think of is that the amiga community suffers from a bad case
> of “not invented here”, and
> as far as I remember when I was part of that community,
> they always prefer some half-assed closed source solution
> originating from the amiga community rather than some
> well built and complete open-source solution.
As I explained before, that is not the reason, and I hope my explanations are almost clear.
> That’s why, for instance, they don’t have anything
> like a remotely decent web browser.
Development into Amiga is rather diminished. Lots of projects are one-man-made only.
That is why the three (*3* of them) existing Amiga Browsers, and the two (*2* of them) are still in progress and updated from time to time, or even abandoned (Voyager Amiga Browser).
Also you must remember the fact that only since last 2 or 3 years internet begun to change and trasforming into CSS based reality.
Again its development seems is now evolving into XHTML direction.
> Of course, if they are happy that way, it’s not my problem.
> But still, it barely makes sense.
Well, seems that you are mostly uninformed of Amiga situation, programming scene, problems of portings from alien systems… so I don’t feel to accuse you for any the things you wrote.
From your point of view these thoughts are correct, but I explained you why your considerations don’t match situation.
Ciao,
Raffaele
Excuse me. There are two typos in this part of my statements here is complete discussion:
Development into Amiga is rather diminished. Lots of projects are one-man-made only.
That is why the three (*3* of them) existing Amiga Browsers, and the two (*2* of them) ->NEW BROWSERS IN DEVELOPMENT<- are still in progress and updated from time to time, or even abandoned (Voyager Amiga Browser).
Also you must remember the fact that only since last 2 or 3 years internet begun to change and trasforming into CSS based reality.
Again its development seems is now evolving into XHTML direction.
[EDIT]
Until when these changes into internet took place, the existing browsers for Amiga were barely sufficient to navigate internet, and Amiga users were satisfied with them.
Now certainly it is the moment for Amiga to evolve and embrace new style guidelines by CSS and new standards like XHTML.
[EDIT END]
I apologize.
Ciao,
Raffaele
”
Workbench.library, Gadtools.library Intuition.library
These described standard Amiga interface; arbitrates collision of sprites, icons and mouse; describe how OS must move windows and redraw them; deal with icons (Amiga has 5 different icons types: programs, projects, drawers, disks and special icon type trashcan); these libraries also describe gadgets and their look&feel appearance, etcetera). “
Every Os has a native, specific API. Toolkits like Qt and GTK just wrap them to achieve portability. Wrapping the amigaos API is no different than wrapping xwindows or win32.
“Toolkit GUI’s from other OSes must be translated to accomplish Amiga unique system of dealing with libraries. That requires *enormous* effort.”
If you’re talking about the old amiga-style shared libraries versus dynamic linking shared libraries like every other OS use, then I agree that it’s a problem.
However, it would feel more like a missed opportunity for the current crop of amiga OSes, which were all rewritten from scratch, to move away from some outdated technical solutions toward more modern ones.
“Development into Amiga is rather diminished. Lots of projects are one-man-made only. “
And one man project can’t compete with equivalent open-source projects.
A web rendering engine is pretty much a standard component nowadays (as is a GUI toolkit), why not just port and maintain an open-source one and build a specific browers in the “amiga spirit” on top of that instead of maintaining an outdated, amiga-specific html renderer ?
“Well, seems that you are mostly uninformed of Amiga situation, programming scene, problems of portings from alien systems..”
Actually, until 4 years ago, I used to develop on amiga, and I was well aware of the various portability problems and such.
What surprises me is that it doesn’t seem to have evolved much since that time, despite the fact that people use new, rewritten from scratch versions of amigaos.
For instance, about the fact that fork still cannot be emulated… Don’t tell me that the current amigaos clones still rely on a shared adressing space for all processes ?
“Every Os has a native, specific API. Toolkits like Qt and GTK just wrap them to achieve portability. Wrapping the amigaos API is no different than wrapping xwindows or win32. ”
Instead of wrapping the OS-API to GTK we prefer to wrap GTK to MUI/zune. Thus, a GTL app becomes a MUI app.
Probably because AmigaOS lacks much of the functionallity required to get such a toolkit running (things like threads, sun/posix ipc, ..)
I think Qt would be just too heavy on the classic AmigaOS hardware. Remember, you are dealing with HW with even lower performance of some of today’s typical PDAs!
It is certainly possible and even useful, but why compromise on speed if native solutions like Feelin & MUI just fit better?
That said… AROS *does* run on modern hardware, so I agree, this would be a perfect opportunity to get an Amiga-like OS with all those portable OSS toolkits, and consequently get all the popular software, like Firefox etc…
“this would be a perfect opportunity to get an Amiga-like OS with all those portable OSS toolkits, and consequently get all the popular software, like Firefox etc…”
…and turn into yet another Unix clone? If you want to run Firefox on the popular toolkits, you don’t use AROS but start with Linux right away. I think the intention here is to build something different, and you don’t get that with ported software.
Yes, I agree with the poster. It does seem like the current Amiga users and developers prefers closed source solutions from within the community. Amiga land really has turned into “amish” in many ways – which is totally counter productive. The Amiga developers like to repell outside developers and chase away people who are interested in contributing if they don’t adhere to the Amiga morale.
Closed source? both Zune and Feelin that now AROS has are open source…..
That’s an improvement. I didn’t knew feelin was open-source. I knew that AROS is.
It’s still a reinvented wheel, though.
Reinventing the wheel you say? perhaps but on another hand it would probably be more work porting something from linux to AROS then writing something from scratch + Zune and Feelin are already useable so why not?.
Yes and no, it’d certainly be useful for easing porting, but it wouldn’t be very amiga-like. MUI was just a (rather nice) toolkit built on top of the basic Intuition BOOPSI system, and I’d guess from looking briefly at the web page that Feelin is simillarly structured.
Remember MUI was useable (though a bit slow) on a 7MHz 68000 and really quite useable on a 14MHz 68020… processors that are likely less powerful than even an oldish mobile phone (though the custom chipset helped a bit too).
And as to the previous comment, it’s not like the Amiga ever had just one toolkit (in fact, the original Intuition developer documentation positively encouraged you to do your own thing… though later documentation did introduce UI guidelines of sorts).
(And MORB huh? Mr Clicksaver himself…? *waves*
)
Yes and no, it’d certainly be useful for easing porting, but it wouldn’t be very amiga-like.
That’s exactly what I meant. What is “amiga-like” anyway ?
Remember MUI was useable (though a bit slow) on a 7MHz 68000 and really quite useable on a 14MHz 68020… processors that are likely less powerful than even an oldish mobile phone (though the custom chipset helped a bit too).
Yes, but who still use that kind of hardware nowadays ?
MUI was just a (rather nice) toolkit built on top of the basic Intuition BOOPSI system, and I’d guess from looking briefly at the web page that Feelin is simillarly structured.
BOOPSI served a purpose at a time where most people were coding in C and there were no good object oriented languages available on the platform. Still, it was unwieldy and not that efficient, with all those switch/case statements everywhere to route method calls.
“(And MORB huh? Mr Clicksaver himself…? *waves*
)”
God damnit. By the way, when I wrote that thing, I was still intoxicated with “the amiga way of coding”, hence why it was in C with a crappy boopsi/mui-like user interface :p
I’m not sure if there are any good OOP languages on the Amiga platform even now… (and no, C++ is a half-baked OOP language before anyone asks
). And the switch statements could be a pain, which is why most toolkits implemented on top of BOOPSI use other mechanisms (such as callbacks).
Still, support for other toolkits is never a bad thing, but the Amiga is pretty much a hobby platform these days for most people, even if there are still features I miss in more mainstream OSs.
(And yes, I’d noticed PUL was a bit MUI-like having had to poke CS after it was broken by 15.9, though thankfully that was just a changed DLL name. At least you’d left the source behind when you moved on though…
)
“I’m not sure if there are any good OOP languages on the Amiga platform even now… (and no, C++ is a half-baked OOP language before anyone asks
)”
I beg to disagree. And anyway, in terms of ease to code with, it’s still light years beyond doing OO by hand in C…
“And the switch statements could be a pain, which is why most toolkits implemented on top of BOOPSI use other mechanisms (such as callbacks)”
Callbacks ? Talk about unwieldy.
C++ better than C for OOP? Well, duh, and C++ is a useful tool if a bit bloated feeling these days (I preferred it circa v1.2, though SEH is a nice addition…) But OOP isn’t just about the language, and the Amiga was more OOP than many OSs (though the GUI wasn’t oddly enough).
There are however more productive languages out there than C or C++ (though perhaps few as simple and elegant).
As to implementing an event mechanism, I can’t off hand think of ways of doing this that don’t rely on either a single event handler managing a message queue (with the switch style logic that implies) or seperate handlers managed via callbacks… is there another mechanism I’m not thinking of?
“But OOP isn’t just about the language, and the Amiga was more OOP than many OSs (though the GUI wasn’t oddly enough)”
Are we talking about the same AmigaOS ? The one I remember had a very straightforward, but undoubtedly procedural API.
“As to implementing an event mechanism, I can’t off hand think of ways of doing this that don’t rely on either a single event handler managing a message queue (with the switch style logic that implies) or seperate handlers managed via callbacks… is there another mechanism I’m not thinking of?”
No, but what I was getting at is that a C-based system relying on explicitely defined callback isn’t the sexiest thing I can imagine.
Take Qt, for instance. Event handlers are called slots. They are basically callbacks. However, to define them, you merely have to label them as being slots (then moc takes care of the details of generating the code to register them), and since they are member functions, they can access member variables from the instance they belong to directly, and in a natural way.
A C based callback system would make you obtain a pointer to some user-defined data structure to access your data, which you have to explicitely dereference everytime.
And if you want to inherit a widget class from another, it would start getting pretty messy.
I just got started with AROS a few days ago, and I’m excited about the launch of the software archive. However, I’m a bit confused about how software downloads are going to work since, despite all my best efforts to prove myself wrong, AROS as an OS seems to be solely LiveCD right now. Am I wrong about this, or is this repository geared for just the Linux-AROS users?
You got it a bit wrong there =) its possible to install AROS native already (a bit of work innvolved) you should join the aros-exec.org forum and ask for help! the guys there are sure to help you! or use the irc channel #aros on irc.freenode.net
Exec was highly OOP in design (don’t confuse OOP methedologies with OOP languages… you can do OOP in C just fine, though other languages make it a lot easier and provide more rigour).
So we’re talking about tools and APIs that hide the reality? Fair enough, that’s a desirable goal, and there’s no doubt the hobby and even commercial Amiga OSs have a ways to go in such areas (and in many others).
Memory protection seems to be one area where progress has been rather slow despite this being a mandatory feature of any modern OS. It’d likely mean many old amiga apps would break but they could be flagged as such and run in a shared sandbox I’m sure…
At the end of the day, these are never going to be more than hobby OSs anyway (however much we might occasinally wish otherwise), so there’s little harm letting them do what they want in the way they want.
Window’s and UNIX-derived systems rule the roost (much as I dislike both), but having other options to at least play with is always welcome.
“Exec was highly OOP in design (don’t confuse OOP methedologies with OOP languages… you can do OOP in C just fine, though other languages make it a lot easier and provide more rigour).”
Exec ? OOP ? If you’re going to call OOP anything where you can group together functions related to the same data structure, then about everything is OOP.
What people usually call OOP is usually a more formal and advanced application of this pattern involving inheritance, encapsulation, etc.
Besides, the source of exec 3.1 (that used to, and maybe is still floating around) looks nothing like OOP code. It’s rather an assembly mess of spaghetti code peppered with various hacks accumulated over the years to work around various hardware bugs and quirks.
@ Morb:
>>>
For instance, about the fact that fork still cannot be emulated…
>>>
Fork IS emulated but it is not native AFAIK.
>>>
Don’t tell me that the current amigaos clones still rely on a shared adressing space for all processes ?
>>>
Fork() works strange on AmigaOS due to the way it handles processes and how they creates child-processes in a shared addressing space if I remember well. Programmers who has unpolite behaviour of handle computer memory could create serious problems. Don’t ask me more because I am not a programmer.
Regarding how new AmigaOSes and clones deals with memory:
Actually MorphOS deals with different BOXES in which processes or entire OSes could run and in case of crash they crash only their box…
…But most part of actual MorphOS drivers to control the hardware are loaded into the Amiga-API compatibility box. If Amiga box crashes, it crashes entire computer.
For more details you must ask to experts of MOS.
Regarding AOS4 it has a partial memory protection, but I don’t know how it works…
And obviously the protection is only partial, because AOS must grant retro-compatibility with the existing old Amiga software, at this stage of existence, to allow users to access a vaste number of programs.
(And old Amiga software has all problems of addressing legacies as running on old Amiga systems.)
———-
Infos regarding Amiga OOP for those who care, and for persons involved into the other discussion (OOP).
———-
Amiga has built into it BOOPSI system that is “Basic Object Oriented Programming System for Intuition”. It is a O.O. system well described and used into old docs and autodocs for Amiga SDKits.
Sure it is a very powerful help to program Amiga in OO.
To program Amiga OO style, BOOPSI system could be used even with C and C++ if programmers follow AmigaOS guidelines.
GNU C++ outputs good Amiga and MorphOS programs, but no actual OOP language currently on the scene has proper support for Amiga Shared libraries.
If I remember well there are also languages for Amiga which deal strictly with O.O. programming, such as Oberon language, but it is very, very old.
And HUM… there is also Amiga E language, small but powerful.
Also, many amiga resources, infos, and help for programming Amiga (even OOP style) are on the web, and are maintained by associations, clubs, big Amiga sites, and enthusiasts. Every person who wants to program Amiga OO should consider to read these pages.
Infacts Amiga survived the demise of Commodore, because of internet and its capabilities to share resources and infos worldwide.
I remember for example a set of utilities, routines, procedures and functions built by an Amiga programmer to help program Amiga in OOP style opposite as to BOOPSI approach. But I am not a programmer so I never read it carefully.
It could be find here:
http://www.geocities.com/SiliconValley/Bridge/5737/Main/oop4a_e.htm…
it is called OOP4A (OOP for ALL).
ALSO…
Java for Amiga, is currently in development. We all must still wait a bit to use it properly, because it is in its early alpha stage.
Well, obvioulsy I think that Java due of its nature has really a very OOP approach.
———-
About Feelin situation which is striclty tied with the thread topics:
Feelin actually has a very different approach to OO, because it has its own method to implement objects and it is written from scratch, without dealing with BOOPSI.
I think it is a good thing, because it doubles methods of Amiga to handle Objects.
Regarding objects and the way to handle data streams as objects it exists also project Reggae for MorphOS.
http://teleinfo.pb.bialystok.pl/~krashan/software/reggae/
A very new approach to deal with objects into Amiga. Very, very interesting and promising.
———-
@ Cheeseballoon and AROS
———-
Yes, AROS could be also installed on HD, but be careful when you launch this procedure, because it will destroy all informations stored on the HD.
So use a blank HD (even old little HDDs are good, because Amiga-like OSes are very small), or you will lose all your data.
I don’t know if dual installation side by side with Windows and MAINLY ->fault proof<- has been implemented, as long as I don’t know if AROS Team realized “dual boot” procedure using portings of GRUB and LiLo.
So at the moment sure it is safe BETTER to use LiveCD only.
Read carefully docs to install AROS even on an old little HD if you want it, and stay tuned for further development.
For the record, I do know what BOOPSI is and how it works. I did write C code directly at the BOOPSI level a long time ago, before MUI existed. I didn’t find it a pleasant experience.
“To program Amiga OO style, BOOPSI system could be used even with C and C++ if programmers follow AmigaOS guidelines.”
Yeah. The question, is who’d be mascochist enough to do it. It’s unwieldy, inefficient, and makes for hard to read code. With C++, most of things, like which function to call and such are resolved at compilation time.
BOOPSI, by contrast, adds a systematic and most of the time superfluous runtime overhead when you call a method.
Also, object oriented languages are designed to make OO code natural to write and readable. Using BOOPSI is bound to defeat that.
As for that OOP4A thing, I think that I could alter slightly an old saying: “Those who don’t understand C++ are condemned to reinvent it, poorly.”
Why would OO need to be implemented at runtime anyway ? What’s wrong with compile-time OOP (a la C++) ?
I don’t think that commodore’s engineers would have created BOOPSI if good C++ compilers were available on the platform at the time.
By the way, BOOPSI was an incomplete system. Their original plans were basically something MUI-Like, but because they lacked time and development resources, it wasn’t really usable. There was a crude object-oriented programming framework, the very beginning of a GUI toolkit, and that was it.
Gadtools is something they slapped quickly on top of it, exposing a plain, non-OO style api, because they didn’t have the time to flesh out the basic BOOPSI toolkit.
“Fork() works strange on AmigaOS due to the way it handles processes and how they creates child-processes in a shared addressing space if I remember well. Programmers who has unpolite behaviour of handle computer memory could create serious problems. Don’t ask me more because I am not a programmer.
Regarding how new AmigaOSes and clones deals with memory:
Actually MorphOS deals with different BOXES in which processes or entire OSes could run and in case of crash they crash only their box…
…But most part of actual MorphOS drivers to control the hardware are loaded into the Amiga-API compatibility box. If Amiga box crashes, it crashes entire computer. “
Ok, so what I gather from that is these new generation amigaoses are still not able to provide each process with their own adressing space. This is the very reason why fork can’t be done, and not, it’s not the fault of the application programmers as “impolite memory usage” implies, it’s definately a lacking memory management implementation.
The only reason, if I recall properly, why this archaic address space sharing scheme was kept, was because the amigaos api relied on applications accessing some system data structures directly, in particular for inter-process communications (but exec is OOP, huh ?). The assumption that the adressing space was shared also lead many developers to do things that would be considered Bad nowadays, like passing around (between processes, even) pointers and ownership of stuff allocated on the heap (which was common for all processes).
I remember that the idea that most people were tossing around at the time was to sandbox the legacy api and apps using it in their dirty little shared adressing space, and have a new, proper api for the new apps. Apparently, it didn’t happen that way, I guess probably for the sake of porting legacy applications easily, and at the price of making difficult to run code developed for other OSes, effectively isolating amigaos as a weird, outsider os.
Of course, at stated above, it could be considered a hobby os, but it could have stayed an useful os instead.
“GNU C++ outputs good Amiga and MorphOS programs, but no actual OOP language currently on the scene has proper
support for Amiga Shared libraries.”
It’s the other way round. It’s the amiga shared libraries that don’t have proper support for a lot of things that compilers expect from shared libraries. Again, why no plan were made to switch to dynamic linking instead of the old “array of function pointers” stuff is something I don’t get, especially given how it makes leveraging open-source packages much more difficult.
Although I must say that it kind of go together with separating adress spaces, so I guess if you don’t do one, the other doesn’t really make sense.
Your OOP argument has wandered into the compile-time vs run-time arena, and there are pros and cons to both (and no clear answers). Provided the overhead isn’t too great, I’d prefer the additional flexibility that run-time brings, though if performance is key, then a compile-time approach is almost certain to be superior.
And as for Exec… well, clearly it couldn’t do true data encapsulation (and at the time, the overhead of trying to do so would have been too great anyway), but it did (as you say) functionally group procedures and data (what OOP calls methods and classes) and most significantly, it made heavy use of inheritance. This was far more OOP in methodology than much else available at the time (though not as OOP as some more recent systems to be sure).
However, I do agree with you that to a great extent, that’s all in the past and simply won’t work going forward. There’s no doubt that the way the Amiga does certain things will have to change if it’s to remain even slightly relevant.
A fresh start open source OS (AROS isn’t truely that as it grew out of efforts to clone AmigaOS 3.1) that builds on the Amiga feel where possible and extends it into more modern OS requirements would be nice to see, though I’m not holding my breath.
EXEC is not OOP in any way, functions and data structures are separated. Having a smaller structure as the header of a biggest one doesn’t make OOP. Where are the methods, where are the attributes ?
IMHO compile time OOP is far more flexible than run time OOP. Feelin resolves everything (methods, attributes and attributes values are defined with strings) at run time, and obviouly while running. Because each class is a shared library, they are loaded when needed and expunged when they are no longer needed.
The purpose of shared libraries is to have the lowest blue print on memory, because the code is only loaded once and shared between applications (compared to dynamic linking where each application have its own copy of a code). IMHO dynamic linking is just a big waste of memory. As far as I remember, it’s only used on Window. Am I right ? Linux have shared libraries as well as BeOS…
All classes have opaque Local Object Data, thus you cannot make any assumption about the contents of an object (and its class). More over, each class define the methods it implements with a table, which is also used the resolve their IDs. With Feelin, you can also create meta-class (class for classes).
Thanks to this features, classes can have major changes without loosing any compatibility, and most of all without having to recompile the entire system just because you have moved some members of your Local Object Data, or modified the size of it, or added / removed attributes or methods.
—-
Concerning the Amiga unprotected memory, I think it’s a very nice feature, not meant for uncarreful programmers 😉 What I like the best on the AmigaOS is its responsiveness, it has nothing in common ! And yes I love this old deprecated thing where everything is to do.
F*ck I made a mistake in my previous post, instead of “IMHO compile time OOP is far more flexible than run time OOP” I wanted to wrtie “IMHO compile time OOP is far less flexible than run time OOP”. This changes everything 😉
So, Exec has inheritance and polymorphism (SAS/C even allowed you to not have to use casts), but not encapsulation… 2 out of 3 ain’t bad
Building a C++ wrapper round Exec was easy enough (though the memory management got messy), and if you did that you could even get the encapsulation if you really wanted.
OOP is an approach to coding, no more, OOP languages just make the task easier and more robust.
I really like OOP GUI. It’s like I’m the father of planty little children. I set the rules and they play together 😉