Which is better? OS 4 or Morph OS . . .

[Piru]

I usually try to stay away from commenting the competition, but here I make an exception.

AOS4 has more flexible library interfaces that will allow better backward compatability in the future

Maybe so, but the interfaces broke source compatibility from the previous AmigaOS. Also, I seriously doubt you'll ever see AmigaOS running on 64-bit systems, there are just too many limitations in the internals of the OS. To make it 64-bit you'd need to redesign all structures and most of the OS calls, and thus they'd no longer be anywhere near compatible to old ones, and thus you get no advantage from the "interface" (the new interface would be completely different to old one). In fact, I'm yet to see any feasible explanation why interfaces would give any benefit over other methods of handling library calls.

not to mention that it supports some POSIX-style shared libraries

I am not sure what you mean with POSIX-style libraries? If you mean dynamic symbol binding, MorphOS has had that for years, even before OS4 existed.


PS. I'm not saying OS4 is all bad, but these things certainly aren't any benefit over MorphOS.

[Piru]

@Karlos

1) An interface defines a namespace. This allows me to create my own interfaces that have function names that would otherwise clash with the OS ones. IKarl->AllocVec() is totally different from IExec->AllocVec(). Both can happily coexist in the same source.

And this is different from IKarl_AllocVec() and IExec_AllocVec() how?
Another matter is that for example #define AllocVec(...) will completely screw the nice namespace concept up, polluting it. In fact, it could be argued that IKarl_AllocVec() is way more elengant since it does NOT pollute the namespace, ever. In analogy most AmigaOS structures have prefix for the entiries, ln_Name instead of Name.

2) Depending on what your interface designed is for, you can happily create multiple instances of a particular interface. Each instance has its own data area.

It's trivial to have library base per caller, bsdsocket.library is great example of this. They can be divided even more, no need for them to be per task.

3) Builds on points (1) and (2) really. There is no reason why I can't have several libraries that implement a particular interface.

And there is no reason why this couldn't be done using perfectly normal libraries. In fact, it has been done several times already (for example the font engine concept in AmigaOS, bullet.library).

The biggest downfall of interfaces is that it's limited to single system, not being source-level compatible to others. While it is possible to implement these things with Interfaces, the actual costs of the implementation (losing src compatibility for no real benefits) is really not worth it.

[Piru]

@Karlos

Maybe it should be pointed out that I also find C++ horrible bloaty nonsense and broken by design aswell.

I'd happily take Java any day, instead.

That being said, I still consider the "interfaces" a bad idea, regardless, at least if you're concerned in moving source between different platforms (that is different AmigaOS and compatibles).

I firmly stand behind my claim that interfaces give absolutely no benefit at all over MorphOS.

[Piru]

@AMIGAZ

Don't worry, this perfectly mature debate. People don't always need to agree.

[Piru]

@Karlos

How? If you write 3.x style code it compiles in OS4. Unless you are writing the libraries themselves rather than applications it need not affect you.

Sure, but then you're forced to make a decision before you start coding anything. If started with OS4 interface style, and you at some later point decide you might want to create OS 3.x, MorphOS or AROS version of your program, you're upto some painstaking changes in the source code.

Also, as a final note: Interfaces are no way anything special. If you really need them, it's trivial to implement them for you current needs. In fact, interfaces are not much more than just some function pointer arrays.

What I also find stupid is forcing the interfaces to developers (or at least forcing the choice of using IFace stuff, or just old style coding), when instead they could be used if it's really applicable for the particular library. (My point being that for some new libraries where the interface actually gave some benefits it would be just fine, but it doesn't make sense to convert the existing establieshed APIs).

I didn't say they did. I said I found Interfaces better by design than 3.x style libraries. I've nothing against MOS.

I understood that, just tried to close up my argument... We're starting to drift a bit from the topic... ;-)

Anyway, at least we can agree to disagree. :-)

[Piru]

@Karlos

that at least they are not anonymous.

Function array don't need to be anonoymous.

Anyway, here's something I cooked up in few mins.. Just to prove the point. This is pretty much what interfaces do, but implement in scaled down single file example, with dummy functions for demonstration purposes only. Like you pointed out, the diff is that here you must pass the interface pointer explicitly.

Code: [Select]

#include <string.h>
#include <stdio.h>

struct myface
{
  int   (*foo)(struct myface *iface, char *str, int idx);
  char *(*bar)(struct myface *iface, char *str, const char *str2);
  void  (*bleh)(struct myface *iface, const char *str);

  /* data or whatever you might need */
};

static
int imp_foo(struct myface *iface, char *str, int idx)
{
  memcpy(str + idx, &quot;foo&quot;, 4);
  return 4;
}

static
char *imp_bar(struct myface *iface, char *str, const char *str2)
{
  strcpy(str, str2);
  return str;
}

static
void imp_bleh(struct myface *iface, const char *str)
{
  printf(&quot;bleh and %s\n&quot;, str);
}

void *getiface(const char *name, int x, int y)
{
  if (!strcmp(name, &quot;moo&quot;) && x == 0 && y == 0) /* whatever rocks your boat */
  {
    /* simple example, something more complex would allocate
       the new interface */
    static const struct myface face =
    {
      imp_foo,
      imp_bar,
      imp_bleh
    };
    return (void *) &face;
  }

  /* there could be different interfaces returned here,
     depending on the passed args.. whatever you need. */

  return NULL;
}

void disposeiface(void *iface)
{
  /* cleanup, if any */
}

int main(void)
{
  struct myface *IFace = getiface(&quot;moo&quot;, 0, 0);
  if (IFace)
  {
    char tmp[4];
    char tmp2[4];

    IFace->foo(IFace, tmp, 0);
    IFace->bleh(IFace, IFace->bar(IFace, tmp2, tmp));
    IFace->bleh(IFace, &quot;things&quot;);

    disposeiface(IFace);
  }

  return 0;
}


