Where is the SDK?

But you're going to do that anyway, right?

Mentioning it in the documentation somewhere would be helpful.

ssolie wrote:
@Hans
Quote:

Mentioning it in the documentation somewhere would be helpful.

Perhaps you should read the migration guide again. I believe it is fully explained why varargs are handled the way they are in that document which has has been included with every SDK.

Actually, I now have one thing that could be clarified
in the documentation. I had some trouble using
ILocale->FormatString() because I was using varargs.
It seems that the PowerPC version of AmigaOS has two
versions of varargs, the standard one and
va_startlinear()/va_getlinearva().
You also have to use the VARARGS68K macro.

Why this extra complication? Mentioning it in the
documentation somewhere would be helpful.

dataStream - a stream of data that is interpreted according to
the format string. Often this is a pointer into
the task's stack.

TetiSoft wrote:
@Hans

The SDK:Documentation/Developer Info/General/os4_migration_guide.pdf
file explains that the varargs handling of the PPC SysV ABI
is incompatible to the varargs handling of the 68k.
It also explains that VARARGS68K has to be used when
backwards compatibility is needed. All OS4 system functions
are declared with the VARARGS68K attribute in the
<include/interfaces/something.h> files so I thought it
would be common knowledge that the "normal" C varargs
handling cant be used with any existing OS4 system function.

Suggestions how to modify the existing doc
Quote:

dataStream - a stream of data that is interpreted according to
the format string. Often this is a pointer into
the task's stack.

are welcome

Just add a note about the VARARGS68k thing and point to the OS4 migration guide

VOID?ped_Init(void)
VOID?ped_Expunge(void)
LONG?ped_Open(void)
VOID?ped_Close(void)

LONG?ped_Init(struct?PrinterData?*?pd)
VOID?ped_Expunge(VOID)
LONG?ped_Open(struct?printerIO?*?ior)
VOID?ped_Close(struct?printerIO?*?ior)

VOID?DriverExpunge(VOID)
VOID?DriverInit(struct?PrinterData?*?pd)
VOID?DriverClose(struct?printerIO?*ior)
LONG?DriverOpen(struct?printerIO?*ior)

devices/prtbase.h: strange functionpointers in struct PrinterExtendedData.
Quote:
VOID ped_Init(void)
VOID ped_Expunge(void)
LONG ped_Open(void)
VOID ped_Close(void)

In the Comments of the pointers:
Quote:
LONG ped_Init(struct PrinterData * pd)
VOID ped_Expunge(VOID)
LONG ped_Open(struct printerIO * ior)
VOID ped_Close(struct printerIO * ior)

And finally in the Printerdriver Example from the NDK3.9:
Quote:
VOID DriverExpunge(VOID)
VOID DriverInit(struct PrinterData * pd)
VOID DriverClose(struct printerIO *ior)
LONG DriverOpen(struct printerIO *ior)

A note on the function pointers in these data structure definitions:
unless otherwise specified, all functions expect that their parameters
are passed on the *stack* rather than in CPU registers. Every parameter
must be passed a 32 bit long word, i.e. an "UWORD" will use the same
stack space as an "ULONG".

When the printer driver is PPC native, the function pointers will
point to PPC native functions, otherwise to 68K stubs or functions.
[...]
When the printer driver is PPC native, the function pointers
point to PPC native functions.
[...]
/* called after LoadSeg, returns zero for success:
*
* LONG ped_Init(struct PrinterData * pd);
*/
[...]
/* called before UnLoadSeg:
*
* VOID ped_Expunge(VOID);
*/
[..]
/* called at OpenDevice, returns zero for success:
*
* LONG ped_Open(struct printerIO * ior);
*/
[..]
/* called at CloseDevice:
*
* VOID ped_Close(struct printerIO * ior);
*/
[...]
Starting with printer.device 51.12 PPC native printer drivers
are supported. Those must contain a global symbol "PrinterSegment"
which defines the start of the struct PrinterSegment, to keep this
in the binary, driver writers can call "strip -KPrinterSegment ...".

LONG SAVEDS STDARGS
DriverInit(struct PrinterData * pd)
[...]
VOID SAVEDS STDARGS
DriverExpunge(VOID)
[...]
LONG SAVEDS STDARGS
DriverOpen(union printerIO *ior UNUSED)
[...]
VOID SAVEDS STDARGS
DriverClose(union printerIO *ior UNUSED)

checkbox_gc.doc: GA_Selected method OM_GET is missing.