How is OS4 ?

[Karlos]

And regarding timberwolf, there's nothing to swallow, really. An half-assed port of something that should only have required one month to port has nothing really appealing.

If that really were the case, how come nobody else has actually bothered in all the years the bounty was up?

OWB (even for OS4) probably required much more work, since the GUI had to be written from scratch, in addition to the usual layers like memory/thread/file/events/network/graphics... In timberwolf case, the whole UI is based on the graphics layer, which means it's just much less work to port.

It seems that the GUI is the most problematic part of the current alpha version. At present, I'm inclined to believe that WebKit might be easier to manage since it's no doubt a lot cleaner code wise than gecko is.

[Karlos]

Why not ? C++ function names are mangled and after that can be handled as C functions are handled now in amiga shared library.

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?

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. 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.

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.

Virtual methods are handled by a vtable and by the class constructor(s). The constructor with mangled name can be part of the shared library.

greets,
Staf.

There's more than just the vtables and even the stuff above to worry about. Templating and RTTI present other interesting problems as does thread concurrency. The latter isn't a problem for amiga libraries but remember the STL was not designed with concurrency in mind. GCC has gotten around this on platforms like linux by using a posix thread model in the compiler. In the end, you wouldn't just be creating the shared library, you'd have to reimplement the entire entire STL it provides as well.

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?

On the other hand, you can take an already tried and tested C++ standard library and statically link it to your application. Which is fine. However, with .so files you can defer that until runtime.

[Karlos]

As Red says: Since when, exactly?

The rest is covered quite nicely by Fab I think.

I think he meant when a thread is solely about OS4, not the forum.

[Karlos]

@karlos
Which saves disk space (precious resource these days ;-))

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

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 apparently on Amiga it is not possible make shared objects shared.

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. From a memory usage perspective, you've lost nothing compared to static linking in that regard.

Concurrency obviously is not problem on Amiga. Exceptions could probably work with some stub code. After all C++ libraries are always more or less compiler specific.

What I meant was that the C++ standard library is not designed with concurrency in mind because threading is not part of the C++ standard (yet). Of course, C++ is used in multithreaded systems so platform specific implementation of the library are are designed to be thread safe. The norm for GCC is to assume posix compliant threads.

But tools to extract manged C++ names are missing indeed. Maybe I should look into it some day...

[Karlos]

If he cannot say what he means, how can he mean what he says?

English might not be his first language? *shrug* As a quasi-geordie, I can almost sympathise.

[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?

[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.

[Karlos]

*shudder*

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

[Karlos]

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

[Karlos]

Anyway, to summarise regarding .so ...

Not all shared libraries can be readily implemented as .library files, at least without someone actually working out how to implement the required features and going on to produce a compiler that can produce the required output and at least porting the most obvious examples (libstdc++ et al) to that target.

So, OS4 decided to meet the problem halfway by supporting runtime linking of .so files as per the linux example (albeit without sharing code in memory at this time). We were already using the ELF specification that defines them as our preferred executable format so to me it seems quite a reasonable way to get started.

I'd like to see an improved .library system that could obviate the need for .so, but seeing as nobody has done it, it seems a pragmatic choice for the time being. It's better than static linking at least.

[Karlos]

It's funny because most of Amiga users I know prefer MorphOS to OS4.

Isn't that a completely subjective view? Most Amiga users I know aren't bothered about the "next gen" even one tiny bit. I'm somewhat the odd one out in even having an interest.

[Karlos]

PPC is not "dead end" overall, it's jut not used much in desktop machines.

As an embedded CPU, you'll find it in network hardware, signal processing and control systems all over the place.

[Karlos]

BTW, MorphOS has the most efficient AmigaOS gfx system and 32/64MB are enough for it.

You won't be saying that when the Doom 3 engine goes open source. Everybody will be wanting full OpenGL2 drivers and plenty of VRAM for textures, specular maps, normal maps etc.

[Karlos]

this thread has pretty much convinced me that:
 
A: Amiga is doomed.
B: I don't really want to have anything to do with either OS4 or Morph at this time.
C: The smaller the tribe, the more entrenched the factions.
D: NOTHING is "amiga" anymore. At this point, I wouldn't surprised if someone claimed that an A500 is not a "real amiga".

If I may:

A) If you are thinking of amiga as a major platform, then it was doomed back in the late '90s. However, it will continue as a hobbyist platform for a long time.

B) Can't say I blame you. If you think this thread is bad, you should have seen things back in 2003.

C) QFT

D) You'll always get some numpty telling you that. Best ignored, IMHO.