Two newbie questions

First: Hi to all!!
I'm new to os4 programming (i've got a little experience in aros and morphos).
Where can i find some "tutorial" that introduces me to os4 coding?
I've compiled something in the last days and i found i've to use iexec and idos to use api.
Is there a way to avoid this? (i.e. i compiled ahi ppc os4 examples and they give me the same errors (implicit declaration of function...))?
Thank you!!

Welcome to OS4, its nice you have knowledge in most amigasystems. Interested too see what you make later on :)

@rebraist
Check in the SDK pdf called migration guide. But in brief, to get rid of Isomething->function , you just add #define __USE_INLINE__ at top of your source code, or -D__USE_INLINE__ to compiling string. Then you just can use function as in old os3 way. You also better add -lauto at linking stage when you use __USE_INLINE__, as it will sort out some stuff for you (like auto opening of some libs, which, without -lauto you will need to open manually in code : thats easy, but just can be boring). I all the time use __USE_INLINE__ when port os3 sw to os4, without it, it will be just unpossible to port some heavy os3/aros/mos apps.

Soon there also be some public wiki, which cover all the stuff for os4, but dunno when. os4coding.net can be helpfull as forum, and even some good article can be found there (check Rigo's and Trixie's blogs).

kas1e is correct, but I noticed you mentioned some ahi code.

Probably because ahi is written for multiple platforms, they default to inline code, unless you
#define _no_inline
in your program. This is kind of backwards from the way most OS4 code works, but once you know what to look for, no problem at all.

Have Fun!
LyleHaze

-lauto is depricated and should be avoided.

Opening the libs yourself may be touch tedious, but it hets you control of versions etc hiding the code with -lauto doesn't do.

thank you! solved with __USE_INLINE__!!
Now i'm compiling playsineeverywhere.c from lowlevel but it tells me it can't find: config.h, version.h and hookentry... I hope it's not some misconfiguration of my sdk..

files like config.h and version.h are typically prohject files not SDK files, so perhspa you are not build from the right directory so that gcc can't find the files.

I don't know the project so can't give specific advice.

@broadblues
Quote:

Where you read that ?

Quote:

As -lauto mostly uses when you port os3 code to os4, then its automatically most of time mean that all the libs on os4 most of time newer or at least the same as on os3. So there no big point to check on version numbers.

Sure, when you code something from scratch for os4, then its even better just use IInterface->function , so no inlines, and no -lauto.

To add, if -lauto works now, then why not use it. When it will be deprecated for real and removed, then sure. But for now its helpfull (expectually for that os3->os4 porting).

@rebraist
Quote:

Dunno about config.h and version.h (usually they produced by ./configure scripts), but if you have no undef reference on linking, except that just on compiling stage compiler says that config.h and version.h not present , then just comment them out.

As for hooks, they are different on all the oses and you should rewrite them to os4. For that you have 2 ways:

1. SDI hooks. Then you will be able to make cross-compiler hooks, which lately can be easy reused for os4, os3, aros and mos.

2. Native os4 hooks. All what you need to know about when you port os3 hook to os4, is that way of replacing function params instead of passing them to 68k registers are : a0, a2, a1.

I.e. if you have on os3 for example such kind of fucntion used for hook:

Quote:

Then for os4 native it will looks like this:

Quote:

So you only change necessary lines. Keep in mind, even if you have 1 or 2 registers used on os3/mos hook (not all the 3), you still, should put 3 params to the function itself (like i do here for A2, which are second param "Object *skip"), or you will have crashes/bugs and problems if you will not fill all the 3.

Real life hook example with HookEnty and stuff when let's say rewriting from morphos (and almost the same for os3 as well) to aos4 looks like this:

mos:
Quote:

And os4 version of that:

Quote:

Still, if you want to use HookEntry, and want to have hook on os4 as on old os3 way with HookEntry, then you can use some emulated assembler function (like done in simplemail), but that for sure suck, and need to avoid assembler for sure (in simplemail it was done like this only because of reassons to have the same code works on all oses).

But if am right, HookEntry was added in last versions of utility.library (which part of kernel), and can be used as well. But there i can be wrong, and that need to check.

Quote:

http://www.os4coding.net/blog/trixie/ ... -os4-reaction-programming

And other places.

Maybe the term depricated is too specific and I should say, 'not recomended for new code'.

I myself never used it even in old code.

@kas1e

If all you want is a HookEntry to use in PPC code so that you can do:

Quote:

instead of as you would usually do on ppc-amigaos:

Quote:

you could just use this function:



Note that I really don't see the point in doing this since it only adds extra, unnecessary overhead to each call of the hook functions.

If portability between AmigaOS and compatibles is needed then it's easier and more efficient to just use the SDI macros that are written for this very purpose.

@for all of you:
thank you for all the answers!!!!

The correct way to create a hook under AmigaOS 4 is to use AllocSysObject

For example:



Allocating your own hooks is no longer desirable.

