How is OS4 ?

[Jambalah]

We do Amigas as a hobby, and as a love for something intangible from our youth. They are our "Rosebuds". So please. STFU. We get that you like flavor X over flavor Y. But iof someone is going to lay down money on a machine they want to hear the cool stuff they can do with that machine, not take the pepsi challenge.

+1 Absolutely agree

@Methuselas: nice video! Thanks!!

[itix]

@karlos

I was thinking more of the benefits of being able to change .so files independently of the applications that use them.

You can have this with libraries, too. Of course they have to used different name always.

Before anybody starts, the current implementation has been designed to allow linkage against different versions of a .so provided all of the symbols that the originally linked version provided still exist (older gcc implementations didn't do this very well and the whole shebang was reworked).

So, other than saving disk space, you also get to be able to replace your regular libvorbis.so with an altivec tuned one perhaps. Or at least that's the theory.

But is this different to libraries...? I am developing SDL for MorphOS and when I am trying new AltiVec optimization I only replace old powersdl.library in LIBS: and try different SDL games with it.

The current OS4 shared object implementation limitation is that .so files are not opened and shared in memory the way .library files are. Whether that remains the case in future versions remains to be seen.

I havent investigated this topic very much but to my understanding to .so object sharing can not work in a shared address space model. The problem is, as I see it, relocating data sections.

[Karlos]

@karlos

You can have this with libraries, too. Of course they have to used different name always.

The accepted practise for .so files on other OS is to use version-based names and symlinks.

supposing you had a library "mystuff" which was version 1, revision 0, you'd generally call it:

libmystuff.so.1.0

Applications which absolutely must have this version/revision (and depending on a specific revision is bad practise anyway) would link against it directly. Thanks to the naming convention, you can have other versions/revisions installed concurrently. Applications which only depend on the major version would use

libmystuff.so.1

where this is usually a symlink to the actual file which could be any revision number. A library is considered a revision change when none of it's originally exported symbols change. Any changes to the originally exported symbols (or major changes to the behaviour of them) count as a version change.

Applications that actually don't require any specific library version would link against

libmystuff.so

which again is usually a symlink to a specific version/revision (most often the latest one).

But is this different to libraries...? I am developing SDL for MorphOS and when I am trying new AltiVec optimization I only replace old powersdl.library in LIBS: and try different SDL games with it.

It's different to libraries in that you can have multiple concurrent versions/revisions of the library. The AmigaOS method of opening libraries is based on passing the name and a version, where the version is stored in the library itself. You'll always get at least the version asked for (or failure to open otherwise), but possibly a newer one. You can't have V30 and V40 graphics.library available concurrently, for example. OTOH, with .so libraries, I can have libmystuff.2 and libmystuff.1 and applications that depend on each major version can happily coexist. Applications that don't depend on the specific version can all use the newest or oldest version at my choosing - it all depends on which particular specific version I point libmystuff.so at.

Now, you may say (and FWIW, I'd generally agree) that in reality, no newer version of a library should break what an older version does and thus being able to support concurrent versions shouldn't be needed. However, you know as well as I do, that in practise, that often isn't how it pans out.

I havent investigated this topic very much but to my understanding to .so object sharing can not work in a shared address space model. The problem is, as I see it, relocating data sections.

Depends on the OS environment. Shared objects are ELF files at the end of the day and primarily coming from GNU, were designed with unix-like operating systems in mind. A lazy implementation of the linker/loader doesn't need to consider sharing the memory representation between processes because the OS almost certainly gives each process an entirely different address space. However, this does not mean the text (code) segment and data segments cannot be loaded separately by a not so lazy implementation. If the OS allows different processes to share read-only executable memory, it is possible to share that memory region between processes. Their individual memory maps may show that region at different places but the physical address will be the same. Only the writeable data segment of the file will exist in different physical locations, one per process.

Now, for OS4, we have the problem you allude to. How do we create separate instances of the data section? Well, that remains to be seen. It may be that it's never implemented. Or it may be that it is possible if the data segment is always loaded in MEMF_VIRTUAL and some mmu trickery is used.

[Karlos]

Personally I think the biggest objection to .so files in OS4 are mostly aesthetic in the "Not Invented Here" sense. They are seen as an alien system that has been incorporated into the OS. I actually think that's rather silly seeing as we all decided long ago that ELF was a sensible format and gcc was to be our preferred compiler system. Shared objects are simply something useful that you can readily use from that combination, so why not?

[DAX]

@Crumb

OS4.1 is an early alpha? OS4 HW hasn't progressed much in 5 years, in fact Sam440 has been a step back compared to Peg2. Software wise there are many cosmetic changes but little deep changes (swap memory is one of the most noticeable although it was possible with 3rd party apps on OS3.x, we are still waiting auto stack enlargement and gfx core rewrite)

And you keep doing it again, neglecting any progress, of course you can  improve every part of the OS but if you don't add auto-stack enlargement  there was no progress!
But really, OS4.1Up2 has a ton of under the hood improvements and nothing went untouched from the early alphas you helped beta test.  
As for Sam, it was a beginning and mostly aimed at people spending thousands on towerized 1200/4000 only to get clunky systems very prone at breaking. It did a great job and the intended audience is happy, those that were searching for a performance beast were not.
I told you many times at AW that support for such initiatives would make newer HW possible,  and now they will make the 460EX which is more capable and aimed at a certain OS4 population. Power-users will get an X1000 (I will get it with tiny monthly payments, no need to be rich if you want it. I made them for my plasma, why not making them for something I really want, and costs far less?).

But please Crumb, say there won't be any new HW again (as you did last November) "it doesn't make commercial sense!" You bring luck!

I wonder if you have ever done any constructive post in any thread at amiga.org. It looks like you just have joined amiga.org to spread your blabbering and red troll propaganda.
It seems you live in a candy colored parallel reality. HW and SW side OS4 is 10 years in the past. Hyperion had the chance to design new APIs or at least port their OS to mainstream hardware so user base would not shrink to a few users. They failed.

Actually I live in a world where there is no Amiga or Amiga-like OS that justifies preaching about how cool and modern we are (as you seem to do with morphOS a marginally more mature OS that is still ridiculously obsolete), talk about living in candy worlds...

I see potential in AmigaOS as they are now free to form commercial partnerships and things are starting to move, while I believe the hermit crumb idea first announced to me at Pianeta Amiga by Guruman (in the sense that he told me there would be the MacMini port) didn't seem that hot to me.

But make no mistake, what I saw were 3 OS very far from todays standard, all have a long road to travel making those differences, quite frankly, highly laughable (and that is what I think every time I see you so adamantly writing about them, get real Crumb).

As for your clinging to the past read my lips: from the end of September 2009 (the day they signed the settlement) things have changed, you had a glimpse in the past 6 months, you will notice it even more in the next 12, and if that won't be enough, it will slap you in the face a little further down.

[DAX]

Edit.

[Fats]

Maybe this dicussion needs to be moved to a dev related forum.
As I'm one of the contributors to the AROS build system I am very interested in it though.

There's slightly more to C++ linkage than name mangling...
How, using nothing but a jsr style jump table library vector do you propose to enforce exception specifiers, for example? If a virtual function in your application throws an exception from within a library call (perfectly possible under the current libstdc++), is the amigaos shared library implementation expected to unwind the stack and properly invoke destructors for everything?

Isn't this problem orthogonal to linking ? Isn't it compile time and C++ ABI related ?
Of course you need to define a C++ ABI and you can't mix different ABIs in one program be they in static link libs, .so or .library files.

I'm not saying it's impossible to achieve but in the end, your library would likely end up deviating from amigaos shared library norms in order to offer the required features expected of the C++ standard library.

What is your definition of the norm. To me a .library has to following norm.
It has a Resident structure that points to the lib init code.
The init code adds the lib to the system list of libs.
The member of this list has a pointer to an LVO table.
3 slots have predefined meaning (OpenLib, CloseLib, ExpungeLib) and have to obey a certain calling convention.

And if you are going to deviate from the norm, then why bother? Static linking has no such problem. And really, that's all .so files do, except actual linking is deferred until runtime.

That the linking is not deferred to runtime is the reason I am a big proponent of amiga style shared libraries.

It's true that no compiler or other tool support exist ATM to do it.

This answers your own question and it's unlikely to change as long as gcc remains the compiler of choice.

It eventually will change (if I live long enough )

There's more than just the vtables and even the stuff above to worry about. Templating and RTTI present other interesting problems.

Again are these not part of the C++ ABI and orthogonal to the linking step. I have to admit that the intimate knowledge of the inside of C++ compilers is when the STL was still developed by SGI. I haven't seen anything at that time with templating that would make it incompatible with amiga shared libraries. I don't know how RTTI is implemented internally so I can't comment on that.

What I in the end envision is that for each shared library you would get two files; for example for libstdc++: libstdc++.a and libstdc++.library. Only the .a file would not contain any real code but stub code to call the right LVO in the .library but for the compiler/linker it would obey all ABI conventions.

So, for your suggestion to work, you need to first build a new compiler and then implement your own complete runtime and STL for it.

It isn't exactly a cakewalk. Who is going to bother?

I'm already doing the C library in the ABI V1 branch of AROS. So C++ and the STL will be a minor things once I come to it

greets,
Staf.

[Fats]

It's different to libraries in that you can have multiple concurrent versions/revisions of the library. The AmigaOS method of opening libraries is based on passing the name and a version, where the version is stored in the library itself. You'll always get at least the version asked for (or failure to open otherwise), but possibly a newer one. You can't have V30 and V40 graphics.library available concurrently, for example. OTOH, with .so libraries, I can have libmystuff.2 and libmystuff.1 and applications that depend on each major version can happily coexist.

With amiga shared libraries you can also achieve these things in the same .library. You can move a function that is incompatible to a new LVO number and keep an old compatible function at the old location. Programs compiled for the old version will get the right behaviour. Programs compiled with the new version will use the new function.

Another trick, that deviates more from the current norm is that you could return a different library base when the lib is opened with version 3 than opened with version 2 or 1.

Now, you may say (and FWIW, I'd generally agree) that in reality, no newer version of a library should break what an older version does and thus being able to support concurrent versions shouldn't be needed. However, you know as well as I do, that in practise, that often isn't how it pans out.

Yes, and that problem is not solved with the numbering, it is only helpful when people realise they make a backwards incompatible change. All the .2 versions of a library still has to be backwards compatible with the previous ones; some programs may even depend on some undocumented behavior. This is what oftentimes causes dependency hell.
 

Personally I think the biggest objection to .so files in OS4 are mostly aesthetic in the "Not Invented Here" sense. They are seen as an alien system that has been incorporated into the OS. I actually think that's rather silly seeing as we all decided long ago that ELF was a sensible format and gcc was to be our preferred compiler system. Shared objects are simply something useful that you can readily use from that combination, so why not?

Not for me. The fact that there is no runtime linking needed for amiga shared libraries is the reason for me to like it.
One of the comments on current AROS is that it is so responsive even on old hardware. One of the reasons for that is that you don't need runtime linking or virtual memory tricks like copy-on-write to be able to support shared libraries.

Side remark: ELF is used in AROS for .library files. There was a time I was also opposed to the ELF format until it was shown to me that you could keep binary executable files still relocatable and it doesn't force you to use virtual memory.

greets,
Staf.

[Karlos]

Yes, and that problem is not solved with the numbering, it is only helpful when people realise they make a backwards incompatible change. All the .2 versions of a library still has to be backwards compatible with the previous ones; some programs may even depend on some undocumented behavior. This is what oftentimes causes dependency hell.

Actually, no. It shouldn't break compatibility but there's no guarantee made that a major library version will be totally compatible with a previous major version, that's the part of the point. Look at some common linux shared libraries and you'll see version 1 or 0 but with fairly high revision numbers. These are libraries that have undergone various changes over time but (at least claim to) retain compatibility with much earlier revisions. Anything that doesn't change the library in a major way is just considered to be a revision, even if it adds many new functions. If any major documented component of the library is changed in a way that makes compatibility with the previous version questionable (or just non existent), a new major version number should be used.

There's no better example of totally borking compatibility between major versions than libkde* between KDE 3.5 and KDE4

-edit-

Not for me. The fact that there is no runtime linking needed for amiga shared libraries is the reason for me to like it.
One of the comments on current AROS is that it is so responsive even on old hardware. One of the reasons for that is that you don't need runtime linking or virtual memory tricks like copy-on-write to be able to support shared libraries.

Yes, there is latency but it is not really much of a problem. In my experience, on faster processors (read anything less than a decade old), linking a library takes significantly less time than loading the library from your physical disk.

And don't get me wrong, for procedural libraries, I always liked the classic amigaos shared library concept (I also rather like the OS4 interface concept too) as it's a simple and efficient mechanism.

However, when it comes to OOP stuff in C++, I prefer a shared object over static linking and that isn't going to change unless a viable alternative appears. It's all very well to discuss the feasibility of a C++ standard library as a .library, but it doesn't exist and so is somewhat academic for the time being.

[TheBilgeRat]

There's no better example of totally borking compatibility between major versions than libkde* between KDE 3.5 and KDE4

*shudder*

[Karlos]

*shudder*

I take it you like KDE 4 as much as I do :lol:

[TheBilgeRat]

I take it you like KDE 4 as much as I do :lol:

My WM in order would be:

Gnome
XFCE
OpenBox
Ratpoison
Cuneiform tablet
KDE 4:lol:

[pVC]

My WM in order would be:

Gnome
XFCE
OpenBox
Ratpoison
Cuneiform tablet
KDE 4:lol:

Urhg.. take Gnome to second last above KDE and then it's much better

[Karlos]

I don't mind gnome at all. Used to hate it, but, like a pestilent fungal infection, it grows on you.

[itix]

I guess you mean thread? Because this forum has been for all amiga and alternative amiga platforms for ages now.

But yeah i find it irritating as well, but i guess people who cheer for the "underdog" often act like that.
I have yet to see OS4 users posting in MOS threads just to spread FUD about the platform.

You surely dont read ANN (when it was alive) or amiga-news.de ;-)

[itix]

Personally I think the biggest objection to .so files in OS4 are mostly aesthetic in the "Not Invented Here" sense. They are seen as an alien system that has been incorporated into the OS. I actually think that's rather silly seeing as we all decided long ago that ELF was a sensible format and gcc was to be our preferred compiler system. Shared objects are simply something useful that you can readily use from that combination, so why not?

#?.so fits nicely with my GeekGadgets development environment but I dont see use on Amiga side.