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

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

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

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:

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

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

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.

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?