From Newsgroup: comp.os.msdos.programmer

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.msdos.programmer

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.msdos.programmer

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.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.msdos.programmer

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.msdos.programmer

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.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.msdos.programmer

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.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.msdos.programmer

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.

--- Synchronet 3.21d-Linux NewsLink 1.2