Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: Edpon on October 08, 2005, 03:17:15 PM
-
Hi all,
I figure this would be a good discussion question - Which is a better operating system, on it's own AND for ALL Amiga formats?
OS4 or Morph OS
State why it is too please.
Ed
:-P
-
WinUAE
-
This topic has already received plenty of coverage. Search
around the forum. They both have a lot of great things going
for it.
C Snyder
-
They are both about even. MorphOS has better backward-compatability to AOS 3.x but AOS4 has more flexible library interfaces that will allow better backward compatability in the future (not to mention that it supports some POSIX-style shared libraries).
-
If you can afford, both of them.
-
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.
-
@SamuraiCrow
I think you are little confused here. I'm not sure what you mean by POSIX-style shared libraries but for example MorpHOS has SDL (main, image, mixer, ttf, net) libraries as a shared library quite long time now. In addition I've ported ODE/OPCODE, lcms and newlib as a shared library to MorphOS.
-
Piru wrote:
In fact, I'm yet to see any feasible explanation why interfaces would give any benefit over other methods of handling library calls.
Speaking personally, I like interfaces for several reasons, mostly due the the fact that they share several important conceptual features with C++ classes:
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.
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. Whilst this doesn't really apply to the legacy OS interfaces, thinking forwards it is very useful.
For example, I might design some strange hardware abstraction layer where each device has a common interface, say IKarlDevice. Let's assume I have defined an Initialize() method for this interface. I can have an instance per device since I'm no longer dealing with global functions. So I can happily iterate my way down a List of instances of IKarlDevice and call their individual Initalize() methods.
3) Builds on points (1) and (2) really. There is no reason why I can't have several libraries that implement a particular interface. So my system might load several different implementations of my device interface for specific devices. Or to make it a bit shorter, interfaces are inherently polymorphic.
As a more tangible example, consider MUI/Reaction etc. The BOOPSI calling mechanism is just awful. Reimplementing them using interfaces would likely give more compact code that could run a hell of a lot faster. I am sure a button->DoLayout() is an order of magnitude faster than a DoMethod() call via the boopsi dispatcher :-)
Of course I don't expect that will happen, and really, nor should it. Might as well design a completely new, interface centric system in future.
I'm not saying you cant reproduce some of this with OS3.x style libraries, but it is no where near as elegant to accomplish.
-
@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
Look at them all together rather than point by point. For example, who says IKarl has a global pointer? IKarl_AllocVec() implies some global scope function, interfaces, and consequently all their methods, can exist in any scope a variable can.
Unlike C++ namespaces, an interface method is actually a function pointer within the interface structure. You can't pollute it since a structure can only contain uniquely named members. When I said it defined a namespace, I meant IExec and IKarl are seperate structures that can freely contain identically named member functions.
As for the macro stuff, I prefer not to use it at all in clean OS4 compatible code. It is purely for 3.x source compatibility. If that is not important to you, you don't have to use it.
How easy is it to create a list of library instances within a single task, iterate the instances individually and call methods per instance? Sure it can be done, but how straightforward is it to do?
Again with the polymorphic stuff, you can do it using libries, I never said otherwise. Interfaces, however, bring all of these under a very simple to use and implement system.
Your counter arguments are remind me of those made by people comparing writing object oriented code in C versus C++. Nobody says you cant write object oriented code C, or structured code in pascal. It is a question of how straightforward and clean it is to accomplish.
As for your final point, libraries are also single system. They apply only to amigaos and compatibles, so that argument doesn't really apply, unless you want strict compatibility source with 3.x. In that case, sure you can just use the macro level stuff and do that. I've never yet failed to compile any 3.x stuff under 4.0.
Clearly you don't regard interfaces as a useful idea. That's your opinion and I respect that. However, I feel they are genuinely useful and have a lot of potential.
-
lol...is this the start of a computer-geek battle..
I´m glad I don´t know so much about programming :D
-
@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.
-
AMIGAZ wrote:
lol...is this the start of a computer-geek battle..
I´m glad I don´t know so much about programming :D
Not really, just a difference of opinion on something.
I've never cared a less about the red v blue thing.
-
Just checking the temperature on you guys ;)
Carry on
-
Piru wrote:
@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.
:-D You know somehow I guessed.
That being said, I still consider the "interfaces" a bad idea, regardless, at least if you're concerned in moving source between differnet platforms (that is different AmigaOS and compatibles).
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.
I firmly stand behind my claim that interfaces give absolutely no benefit at all over MorphOS.
I didn't say they did. I said I found Interfaces better by design than 3.x style libraries. I've nothing against MOS.
-
@AMIGAZ
Don't worry, this perfectly mature debate. People don't always need to agree.
-
Piru wrote:
@AMIGAZ
Don't worry, this perfectly mature debate. People don't always need to agree.
I'm far too old for all that trolly nonsense :-D
Off topic a bit, what's your take on Objective C?
-
@Piru
;)
-
Piru wrote:
@AMIGAZ
Don't worry, this perfectly mature debate. People don't always need to agree.
No it isn't and yes they do..
/* ducks */
-
@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
True about the decision, but deciding to code anything for amigaos/like stuff is a decision in itself these days :-(
I'd argue that interfaces are a little better than function pointer arrays (and hey, I am like the worlds biggest fan of function LUT, just ask Patrik) in that at least they are not anonymous. Give me blah->method(arg1, arg2) over table[n](arg1, arg2) anyday. Don't forget that a pointer to the instance of the interface is always passed to the function implicitly too (akin to the C++ 'this' pointer), which you'd explicitly have to do for normal function pointer.
What I'd like to see is the interface concept opened up for 3.x compatibles. That would really eliminate the major objection that interfaces force you to stay on one path. Of course, that decision is well and truly out of my hands.
-edit-
Actually, thinking about what you said of the macro stuff earlier, it occured that it doesent really clash. What I mean is:
AllocVec() is just a #define for IExec->AllocVec()
It shouldn't ever clash with any other interface's AllocVec() unless you want to macroize those interface calls too.
IKarl->AllocVec() would sit happily with AllocVec() (as a define). If I needed to make it 3.x source compatible, I could always #define KarlAllocVec().
-
Actually it is precisely due to arguments such as these that I started my own C++ framework project in the first place :lol:
Except there it extends to rather more systems than the amiga compatibles :-)
These days I shudder when I see explicit OS calls :-D
-
@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.
#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, "foo", 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("bleh and %s\n", str);
}
void *getiface(const char *name, int x, int y)
{
if (!strcmp(name, "moo") && 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("moo", 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, "things");
disposeiface(IFace);
}
return 0;
}
Now, is it just me or doesn't this looks just like some half-assed OO implementation for C? :-)
-
True, you just need a constant for n. My main point is that the interface is a bit more than a function pointer table. It is the instance data too and the calling semantics to ensure that the instance data is always passed transparently to any function. For example, IExec->AllocVec(size, flags) actually compiles to IExec->AllocVec(IExec, size, flags).
-edit-
Of course, the anonymity of function LUT is one of its principal advantages. I use them for all sorts of things (presently writing a VM where the opcode value looks up a handler function, for example)...
-
Now, is it just me or doesn't this looks just like some half-assed OO implementation for C?
It does when you see the implementation of it, yes. Of course you don't see the implementation, which is the point.
If you compare what you have just written with a typical BOOPSI object, for example, can you claim this code is not an order of magnitude cleaner and simpler? True boopsi supports more runtime flexibility (closer to smalltalk than C++) but I have never seen anybody make use this.
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. After all, foo() is the most fundamental method ever named :-D
-edit-
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.
-
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 wrote:
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.
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.
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).
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.
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.
Yes but using these alternative mechanisms to access the library functions are no more 3.x source compatible than interfaces would be.
-
@Piru
:lol: we are so off topic :-D
-
@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
Regarding the OS:
I don't argue with you that replacing the old mechanism causes some issues. I am sure that doing so, was to bring about a cleaner system in the long run. Phasing out old stuff gradually can be messy. Heck, I'm using windows here, the king of half baked transformation. 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.
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.
-
@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.
-
I was more thinking of new systems to usurp the old ones. Things like datatypes, in their present guise are fundametally flawed IMHO. But that is another discussion entirely and we are off topic enough already :-)
-
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.
This doesnt work for libraries which are ported from link libraries. For example I cant imagine you edit every single SDL port to call SDLIFace->SetVideoMode() instead of SetVideoMode() ?
As a more tangible example, consider MUI/Reaction etc. The BOOPSI calling mechanism is just awful. Reimplementing them using interfaces would likely give more compact code that could run a hell of a lot faster. I am sure a button->DoLayout() is an order of magnitude faster than a DoMethod() call via the boopsi dispatcher
How inheritance would work? For example if you subclass root class and ad your own methods -- how root class is supposed to handle them?
On the other hand you need a class pointer to call super class. On the other hand you must access your local object data somehow. In practise you are trying to create a class from library base.
If you look into OS4 documentation you will find out interface has
a) function table at positive offset
b) data at negative offset
AmigaOS 3 library base has
a) function table at negative offset
b) data at positive offset
That is major difference between them.
-
@Edpon
Which is better? OS 4 or Morph OS . . .
By the discussion so far, I would say the experts can't decide :lol:
redfox
-
@itix
To begin, I said interfaces share several important facets with C++ classes, I didn't say they were equivalent C++ classes. Therefore, inheritence is not something that is not implicit in the interface design as ultimately C is not an OO language. However, that doesn't mean it is not supported at all...
How inheritance would work? For example if you subclass root class and ad your own methods -- how root class is supposed to handle them?
Remember, a parent class never does have any knowledge of any of any of its childrens' unique methods or properties. Consider an actual C++ class heirarchy. If your parent class is HouseholdPet, and you have sublcasses of GoldFish, Cat, Dog, Budgie, etc, *only* the interface defined by HouseholdPet is common to all. Each implements the HouseholdPet interface and adds some unique methodst too. Dog might add a method chasePostman() to the existing set of methods it inherited from HouseholdPet.
You cant expect to call a Dog specific method such as chasePostman() via an "HouseholdPet* pet" (unless you use RTTI and do a dynamic_castpet and check it was valid) as your particluar pet might be an instance of GoldFish.
-edit-
Mind you, that would be something to see :roflmao:
-/edit-
In this regard, interfaces are no different to classes. I can't realistically call a method of a sub interface via a handle to the parent that the parent does not already advertise.
The second issue is polymorphism. Customising methods of the parent interface to suit the specific child so that different instances of an interface might perform the same method call differently. This is perfectly doable. Remember, the methods are really just embedded function pointers within the interface structure and can be changed. If I cloned an instance of IKarlDevice, I can provide my own function to handle the Initialize() method specifically for that one instance (similar to SetFunction() on a library).
On the other hand you need a class pointer to call super class. On the other hand you must access your local object data somehow
How do I call the 'parent' implementation's method within my method? Well, provided I just don't blitely throw the old pointer away, I can use it to call the original IKarlDevice's implementation too, if I need to. OK, this is not quite as nice as being able to do a java esque "super()" call but it is achievable without that much fuss. I dont see libraries having it any easier.
Furthermore, since interfaces are just structures, provided I give them unique names, I can create any number of cast compatible clones of struct IKarlDevice, eg struct IKarlKeyobard, struct IKarlMouse (adding any unique stuff only at the end of the structure, again like library bases do). Each of these can implemented by totally different libraries. This allows me, if I need to, to handle instances of totally different implementations (as opposed to just modifying a single instances function pointer) of an interface without having to exactly know what they are.
If you look into OS4 documentation you will find out interface has
a) function table at positive offset
b) data at negative offset
AmigaOS 3 library base has
a) function table at negative offset
b) data at positive offset
That's the implementation difference between them. How they can be used by the developer and they can assist the developer in achieving his goals are more important.
I stand by the observation that interfaces simpify the creation of this type of construct compared to achieving the same thing with 3.x libraries (or even boopsi classes).
If you prefer doing this type of thing with 3.x style library bases and the 3.x source compatible ways of calling their code, that is entirely up to you. I personally find it much less cumbersome to accomplish this type of thing with the interface syntax.
-
redfox wrote:
@Edpon
Which is better? OS 4 or Morph OS . . .
By the discussion so far, I would say the experts can't decide :lol:
redfox
I have to apoligise to the thread author, really. This discussion is nothing really to do with the question that was asked :lol:
Which OS is better? That depends on your selection criteria. Due to the nasty politics that led us to where we are now, many people don't have the choice, since each OS is somewhat tied to a hardware choice too.
Only the classic ppc systems, at this time are capable of running both. That said, the classic systems are (in performance terms) eclipsed by the A1, Peg etc., on which the respective OS's really show their true potential.
-
Well you both killed the poor guys topic!
To get back on track and to help you out, OS4 and MOS both have good things in them. As to the better OS thats up to the end user. I for one have used MOS since the PEgasos came out and like it much better then OS4. I would like to see OS4 on the Pegasos II to give it a chance, but I still feel MorphOS is by far the etter choice. Again its all up to the end user.
-
@Acill
I for one have used MOS since the PEgasos came out and like it much better then OS4
Have you used OS4 too, or is that a subjective opinion on what you think OS4 is like to use?
It would be interesting to see what someone like Wilse, who has both platforms to hand would have to say.
I haven't downloaded MOS for BPPC yet, but it's on my to do list. I could then give a more educated comparison, at this time I don't know enough about MOS to comment.
-
Who is the better programmer? Karlos or Piru? :-P
-
:lol: :lol: :banana: :banana:
-
:lol: :lol: :banana: :banana:
-
"Who is the better programmer? Karlos or Piru?"
i have no idea! but i love them both :-)
-
If OS4 and MorphOS were equal, then what would be a deciding factor? The community behind each platform? Industry recognition?
-
the community behind could be the factor.
Its a matter of taste . . . i have friends and "enemies" on both sides, so :-)
-
x56h34 wrote:
Who is the better programmer? Karlos or Piru? :-P
It'll be the one with the biggest beard, bad personal hygiene and no girlie.
And looking at Piru's avatar, he's not old enough to grow a beard or date ;-)
-
:roflmao:
@Doobrey
Interesting argument. However, the unshaven soapdodger genus of programmer belongs to the era of procedural programming. Those of us that subscribe to the more recent OO paradigm prefer cleanliness ;-)
Whilst I'm not going to comment on the "better programmer" thing, I don't originally come from an AmigaOS coding background and I think it is perfectly fair to say that Harry's knowledge of AmigaOS specific coding is more extensive than mine.
-
@Karlos:
Are you saying that Piru likes coding for AmigaOS?
OK, I'll stop now. :-)
-
Darth_X wrote:
If OS4 and MorphOS were equal, then what would be a deciding factor? The community behind each platform? Industry recognition?
If they were equal, would there really be a deciding factor? Equality implies they'd run the same software on the same range of hardware. It would be entirely down to personal taste.
-
MorphOS with a Linux dual-boot is equivalent to the not-yet-released AmigaOS 4 except that AOS 4 will never support fork(). :-P
-
I think this subject needs to be narrowed down a bit. So far, people seem to be interested in the maturity of the technology (which is rather ironic), but not much has been said about usability, capability, overall features, or just the fun factor. The A1000 had a solid OS architecture for its day, but I don't think a lot of people bought them so they could program libraries all day. ;-)
Also, I wonder how many people have actually used both AmigaOS 4 and MorphOS so a fair comparrison can be made.
Me, I finally bought a Mac mini (in transit) to accompany my Windows and Linux systems. I'm afraid the word "Amiga" is merely a memory.
-
Also, I wonder how many people have actually used both AmigaOS 4 and MorphOS so a fair comparrison can be made.
Why not ask someone who owns both? :-D
-
While I dont own OS4 or an A1 I have used both OS4 and MorphOS quite a bit. I have a close friend that uses the latest pre of OS4 on an A1 Micro and I get to use it all the time. To me MorphOS feels more like the Amiga I grew up with and had all the way up to the release of the Pegasos II. OS4 looks like it, but just doesnt "feel" the same to me. Its hard to say exactly what I am talking about here, but even he feels the same way, though he like OS4 a lot more. I joke that he only likes it because he has a lot more money spent to get it then I have in my Pegasos. (mind you I did sell off a loaded A3000 to get the Pegasos)
-
Ok Karlos and Piru, here's the second part of my question, since you two seem to be Amiga Tech Gods - Can you have both OS's on one system, the way you can on a PC? My main reason for asking this question to begin with, was that I'm totally undecided on which system I want to have; since I want to be able to use all my past Amiga games, and want to see what Amiga has in store for the future. I want to support Amiga as much as possible, mainly because I'd love to see it make a grand re-entry into the mainstream computer scene. Winblows and Mac's have dominated for too long, and need to be humbeled by the computer that never dies ! Here's a third part of my question - What OS will support the GREATEST range of standard computers parts, ie - CD-Roms/DVD-Roms, memory, sound cards, etc. ?
Ed
:-D
-
@Edpon
Well, Piru and I were engaged in a different discussion really that was an offshoot of an implementation difference between the two.
You can run both on one machine (not concurrently), a classic machine equipped with a PPC card and an RTG card can run versions of both OS's. I see no reason why you cant have multiple bootable partitions. I myself have OS3.1, 3.5, 3.9 and 4.0 on my A1200T. Adding one more for MOS shouldn't exactly be rocket science.
However, OS4 for BPPC/CSPPC is currently not available outside the betatester group. Conversely, MOS for CSPPC/BPPC is available for download.
I don't expect to see OS4 running on Peg or MOS running on A1 anytime soon (a lot of nasty politics, in fighting etc has gotten us into this situation), which is a shame since these machines are a lot more powerful than their classic counterparts.
Hardware support, for both systems, is understandably a lot narrower than it is for PC. Ultimately this is dominated by driver availability. Some hardware vendors (eg nVidia) take a proprietry view of this issue, so don't expect to see support for the HW anytime soon.
If you are undecided your best bet is to try to attend any local shows etc where you might have the opportunity to try them both in order to make up your mind.
-
If you or anyone is in the San Diego area I would be more then happy to show you MorphOS on a Pegasos II machine. Just let me know. I am home most nights and weekends.
-
@Edpon
I only own one of these systems, and I have never seen the other in operation, so I can't compare OS 4 to Morph OS.
My old Amiga is an Amiga 2000HD e/w 68000 CPU running OS 3.1, so my old software is strictly 68K software.
My micro-AmigaOne is running Amiga OS 4 prerelease update 3 (I'm not a beta tester, so I don't have access to the latest beta OS 4).
Under OS 4, I use AWeb APL Lite (PPC) for browsing the net.
After tweeking prefs, I can run the following 68K programs directly under OS 4: FinalWriter97, AmigaVision, Personal Paint 7.
I found that most of my other software runs fine under the Amiga OS 4 version of E-UAE. So, for example, I can launch E-UAE and then run Shanghai by Activision, Inc. Still need to tweek sound a bit for MegaBall.
I have not tried Lemmings yet.
---
redfox
-
I can't comment which OS is better since i have an Amiga 1200 and i have only tried MOS. Imho the biggest weakness of MOS is its desktop, Ambient. Workbench 3 (with mcp installed) is much more pleasant and productive enviroment for me, even if it looks uglier. I don't care about that.
I have 2 speed related questions:
Which OS is generally faster? and
Which has the fastest 68k emulation?
-
@AmigaMance
You could run Workbench on MOS, if you prefer it over Ambient, see AmigaWBOnPegasos.readme (http://www.elena-fractals.it/Downloads/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.
-
@Edpon
I have to admit, the best fit for your description would be WinUAE.
-
Maybe the better question is this:
Is there a way to run OS4 and MorphOS on the same box? By hook or by crook. I don't give a darn about bending the rules.
-
The Commodore 64 smokes both OS 4 and Morph OS. :-D :-)
-
boing wrote:
Maybe the better question is this:
Is there a way to run OS4 and MorphOS on the same box? By hook or by crook. I don't give a darn about bending the rules.
If you own a classic PPC based system and you have access to OS4, yes. If you own either an A1 or Peg, then for now you are limited to either/or.
-
AmigaMance wrote:
Workbench 3 (with mcp installed) is much more pleasant and productive enviroment for me, even if it looks uglier. I don't care about that.
Yeah, OS4 has the original Amiga Workbench, but ported to PPC and improved. Also, an OS4 native port of Directory Opus Magellan is due to be released very soon.
-
@piru
@AmigaMance
You could run Workbench on MOS, if you prefer it over Ambient, see AmigaWBOnPegasos.readme
Ok, i will try it.
Quote:
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.
You're right. My question should have been: "Which OS runs faster on a classic?" But, i guess, only a OS4 beta-tester with a Amiga 1200/4000 can answer that. ;)
Quote:
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.
I'm getting a little confused here, probably because i'm not familiar with the new systems. How AOS4 is able to run 68k code without a 68k emulator?
Here is an excerpt from the AOS4 feature list:
"Just in Time (JIT) 68K emulation
Dynamic recompilation or JIT compilation is a technique whereby (in this case) 68K machine code is translated on the fly to PPC machine code which is stored in a temporary buffer to avoid recompilation each time the recompiled code is executed. All 68040 instructions including FPU instructions are fully emulated. Even on a lowly 603e@160 Mhz the recompiled code reaches and in some cases surpasses the speed of a 68060@50 Mhz."
@xeron
Excellent!
-
@AmigaMance
OS4 has a 68K interpreter built in. There is also a JIT implementation available for it called Petunia but this is currently restricted to betatesters. I am a bit behind the current release as I have had no time to spend on my system, but at the last test it was fast enough. Depending on the code at hand, my 240MHz 603 could interpretively emulate many 68K applications at a speed comparable to my real 68040 @ 25MHz, which was pleasently surprising. The JIT, suffice to say, was a lot faster.
-edit-
Clarification to avoid any misunderstanding about the general availablity of petunia.
-
If you own a classic PPC based system and you have access to OS4, yes. If you own either an A1 or Peg, then for now you are limited to either/or.
Really? I didnt think you could run OS4 on a classic Amiga w/PPC..from what I saw only MorphOS runs off of both PPC (Pegasos and Classic + PPC)
-Alex
-
Remember, a parent class never does have any knowledge of any of any of its childrens' unique methods or properties. Consider an actual C++ class heirarchy. If your parent class is HouseholdPet, and you have sublcasses of GoldFish, Cat, Dog, Budgie, etc, *only* the interface defined by HouseholdPet is common to all. Each implements the HouseholdPet interface and adds some unique methodst too. Dog might add a method chasePostman() to the existing set of methods it inherited from HouseholdPet.
I'm not sure: would every class have its own interface structure or would subclasses inherit its parent interface structure and extend it. If so, how?
In this regard, interfaces are no different to classes. I can't realistically call a method of a sub interface via a handle to the parent that the parent does not already advertise.
In BOOPSI you can. It is just ignored by super class. Either way interface (as in struct Interface) cant replace Intuition objects at all.
The second issue is polymorphism. Customising methods of the parent interface to suit the specific child so that different instances of an interface might perform the same method call differently. This is perfectly doable. Remember, the methods are really just embedded function pointers within the interface structure and can be changed. If I cloned an instance of IKarlDevice, I can provide my own function to handle the Initialize() method specifically for that one instance (similar to SetFunction() on a library).
That could be an advantage sometimes.
If you prefer doing this type of thing with 3.x style library bases and the 3.x source compatible ways of calling their code, that is entirely up to you. I personally find it much less cumbersome to accomplish this type of thing with the interface syntax.
In my opinion 3.x style is just fine. I've used it so many years already :-O
-
@itix
I really think we should open another thread for this, but...
itix wrote:
I'm not sure: would every class have its own interface structure or would subclasses inherit its parent interface structure and extend it. If so, how?
For simple extensions, where you only need to change a method or two, cloning an instance of the parent and changing the function pointers for the methods you need would be sufficient.
When you need an extended structure, every class having its own interface structure is likely simplest as there simply is no way in C to extend a structure. Otherwise you do what you would to in a library and have the parent structure as the first member and remember which cast you are using. This is a limitation of C itself, not interfaces or library bases.
When you need an extended structure, you have
In BOOPSI you can. It is just ignored by super class. Either way interface (as in struct Interface) cant replace intuition objects at all.
Of course it can't replace BOOPSI directly (that is making existing boopsi fit interfaces and remain compatible), or at least without a lot of effort.
It can, however easily replace boopsi as a fondation. I've already experimented a little in this area, a simple inteface definition with event handler / render methods implemented as one of three simple objects (this was a direct adaptation of my C++ framwork's unfinished guilib idea).
A future GUI framework not based on boopsi but upon interfaces is entirely possible, it just would have no backwards compatibiliy with boopsi at any level.
In my opinion 3.x style is just fine. I've used it so many years already :-O
Entirely your choice. Have you tried any of the types of OO construct design discussed here using only 3.x style and library bases? I have and it is quite frustrating compared to the interface approach.
-
@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).
-
I guess Karlos is a betatester or knows one because the classic versions of AOS 4 and Petunia aren't going to be released until the final release. The main advantage of Petunia over MOS' JIT is that Petunia will be supported under EUAE. (Of course if you wanted to download the source to EUAE and splice it together yourself you could.)
-
@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
Fair enough. The author of EUAE, Rich Drummond, had expressed an interest in using Petunia in conjunction with EUAE but it wasn't finallized.
-
@ Piru and Karlos
For my A4KT, with PPC and PIV am I correct in saying I could run OS4 for classic machines when it comes out, but in order to run MorphOS I would have to get a CybervisionPPC graphic card?
It seems to me (if I understand this correctly) that I could have 3 boot devices and run the 3 main OSes like this:
1) 3.X by means of onboard AGA or PIV, and the 060 on my Cyberstorm.
2) OS4 by means of the PPC and the PIV.
3) MorphOS by means of a Cybervision PPC and the PPC itself (assuming I get a Cybervison PPC).
That would be quite nice. I suppose there won't be a problem with me having the PIV and the CybervisionPPC installed simultaneously as long as I only have one set of drivers active per boot?
-
It can, however easily replace boopsi as a fondation. I've already experimented a little in this area, a simple inteface definition with event handler / render methods implemented as one of three simple objects (this was a direct adaptation of my C++ framwork's unfinished guilib idea).
But would it give a significant performance boost compared to BOOPSI? Calling a method in BOOPSI is not very expensive after all. There is some extra overhead in dispatchers but I think current BOOPSI is quite good.
Surely interfaces have some flexibility to be used like this. And I know few cases where I could take an advantage of interfaces.
Entirely your choice. Have you tried any of the types of OO construct design discussed here using only 3.x style and library bases? I have and it is quite frustrating compared to the interface approach.
I have used only C++ and Java but there I dont have to care about low level details.
Btw it seems in Windows you have interfaces too (in COM objects, I guess).
-
@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).
-
@ Piru
I think I would go for a digital switchbox because the manual one I have now is poor quality with vertical ghosting.
But that is good news indeed. The big box classic may turn out to be a flexible machine for users like me who have PCs to do the serious stuff.
-
Piru wrote:
@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).
Sorry, I wasn't completely clear. Hey, I've been virtually dying of a cold these last few days you know. It is avaliable in that it exists, but is presently only available to betatesters. I have tested earlier versions on my BPPC but my betatesting has been very lacking of late due to other commitments :-( I can only assume, however that it will be present in the final release. I hope so anyway :-)
-
We all know which one is the Best!
AROS!!! :-D
-
itix wrote:
But would it give a significant performance boost compared to BOOPSI? Calling a method in BOOPSI is not very expensive after all. There is some extra overhead in dispatchers but I think current BOOPSI is quite good.
Horses for courses really. An interface call (inderect call from a function pointer) is unarguably much faster than a Boopsi call (dispatcher shennanigas), but when you consider a typical GUI is mostly waiting for stuff to happen I would say not. I do find interfaces cleaner conceptually than boopsi and a lot more general purpose too. Again, my personal opinion.
I have used only C++ and Java but there I dont have to care about low level details.
As it should be. When writing application code the very last thing I want to know about is the platform implementation detail, so I agree. However I also like to work in abstraction layer or lower occasionally where these things become important too.
Btw it seems in Windows you have interfaces too (in COM objects, I guess).
Even MS have OK ideas sometimes you know :-D