I was wandering when the next OS4 update was.
That was a good article on the libraries and I'm the first to post.

_________________

Yup ... you are... Hey .. I guess you gotta keep the post count going !!

As for juicy bits of info ... Hmm..

Perhaps its because of Amiwest etc .. But I felt it a bit of an anticlimax.... Probably just the way I'm feeling lately

Obviously, keep the good work up Hyperion ... the way I'm feeling atm isn't a reflection on your work !!

_________________
******************************************
I dont suffer from Insanity - I enjoy it

******************************************

Interesting.. Is this a little similiar to COM objects in MS? I seem to remember being able to get interfaces to named objects and then change the interface type to that object....

But it's all a little hazy... a year in Europe will do that to a Kiwi... Anyone's memory better than mine?

Despot Bob

Welcome to amigaWorld DespotBob.

_________________
******************************************
I dont suffer from Insanity - I enjoy it

******************************************

You look as though you need cheering up.
Hay I have an ...I'll cheer you up and keep my post count going all at the same time.

And as for juicy bits of info. What's that?

_________________

Quote:

Poster: DespotBob Date: 9-Aug-2003 9:08:25 Interesting.. Is this a little similiar to COM objects in MS? I seem to remember being able to get interfaces to named objects and then change the interface type to that object....

Don't know about that, since I'm not a programmer (but there are progammers here who will surely answer for you)....

Anyway, although you've been lurking for a bit, welcome to Amigaworld.net

Quote:

I seem to remember being able to get interfaces to named objects and then change the interface type to that object....

There is a bit of a difference between COM and the new library model, although they do share some similarities. In COM you would have a clear distinction between an interface and an object, while this is essentially the same on OS 4. It's possible (and planned) to make this into a full-fledged component system, though, but later down the road (4.1).

In COM, you can get an object and ask it for an interface with the QueryInterface method, essentially getting you a different interface.

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

And there you have it! Directly from a key OS4 developer!

Always good too know I haven't gone completely bonkers working in English bars and drinking their warm beer....

I don't know how I feel about having to Use pointers and stuff to get at methods within an interface e.g

library->reboot();

I'm a bit of a lazy programmer in that sense , but I'll live with it.

Now if only I knew a little more about new threading schemes, an IDE....

He he.

@Rogue:

If you don't have QueryInterface, how do you get at the different interfaces in exec? or are you saying that exec implements two different *objects* as opposed to two different *interfaces*? (ie there is only one object at a time that can implement IMyInterface).

I really like the way that, with COM, you can eg just write an object that implements the IStream interface, and then any other object can read from/write to that object, without caring who wrote it. In that sense, COM is one of the few things that Windows has that is actually pretty decent.

It seems to be, from the article, that interfaces are going to have just simple names (ie not guids or structured progids like "hyperion.exec.main.1"), how are you going to provide for things like versioning? (eg say you decide to extend IExec and create IExecEx, what will I pass to GetInterface to get the new one?)

Quote:

don't know how I feel about having to Use pointers and stuff to get at methods within an interface e.g library->reboot(); I'm a bit of a lazy programmer in that sense , but I'll live with it.

If you
#include

you can write reboot(); afterwards. These "inline4" files contain macros of the type

#define reboot() library->reboot()

for exactly this purpose.

Threading might be covered in a future CAM article

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

@CodeSmith:

This isn't a real component system. It's just a framework to turn interface templates into binary representations. In COM, there would be a central object, which could generate interfaces to itself. This is possible with the library model, but it isn't used this way by the current libraries... Additional code would be needed.

The component system that will make it into 4.1 (probably) will build upon this. For now, it's just a fancy library system that allows more than one jump table per library, which we felt was a good thing to have since it allows moving forward without sacrificing compatibility. When an interface becomes obsolete, it can be moved out of the library into a separate "overlay"-Part of the library. Since every library can override the default "GetInterface" function from Exec, a library has quite some freedom how it handles old interfaces...

With respect to versioning, every interface has a a version number. The interface may be extended without adding to the version number, so that a version 1 "main" interface from exec 50.4 has fewer functions that a version 1 "main" from exec 50.5. However, a "main" interface of version 2 might be totally different.

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

@Rogue:

Oh, I see - it's all part of the "mostly transition and building blocks" nature of 4.0. Fair enough, it's going to take some time to get used to the newer features, meanwhile you guys can get busy on 4.1 etc

Are interfaces going to allow for some form of inheritance, eg "class IMyInterface : public IBaseInterface"?