Now, is it just me or doesn't this looks just like some half-assed OO implementation for C? :-)

[Piru]

Also your code means that foo() and bleh() are no longer nasty globals so it won't clash with the interface I might want to add.

Yeah, and that's the point. Here you use the interface, since you're going to add some another implementation. But in general, such construct is not needed (if you always use one set of functions for example).

In general, IMO such construct doesn't offer anything in itself that would justify it. Only in cases where you really are going to have different implementations it might pay off (esp if used locally inside a program or between program and plugins, without some sucky global libraries).

Surely you can see an inherent charm in the approach of your code over a 3.x library that defines a global foo() and bleh() ?

Namespacing aside, you implemented it totally in C, no asm, pragmas or other stuff. Hence it is potentially portable across more than the amiga range of platforms.

Nope, if it means you break all source code compatibily to old systems that had foo(), bar() and bleh() in the API using normal library. If this was some new library that actually benefited from the interface (different implementations used internally), then it would potentially pay off.

You can implement library fully in C as you're aware, I'm sure. Pragmas, inlines and other stuff is easily generated from whatever "library definition" you might use (be it XML or fd + protos).

Also, as a sidenote: if the original library defined the foo, bar and bleh functions, they really aren't global. They're actually the base + offset (and base can change per opener, like happens with bsdsocket!). You're not limited to using inlines, you can well use other means of calling them... Naturally if you use #define inlines then they're global namespace, but there is no need for this to be, nor is the limitation set by the actual library implementation in any way.

[Piru]

@Karlos

Now here, I think is the difference between us. For me, the backwards compatibility issue is an implementation detail. I'm more interested in what I can do with an interface rather than how it replaces the old library call. I look at them as a foundation for runtime loadable class implementations more than a simple library mechanism. That happens to holds a lot of interest for me.

Right. I'm sure these things are fine for your projects.

But for OS: I actually want to see what real benefits some new system might give, before actually implementing it all over the place. I'd rather keep things like they are unless if the benefits are really worth the trouble of the change. For some particular cases the interface calling method surely pays of, but not everywhere.

Yes, of course, but what I meant is, your example is portable and clean across multiple platforms without the need for these other components. The 3.x library interface s not.

Yeah it is portable (while OS4 interfaces are not). If you need portability and such construct, you'll end up implementing something very similar anyway (or using C++)... :-)

Yes but using these alternative mechanisms to access the library functions are no more 3.x source compatible than interfaces would be.

True. That wasn't the point here, but disproving the claim that the functions would somehow be global.

we are so off topic

We are, but I still try to point out that enforcing interfaces to old APIs was actually a mistake, not a benefit. :-)

[Piru]

@Karlos

They (the OS4 developers I mean) wanted something more powerful to replace libraries and took the opportunity to implement it at a time when the whole OS was undergoing fundamental rework anyway, so I don't begrudge them that decision.

Actually my understanding is that the interface sheme was brought pretty much as-is from some "semi-dead" AmigaDE project. (I could remember wrong though). Yet, enforcing it to all existing old OS APIs, I will never understand what kind of brain malfuction made them to do that. It just doesn't make any sense (well, to me at least).

Now as for benefits, I really do see things like heirarchial driver sets, plugins, datatypes, gui objects and all such things that are inherently OO by nature can benefit from the new model, since, well it is an OO design.

They're OO to the outside at least, but the internal original implementation is far from it (existing components from previous OS versions). Just converting these to new system for sake of it (and without actually getting any real benefit from the conversion!), is that really worth the trouble? IMO not.

Certainly some totally new systems that are coded to take advantage of the new features would pay off.

But yet again, just converting all old systems to use interfaces: Just extra work without any real benefits, and causing source compatibility issues.

[Piru]

@AmigaMance
You could run Workbench on MOS, if you prefer it over Ambient, see AmigaWBOnPegasos.readme

Which OS is generally faster?

I haven't seen reliable benchmarking done on the identical hardware, so I can't comment that part. If run on their native systems Pegasos II and AmigaONE, MorphOS and Pegasos II win for sure, since Pegasos II with G4 is faster than any AmigaONE available.

Which has the fastest 68k emulation?

To my knowlege only MorphOS has transparent JIT compiler available for general public. So, MorphOS 68k emulation is faster.

[Piru]

@Edpon

I have to admit, the best fit for your description would be WinUAE.

[Piru]

@Karlos

There is also a JIT implementation available for it called Petunia.

It is? Damn, I must have gotten some wrong information then. My source claimed it wasn't available outside of betatesting (that is, that it wouldn't be available for mere mortals).

[Piru]

@SamuraiCrow

The main advantage of Petunia over MOS' JIT is that Petunia will be supported under EUAE.

Says who?

I have some serious doubts this could work. At least not without some massive rewriting and slowdowns to the JIT (all memory accesses would need to be trapped etc etc).

This is what the Petunia author says:

Do you plan any support for UAE?
I don't know yet. There will be a possibility of reaching the emulation from the "outside", so theoretically UAE would even go on with Petunia's engine, if somebody does a special version. I don't intend to do it, but I would help gladly to anybody in this work.

"Theoretically" is far from "will", I'd say.

(Of course if you wanted to download the source to EUAE and splice it together yourself you could.)

Uh?


Anyway, speaking of advantages: At some point MorphOS Trance was something like 3X faster than Petunia. I doubt this is the case anymore, though. It'd be interesting to see some fresh benchmarks.. *hint hint*

[Piru]

@X-ray

That should work, however you'd still need to figure out how to switch the monitor input (manually move the monitor cable, have a monitor switchbox, have two monitors or have a monitor with multiple inputs).