The OS4 direction thread

[Hans_]

@Matt_H

Rogue made it clear (somewhere) that shared objects are not going to replace shared libraries. Shared objects have no way to share data between multiple processes; shared libraries do.

In fact, it's this difference that makes porting shared objects to libraries a pain. Shared objects can use local variables without screwing up multiple processes because local variables aren't shared across multiple processes (the MMU is used to create local versions, I've been told). With shared libraries, such variables are shared across all apps using that library, making subtle bugs occur. This means that maintaining a port takes a lot of effort. Every new version must be checked/repatched for these kinds of issues.

I don't think that it's turning Amiga OS into another Unix system. You can't use Linux PPC shared objects in Amiga OS. Yes, it does mean that we're going to get more quick and dirty ports. One thing you can rely on though, people will probably still work on OS4 native software simply because they don't like the quick and dirty ports.

Hans
 

[Hans_]

@Piru

Should people really be doing this in shared libraries/objects?

int func()
{
    static int staticLocal;

    // further code that uses staticLocal
}

Apparently that's quite ok with a shared object, because each process that links to the shared object has it's own local var space. To me, it just looks like a thread unsafe time-bomb waiting to happen. It's bad coding practise. What happens if you use such code from multiple threads within the same process?

I like the fact that I can decide what is global and what is  local to a library opener. My understanding is that this is why they created the Open/CloseInterface() system in OS4 (you can have per interface data without messing with the lib-base).

Really, I think that they created shared-object loading facilities so that you can just take some cross-platform source code, type make, and build the app, without having to write library frameworks (a lot of extra work). It's also less of a problem if someone adds/removes functions to/from the shared-object (I think that removing functions from a library after release is a bad idea, you're breaking compatibility). Then there's the issue of some shared-objects wanting to link to external global variables. I can't think of any clean way of doing that with a library (I also don't think that a library should have external dependencies like that).

Hans

[Hans_]

Piru wrote:
@Hans_

Really, I think that they created shared-object loading facilities so that you can just take some cross-platform source code, type make, and build the app

Well, you don't really get very well functioning stuff that way. And what happened to ixemul anyway? It actually works amazingly well on many such occasions (and you hardly ever really absolutely need shared-object stuff in quick compiles anyway).

Ixemul doesn't provide you with all the libs that a Unix system has. I seem to recall there being issues with ixemul on OS4, but I don't know whether that's been fixed or not.

BTW, why won't you get well functioning stuff this way? It works on Linux. The current X11 Firefox compile for Amiga OS4 is about 118 MB thanks to everything being statically linked (and compiled with the debug flag). X11 + apps is also sizeable because it's all statically linked. Having them use shared objects will at least not waste my HD space.

without having to write library frameworks (a lot of extra work).

Actually the relskeleton framework is quite simple. Also, it doesn't involve changing millions places in the sourcecode (However, naturally some sources require more work than others). I'll much rather take proper library that doesn't gobble tons of memory and resources just because coders were lazy and/or incompetent.

I know it's not complicated to write an Amiga library wrapper framework, but it takes a lot longer than simply typing make and hitting the enter key.

It's also less of a problem if someone adds/removes functions to/from the shared-object (I think that removing functions from a library after release is a bad idea, you're breaking compatibility).

Huh. You never remove functions or insert new ones before the old. You only declare them obsolete, and wrap the old API so that it can use the services of the new, thus keeping binary compatibility. If the API changes completely, just create a new library (change the name) instead. This should be quite obvious.

Maybe YOU don't. However, that's the reason why sometimes v5 of a particular .so is incompatible to v4. I think it's a really stupid thing to do as this means you need new versions of all apps that used that .so (not a big problem if it's all open source, but it's still not good). Some people do mess with functions in shared objects this way.

Then there's the issue of some shared-objects wanting to link to external global variables. I can't think of any clean way of doing that with a library (I also don't think that a library should have external dependencies like that).

I'm not quite sure what you mean by that, but assuming it's just having some "really" global variable: the section trick does the job just fine, if you really must. If you just need some variable from other loadable component, you can do this quite easily too. There are various way to do this, for example fields in public library possize, or some function to return the variable pointer.

What I mean is that shared objects can also have, for example, something like: extern int appGlobal. The application would be expected to provide this global variable.

And finally: This relskeleton stuff is nothing magic, it's actually old news. Even SAS/C did it decades ago already.

I frankly don't understand why OS4 can't have the same.

There's no technical reason why they couldn't. Personally, I prefer shared libraries to shared-objects, but I don't have a problem with them providing shared-objects for those porting software over. If it takes them less time porting stuff over, maybe they can spend more time writing real Amiga software.

Hans

[Hans_]

Piru wrote:
@Hans_

There's no technical reason why they couldn't.

Really? So why don't they? For example python would work perfectly fine as a real shared library, and then it would not eat as much memory, either.

MorphOS python binary is 9KB, while python.library is 1.2MB. The library is loaded to memory once.

Limited resources is the only reason I can think of. They have a limited team working on Amiga OS4, and a huge number of tasks. It's a tool for anyone porting stuff over; it saves time.

Hans