OSNews

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.