startup getmainargs

[kerravon]

So win32 executables using msvcrt.dll need to do this (or similar):


https://sourceforge.net/p/pdos/gitcode/ ... w32start.c

__getmainargs(&argc, &argv, &environ, 0, &startinfo);
status = main(argc, argv);
exit(status);


I didn't really like that, so for PDOS-generic I created this:

https://sourceforge.net/p/pdos/gitcode/ ... pgastart.c

*__os->main = main;
return (__os->__start(0));


With MVS work that I am about to start, I realized I have a problem.

I can't tell whether an executable is PDOS-generic (ie the C runtime library isn't in the executable), or whether it is native MVS (the MVS-specific C runtime library is in the executable, and the PDOS-generic parameter is more-or-less just used to retrieve the SVC callback so that when it is time to do an MVS call via SVC (equivalent of INT xx on the 80x86), it does a callback to PDOS-generic instead of a real SVC).

My plan is to call the MVS executable with a parameter of 0xffffffff instead of the normal parameter containing the command line argument. And a "properly written" (TM) MVS application is expected to detect that and make use of the PDOS-generic second parm. Another option would be to make the first parameter on an odd address, and the startup code is meant to detect that and subtract 1 to get the PDOS-generic parameter, and then add 4 to get the normal parameter.

However, either way, I need to have done the start() processing myself before calling the executable, so that my runnum can be increased so that I know what files have been opened by this program, so that I can automatically close them.

And then when the application starts, it will be doing its own MVS-specific start() call to open SYSPRINT etc.

One day PDOS-generic may put in real SVC handlers to allow at least some non-PDOS-generic-aware programs to run, in which case I would stop fudging the parameters as an option in the OS itself.

Anyway, I am now considering making the MVS startup code to look the same as Win32. Allowing for theoretical DLLs on MVS too.

And it occurs to me that this (ie Win32 startup code) should in fact be some fundamental part of computer science (I think Windows NT was created by a DEC designer or something - maybe some computer science concept was carried across). I'm not aware of the concept myself, but I'm presumably stumbling into it now. Just thought I'd ask if it is a well-known concept that Win32 programs abide by, and it wasn't known at MSDOS time or whatever. Specifically you do a call to get the arguments and then you execute main. The startup code - if any - would need to exist in getmainargs.

[Octocontrabass]

And it occurs to me that this (ie Win32 startup code) should in fact be some fundamental part of computer science (I think Windows NT was created by a DEC designer or something - maybe some computer science concept was carried across).

I don't think so. If anything, Microsoft probably would have preferred to have C programs export a main() symbol that would be called by msvcrt.dll so no one would be able to see internal functions like getmainargs().

Specifically you do a call to get the arguments and then you execute main.

"You" don't do those things, your C standard library does. The only reason you're doing those things for your programs is because you're implementing (part of) the C standard library.

The startup code - if any - would need to exist in getmainargs.

The startup code is whatever runs before calling main(). Most of the startup code could be hidden in a function like getmainargs(), but the code calling getmainargs() is still part of the startup code.