Quote:

Or maybe there's a configure script somewhere that is supposed to generate those files. Headers called config.h are often created a by a configure script that is designed to generate the right config for the current platform.

Hans

@salas00
Quote:

I remember that one of the points to have "HookEntry" in the code, is to be portable without code changes, and without using of the SDI macros. I do not know through why sometime coders do not use SDI macroses, maybe there some problems with it, dunno, or maybe some estetic reassons like how cool to see old os3 code which works everythere , or maybe to do that strange 68k-ppc mess (like calling from ppc 68k hooks). The latest i can find necessary in only something like let's say mui, when some classes are 68k still, and need to use it still. But that for sure not excuse, as everything should be native in end.

I just remember on aw.net was some "hot" talks about differences beetwen all the hooks, and one of the points of opponents was that "hookentry" not implemented in os4 at all, and thats the reasson why simplemail author (SBA) make an assembler version of it (here). I then write mail to SBA and ask why he at all do it, and he say that it was done long ago, just for some old version of the exec.library, which back in past do not have it implemented. And so, i understand it like now it is implemented. I didn't test it, but have some pure technical interest to know for sure if it in exec now, or never was and never will (if someone have some info about, plz share it)

@broadblues
Quote:
Andy, can you explain a bit more please about ? I just always think that on amigaos you have 2 ways of using those callback hooks:

1. Any fucntion which provide hooking functionality
2. Manuall usage of CallHook from utility.library (and all the other function which provide hooking functionality anyway in end use CallHook).

So that all kind of manual usage all the time. And i assume your example in end as well use CallHook (just programmer do not know about).

@kas1le

I don't pretend to be an expert on hooks. So there may well be errors here.

Hooks can be divided into two sides allocating the hook and filling out the structure with functions for one and the second side is calling the hook.

The second side is easy. Under AmigaOS4 you *must not* call the hook function directly. You *MUST* use IUtility->CallHookPkt() (or the varags version IUtility->CallHook())

IUtility->CallHookPkt() takes care of whatever calling convention is required by the hook (invoking the emulator for 68k etc etc)

The First side is the more complex IMHO

Originaly you could create a hook structure on the stack (dangerous) or with static allocation or by called AllocMem etc yourself, this will still work but is discouraged, instead you should use the new function AllocSysObject() as I described above. This handles allocating the right memory type and any resource tracking etc etc and fills in the structure for you.

You still need to provide the HookEntry and subEntry points. These behave differently for PPC and 68k

For 68k hooks the Hookentry is called with the arguments on the stack

A0 = Pointer to Hook
A2 = Object
A1 = Message

For 68k Here argument order is not critical as you specify

For PPC Hooks the arguments are put on the stack I think, or if not perhaps they follow the sysV ABI so argument order is mandatory you hookentry *must* be written thus

ULONG HookEntry(struct Hook *hoo, APTR object , APTR message)

Refering back to my DEV CD RKMs to make sure the purpose of the HookEntry is to call the subEntry which is the real code and which may be written in *any high level language* so it takes the Hook call and translates the parameters to a format the language can understand. Most often that would be to push them onto the stack for a C function call (after all most high level languages find their way back to C at some level).

For PPC hooks the caling convention of the HookEntry and subEntry are the same so get the hookEntry to call the subentry is somewhat redundant (if writtent in C), but for 68k that is not so.

To what extent you really could call a Hook written in a non C I don't know, something called with CallHook should always work (if your HookEntry is written correctly) if the calling side is cheating it likely won't.

So what it boils down to for AmigaOS4 is:

1. Allways Allocate your Hook structure with AllocSysTags()

2. Allways Ensure you Hook is prototyped ULONG HookEntry(struct Hook * hook, APTR object, APTR message)

3. Allways call Hooks using IUtility->CallHookPkt()

Clear as mud huh?

@broadblues, kas1e

Quote:

Yes and no The -lauto switch can be useful when writing quick proof-of-concept code in which you don't want to bother with opening libs. It also makes code examples cleaner and focused. However, in real software it's recommended to open the libraries yourself, to acquire full control over system resources and provide proper error handling. Most developers have their own library opening routines already written so not using -lauto means little extra work.

When referring to my ReAction tutorial, things must be read in full context. For a proper opening of ReAction classes libauto is really deprecated - the reason being that it doesn't work! Or rather: it doesn't give you what it should. Libauto opens classes like libraries, that is, using OpenLibrary(). This of course works because classes are libraries but the catch is that the opening call will only give you the library pointer, not the class pointer. For OS4-compliant ReAction programming, classes must be opened via OpenClass(), which libauto doesn't support.

@rebraist Quote:
If you don't mind using a programming language other than C, then PortablE is one solution. It hides all AmigaOS4's interface "junk", so that the same code can usually be compiled on AmigaOS3, AmigaOS4, AROS & MOS.

If you open a library, then on OS4 it's inteface is automatically opened (without using -lauto).