I see some documentation for DOS 4.0 here:

https://pcdosretro.github.io/multitaskingmsdos4.htm

It says NE executables don't have a PSP.

Is there another way of retrieving:

1. The command line (I believe this would have predated
the use of CMDLINE).

2. The environment pointer.

Thanks. Paul.

On Tue, 27 Feb 2024 06:12:29 +0800, Paul Edwards wrote:
> I see some documentation for DOS 4.0 here:
>
> https://pcdosretro.github.io/multitaskingmsdos4.htm
>
> It says NE executables don't have a PSP.
>
> Is there another way of retrieving:
>
> 1. The command line (I believe this would have predated
> the use of CMDLINE).
>
> 2. The environment pointer.
>
> Thanks. Paul.

OS/2 v1.0's SDK might shed some light. Assuming that it's available
somewhere.

On 28/02/24 03:29, JJ wrote:
> On Tue, 27 Feb 2024 06:12:29 +0800, Paul Edwards wrote:
>> I see some documentation for DOS 4.0 here:
>>
>> https://pcdosretro.github.io/multitaskingmsdos4.htm
>>
>> It says NE executables don't have a PSP.
>>
>> Is there another way of retrieving:
>>
>> 1. The command line (I believe this would have predated
>> the use of CMDLINE).
>>
>> 2. The environment pointer.
>>
>> Thanks. Paul.
>
> OS/2 v1.0's SDK might shed some light. Assuming that it's available
> somewhere.

What relevance is OS/2 v1.0 to MSDOS?

Thanks. Paul.

On Wed, 28 Feb 2024 12:00:44 +0800, Paul Edwards wrote:
> On 28/02/24 03:29, JJ wrote:
>> On Tue, 27 Feb 2024 06:12:29 +0800, Paul Edwards wrote:
>>> I see some documentation for DOS 4.0 here:
>>>
>>> https://pcdosretro.github.io/multitaskingmsdos4.htm
>>>
>>> It says NE executables don't have a PSP.
>>>
>>> Is there another way of retrieving:
>>>
>>> 1. The command line (I believe this would have predated
>>> the use of CMDLINE).
>>>
>>> 2. The environment pointer.
>>>
>>> Thanks. Paul.
>>
>> OS/2 v1.0's SDK might shed some light. Assuming that it's available
>> somewhere.
>
> What relevance is OS/2 v1.0 to MSDOS?
>
> Thanks. Paul.

It's relevant to Multitasking MS-DOS. Not MS-DOS.

Multitasking MS-DOS and MS-DOS are architecturely quite different, and quite
incompatible with MS-DOS.

https://betawiki.net/wiki/Multitasking_MS-DOS_4

PS) the above article describe the subject much more in-depth than
Wikipedia.

Resending - ES was down ...

On 28/02/24 14:52, JJ wrote:

> https://betawiki.net/wiki/Multitasking_MS-DOS_4
>
> PS) the above article describe the subject much more in-depth than
> Wikipedia.

Thanks. I read the article in full, but it didn't
explain how to get the command line or environment
variables - so as you said, maybe the OS/2 1.0 SDK
has some clues.

I know how to get these things in OS/2 1.0, but
the syscall:

DosGetEnv(&seg, &offs)

is not one of the ones available for MT MSDOS
that I saw.

But the above two values are also in AX and BX
on program entry for OS/2 1.0:

https://retrocomputing.stackexchange.com/questions/26111/initial-contents-of-cpu-registers-at-os-2-1-x-program-startup

And that references RBIL:

https://fd.lod.bz/rbil/interrup/dos_kernel/214b.html

which is more general about "new executable" being
as above.

So I would guess that that means those registers are
the ONLY official way of retrieving both the environment
and the command line.

Which means the startup code for an application must be
written in assembler for MT MSDOS, unlike OS/2 1.x and
2.x which should be possible to do in C since registers
are not needed, and the stack can be ignored too, which
is helpful to me.

And the program name would presumably be at the end of
the environment block, as with MSDOS >3.

BFN. Paul.

On 28/02/24 19:42, Paul Edwards wrote:

> So I would guess that that means those registers are
> the ONLY official way of retrieving both the environment
> and the command line.
>
> Which means the startup code for an application must be
> written in assembler for MT MSDOS, unlike OS/2 1.x and
> 2.x which should be possible to do in C since registers
> are not needed, and the stack can be ignored too, which
> is helpful to me.
>
> And the program name would presumably be at the end of
> the environment block, as with MSDOS >3.

I just realized that for MSDOS (normal MZ) I should
be able to ignore the stack and the registers and
get the environment pointer and command line by
calling this:

DOS 3.0+ - GET CURRENT PSP ADDRESS
AH = 62h

And thus have the entry point as C code.

Note that I have managed to get rid of my dependence on
the traditional Unix stack (which PDOS/386 does not
provide), for my Linux ELF programs too. And have
system() working too, even though PDOS/386 doesn't provide
a fork(). (it now has a dummy fork though).

And then for all PDOS environments I will be able to
switch in the PDOS-generic stack and still have
"properly written" executables (still conforming to
the specs of existing OSes) run. While allowing
PDOS-generic apps to run too.

BFN. Paul.

On 28/02/24 19:42, Paul Edwards wrote:

> I know how to get these things in OS/2 1.0, but
> the syscall:
>
> DosGetEnv(&seg, &offs)
>
> is not one of the ones available for MT MSDOS
> that I saw.
>
> So I would guess that that means those registers are
> the ONLY official way of retrieving both the environment
> and the command line.
>
> Which means the startup code for an application must be
> written in assembler for MT MSDOS, unlike OS/2 1.x and
> 2.x which should be possible to do in C since registers
> are not needed, and the stack can be ignored too, which
> is helpful to me.

I spoke too soon about OS/2 2.x. It turned out that
DosGetEnv was not available.

For a while I thought I would be in the same boat
as MSDOS 4.0 - required to rely on the stack on
entry to the program (which I don't want to do,
because I want to redefine that for PDOS-generic).

After a lot of looking, I found how to do it
another way:

#ifdef __16BIT__
{
USHORT seg, offs;

if (DosGetEnv(&seg, &offs) != 0)
{
p = "\0"; /* two NUL characters */
}
else
{
p = (char *)(((unsigned long)seg << 16)
| offs);
}
}
#else
{
PIB *pib;

if (DosGetInfoBlocks(NULL, &pib) != 0)
{
p = "\0"; /* two NUL characters */
}
else
{
/* skip three 32-bit values and then you get a
pointer to the command line */
p = pib->pib_pchcmd;
}
}
#endif

I didn't see an equivalent of DosGetInfoBlocks
for MSDOS 4.0, so I still may be dependent on
the registers on entry to the NE executable.
I don't know if I can still get an "artificial"
PSP for an NE executable on MSDOS 4.0 by calling
the appropriate INT 21H.

But it's not important to be able to support
MSDOS 4.0 anyway - which I don't have to test
(and don't bother sending me a link to it - I
know I can get it if I want a bootleg copy).

BFN. Paul.