Your comment about versioning, that means that to open the "main" interface of version 50 of my.library, I'd do something like this:

Library *MyBase = OpenLibrary("my.library",50);
IMyLibrary *mylib = (IMyLibrary *)GetInterface(MyBase,"main");

correct? or, if you write some wrappers to take full advantage of C++:

IMyLibrarySmartPtr mylib = GetInterface(50);

Thanks for all this info, btw. Greatly appreciated

Quote:

Are interfaces going to allow for some form of inheritance, eg "class IMyInterface : public IBaseInterface"?

Not the interface as is. The component system will have something like this, but of course it needs to be ISO-C compatible, so no ": public xxx"

Quote:

Your comment about versioning, that means that to open the "main" interface of version 50 of my.library, I'd do something like this: Library *MyBase = OpenLibrary("my.library",50); IMyLibrary *mylib = (IMyLibrary *)GetInterface(MyBase,"main"); correct?

It would look somewhat like this:

struct Library *XxBase = IExec->OpenLibrary("xx.library", 50);
struct XxIFace *IXx = IExec->GetInterface(XxBase, "main", ifversion, NULL);

"ifversion" would be the version number of the interface. So you basically have two version numbers, one from the library and one from the interface. interfaces with the same version number are backwards-compatible, and if in doubt you need to check for a specific library version.

I don't think your Template wrapper would work - for one thing it is missing the library name

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

First I'd like to thank the OS4 people for writing this sort of technical article. There have been several and they are always interesting.

While this latest info on the library subsystem sounds very clever how it is transparently compatible to both PPC and 68K, I am becoming worried at the number of comparisons being drawn with the PC-like COM system. Under Windows (and Linux, AFAIK) it always seems that a new library or other shared resource is not compatible with the old one. This means that to get older software to use a newer library you have to recompile the application, and that results in loads of versions of the same library on the disk. This seems a daft idea to me 'cos it isn't very *shared* then... (although I know some other people think it's sensible ).

Does anything in this new OS4 library model lead us down this path of having numerous ever-so-slightly-incompatible files all over our systems?

Quote:

First I'd like to thank the OS4 people for writing this sort of technical article. There have been several and they are always interesting.

Thanks

Quote:

Does anything in this new OS4 library model lead us down this path of having numerous ever-so-slightly-incompatible files all over our systems?

No. There isn't much of a difference between the old and the new library model, apart from the fact that for the old model the call through an "interface" (or rather, the jumptable) was implicit, while in the new system this is explicit and you can have more than one jump table.

Remember, this sharea some similarities with MS COM, but not really much, and COM by itself doesn't mean that you end up with different versions of the same file, either. You can implement COM or a component system on top of the new library concept, but that wouldn't necessarily mean you have to have different versions of the same file...

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

Quote:

First I'd like to thank the OS4 people for writing this sort of technical article. There have been several and they are always interesting.

Yes, they do a very nice job of producing an article that gives you a solid grasp of what you can expect from that part of OS4. It's generally worded in a way that is both understandable for the layman and informative for the programmers. Nice balance guys.

Oh yeah, seeing this is your first post, welcome to Amigaworld.net.

@Rogue:

So libraries and interfaces can each have their own separate version numbers. That's actually pretty flexible!

About the templates... I find that library names are *so* 20th century

(I think this bit of code needs gcc 3.x to compile)

#include

using namespace std;

class IFoo {
};

class IBar {
};

template T *GetInterface(int libver,int ifver)
{
cerr << "unknown type in " << __PRETTY_FUNCTION__ << endl;
return NULL;
}

template<> IFoo *GetInterface(int libver,int ifver)
{
cout << "opening foo.library version " << libver << endl;
cout << "getting IFoo version " << ifver << endl;

return NULL;
}

int main()
{
IFoo *myFoo = GetInterface(50,1);
IBar *myBar = GetInterface(50,1);

return 0;
}

In this way, the library name is hidden away in the specialized template (GetInterface), so the coder only has to worry about type IFoo and version numbers.

Quote:

No. There isn't much of a difference between the old and the new library model, apart from the fact that for the old model the call through an "interface" (or rather, the jumptable) was implicit, while in the new system this is explicit and you can have more than one jump table.

Thanks for that clarifiaction.

Interesting what you were saying about precompiled function refs vs. dynamically building from FD files. If it's only done at library open time, is there really performance/flexibility benefit with one system over another?

Quote:

Oh yeah, seeing this is your first post, welcome to Amigaworld.net.

Aww, Jeez, thanks!