startup getmainargs

[nullplan]

If the compiler uses - or can use - stack calling convention, then:

#define va_arg(ap, type) *(type *)(ap += sizeof(type), ap - sizeof(type))

Wow, such portable! It doesn't work on any platform I know except i386.

My application suite doesn't pass "short",

That is no issue because the type given to va_arg must be a promoted type, i.e. int or bigger. GCC warns me that executing va_arg(ap, short) will abort at run time.

[iProgramInCpp]

I was thinking more along the lines of having the entry point be inside (the equivalent of) msvcrt.dll. This is actually how dynamic linking works in Linux: dynamically linked ELF executables specify that ld-linux.so contains the entry point.

In Win32 applications, main() is called by a function that goes by either `_mainCRTStartup` or `_start` or `start` (I believe it depends on which compiler toolset it was compiled with). But that function is linked into the application.

Dynamic linking on Windows works in basically the same way as on Linux, yes, but the thing doing the loading is not msvcrt.dll. It's actually ntdll.dll. When a process is created, the main thread's first instruction is in ntdll.dll. Then, it loads all of the DLLs, and then the application. For each of the DLLs, its entry point (DllMain) is called with DLL_PROCESS_ATTACH (well, er, again, _DllMainCRTStartup etc), and then the application's entry point is called, which eventually calls main().

Universal across all compilers and linkers worldwide.

All compilers... that implement the C90 standard in a way that completely abides by the standard?

[kerravon]

If you write a C90-compliant application - I have an OS for you. What more do you want?

If applications are only ever going to use plain C90 APIs, why are you copying some other OS's APIs?

Ok, so traditional PDOS-generic *doesn't* copy some other OS's API.

So I assume this is a question about why I am copying TOS APIs, as one example.

That is so that I can have a bunch of TOS executables - my entire repertoire of apps - all written in C90 - and be able to turn up to a real TOS machine, or a PDOS-generic-with-TOS-extensions machine (which is basically any 68000 machine or any 68000 emulator).

So if someone hires me to work on a real Atari, for me, nothing changes at all. I may as well be working on an 80386. All my tools - hexdump - anything - work unchanged.

Ditto MVS etc.

I would need permission to install those executables, but that is a human issue, not a technical issue. I'm interested in the technical issue.

Or it may not be hired. For some reason I may be sitting in front of an Atari and that's all I have. No problem. I continue without any interruption.

[kerravon]

If the compiler uses - or can use - stack calling convention, then:

#define va_arg(ap, type) *(type *)(ap += sizeof(type), ap - sizeof(type))

Wow, such portable! It doesn't work on any platform I know except i386.

It works on S/370, 68000 and x86. Those are the 3 platforms I traditionally used.

Recently (several years) I started using ARM, and SubC only does stack-based code generation, and I have an ARM target for SubC. I also have a version of gcc 3.2.3 that does stack-based ARM. Being stack-based isn't an issue - I have assembler code for when I want to call a Linux API that takes parameters from the stack and puts them into specific registers.

In other words - it can work fine on ARM too.

And can work on any other "platform" too - but if I am using an existing compiler, then I am at their mercy. But an existing compiler will also come with builtins to handle that, so I need to add what - 5 lines of code to a PDPCLIB header and I'm done? Not an issue.

[kerravon]

Universal across all compilers and linkers worldwide.

All compilers... that implement the C90 standard in a way that completely abides by the standard?

I don't understand your point - yes, I expect C90 to be fully supported - and I'm very used to seeing 100% C90 compliance - ie I haven't been able to fault any commercial compiler really, for decades. I found some issues with Microsoft C 5.1, but not with Microsoft C 6.0 (1990). Microsoft C 6.0 claims itself that it is not 100% compliant, but I personally haven't encountered an issue, so unless I look up the documentation, I don't know what's wrong with it.

But to answer your question - no, for my purposes it doesn't need to be 100% compliant. It only needs to be sufficiently compliant to compile my code and tools. I am trying to create a "starter system" that allows you to go in any direction you want, writing in C90 instead of assembler or machine code.