On Sun, 2 May 2021 06:46:17 -0700 (PDT), muta...@gmail.com wrote:
>
> It can be helped. You can avoid the middle component,
> the OS, needing to be changed.

If you don't want to offload the code to the kernel, then yes.

> And the command interpreter is not necessarily on
> either side of that exec() call either.

Not the command line interpreting part. That's irrelevant. It's the program
executing part.

> Going from 8080 CP/M to 8086 MSDOS required conversion
> of code at the assembler source level.

Yes, assuming that the program was created using pure Assembly.

> How do you propose doing a transition from 16-bit
> MSDOS to 32-bit theoretical MSDOS?
>
> Starting with applications that are calling exec()
> in either assembler or C.
....
> Ok, I forgot to mention something there.
>
> I am talking about 16-bit MSDOS programs that were
> written with a reasonably clean (I'm willing to negotiate,
> nothing is set in stone) Pos* interface, and then
> porting those to 32-bit MSDOS.
>
> There is a reasonably clean PosExec() for 16-bit MSDOS,
> but the caller and called will both need to adjust for
> 32-bit MSDOS. I don't see any reasonable way of avoiding
> that, and I don't know what the proposed alternative is
> anyway.

The pointer interpretation is entirely different for both platforms. You'll
juat have to treat pointers differently for each platform. e.g. for 16-bit
DOS, HiWord of the pointer is the Segment, and LoWord of the pointer is the
Offset; and for 32-bit DOS, HiWord is the upper 16 bits of the 32-bit flat
address, and LoWord is the lower 16 bits of the 32-bit flat address.
Assuming that pointer for the 32-bit DOS is a flat address.

On Tuesday, May 4, 2021 at 1:47:20 AM UTC+10, JJ wrote:

> > It can be helped. You can avoid the middle component,
> > the OS, needing to be changed.

> If you don't want to offload the code to the kernel, then yes.

The entirety of the code can't be offloaded from
either the caller or the callee. The only thing you
can entirely offload is the kernel, and that
actually maximizes the usefulness of it.

> > And the command interpreter is not necessarily on
> > either side of that exec() call either.

> Not the command line interpreting part. That's irrelevant. It's the program
> executing part.

I'm talking about the program execution.

PROGA can exec() PROGB without either the kernel
or command.com being involved.

> > There is a reasonably clean PosExec() for 16-bit MSDOS,
> > but the caller and called will both need to adjust for
> > 32-bit MSDOS. I don't see any reasonable way of avoiding
> > that, and I don't know what the proposed alternative is
> > anyway.

> The pointer interpretation is entirely different for both platforms. You'll
> juat have to treat pointers differently for each platform. e.g. for 16-bit
> DOS, HiWord of the pointer is the Segment, and LoWord of the pointer is the
> Offset; and for 32-bit DOS, HiWord is the upper 16 bits of the 32-bit flat
> address, and LoWord is the lower 16 bits of the 32-bit flat address.
> Assuming that pointer for the 32-bit DOS is a flat address.

There is no LoWord in the existing 16-bit MSDOS
exec() parameter block.

In any proposed solution of "how to write MSDOS
programs" I'm expecting to produce a 16-bit
executable that actually works on say real
MSDOS 3.2.

Starting from the above, how do you minimize the
amount of changes required to support a future
32-bit MSDOS? ie the year is 1986. MSDOS 3.2
was just released, and so was the 80386. Gates
just announced he will produce a 32-bit version
of MSDOS, but the exact details haven't been
announced yet.

You're a friend of Gates. You can influence him on
both the design of 32-bit MSDOS and on coding
standards for 16-bit MSDOS programming to make
the transition back and forth to 32-bit as easy as
possible. In any application there will be two distinct
executables created - one for 8086 16-bit MSDOS
and one for 80386 32-bit MSDOS.

Do you have a proposal?

Note that OS/2 1.0 had a "family API" for the same
executable to work on both MSDOS and OS/2, but
that's not a goal here.

BFN. Paul.

On Mon, 3 May 2021 09:11:22 -0700 (PDT), muta...@gmail.com wrote:
>
> The entirety of the code can't be offloaded from
> either the caller or the callee.

Not the entire code. Only part of it. The CMDLINE creation part.

> The only thing you
> can entirely offload is the kernel, and that
> actually maximizes the usefulness of it.

That would be no different that a bootable application which use its own
private OS. Basically an OS, but isolated.

> I'm talking about the program execution.
>
> PROGA can exec() PROGB without either the kernel
> or command.com being involved.

Offloading the CMDLINE creation code to the kernel which makes the kernel
part of the components, was just a suggestion. It's up to you to decide
whether to choose bigger kernel, or bigger applications; because the code
has to be placed somewhere.

> There is no LoWord in the existing 16-bit MSDOS
> exec() parameter block.

I was referring to your PDOS' pointer type in general.

> Starting from the above, how do you minimize the
> amount of changes required to support a future
> 32-bit MSDOS? ie the year is 1986. MSDOS 3.2
> was just released, and so was the 80386. Gates
> just announced he will produce a 32-bit version
> of MSDOS, but the exact details haven't been
> announced yet.

It's why I asked about the pointer type of your PDOS.

On Tuesday, May 4, 2021 at 9:50:58 PM UTC+10, JJ wrote:

> > The entirety of the code can't be offloaded from
> > either the caller or the callee.

> Not the entire code. Only part of it. The CMDLINE creation part.

Ok, true, you can do that. But if you do that, you can
avoid the CMDLINE altogether and just create a new
INT 21H function, can't you? And maybe that is the
superior solution, so that we can fix this "envseg"
issue in the parm block at the same time.

> > The only thing you
> > can entirely offload is the kernel, and that
> > actually maximizes the usefulness of it.

> That would be no different that a bootable application which use its own
> private OS. Basically an OS, but isolated.

Well I guess that's what it is. It's a very small OS that
knows about CMDLINE, even though MSDOS 3.2
does not.

Maybe at some level there is no distinction between
OS and application?

> > I'm talking about the program execution.
> >
> > PROGA can exec() PROGB without either the kernel
> > or command.com being involved.

I misspoke above. The kernel is still involved, it just
doesn't know about CMDLINE.

> Offloading the CMDLINE creation code to the kernel which makes the kernel
> part of the components, was just a suggestion. It's up to you to decide
> whether to choose bigger kernel, or bigger applications; because the code
> has to be placed somewhere.

I don't care about the size of either. What I care about is
compatibility.

> > There is no LoWord in the existing 16-bit MSDOS
> > exec() parameter block.

> I was referring to your PDOS' pointer type in general.

> > Starting from the above, how do you minimize the
> > amount of changes required to support a future
> > 32-bit MSDOS? ie the year is 1986. MSDOS 3.2
> > was just released, and so was the 80386. Gates
> > just announced he will produce a 32-bit version
> > of MSDOS, but the exact details haven't been
> > announced yet.

> It's why I asked about the pointer type of your PDOS.

Well, I'm willing to negotiate, but my opening offer, which
is what the PDOS/386 source code currently in sourceforge
does, now that I have fixed binutils 2.14a to stop stripping
relocation information, so that I could disable the VM code
that Alica wrote, is at the same level as 16-bit MSDOS - the
OS and applications all see the exact same flat memory
space, starting at location 0 (ie where you will find real
mode interrupt vectors, which are not the protected mode
interrupt vectors, which are currently not in a fixed location
so can't be directly manipulated by applications - but that's
not necessarily a bad thing).

Very simple. No memory protection. You can write directly
to 0xb8000 and the SVGA graphics card without any fuss
at all. As you can in 16-bit MSDOS if you make it
0xb800:0x0000

This is 32-bit MSDOS, not 32-bit Windows.

Actually I have a 32-bit Windows proposal too, but forget
about that for now, and let's agree what 32-bit MSDOS
should look like.

BFN. Paul.

On Tue, 4 May 2021 08:39:23 -0700 (PDT), muta...@gmail.com wrote:
>
> Ok, true, you can do that. But if you do that, you can
> avoid the CMDLINE altogether and just create a new
> INT 21H function, can't you? And maybe that is the
> superior solution, so that we can fix this "envseg"
> issue in the parm block at the same time.

Sure, the CMDLINE can be omitted and be replaced with a more elegant method,
but didn't you said you want to make it easy to port programs to your OS? If
you remove CMDLINE, you'll have more work porting those programs.

> I don't care about the size of either. What I care about is
> compatibility.

In your case, there's no way to keep 100% compatibility due to platform
difference. What you can do is to minimize the incompatibilities due to that
- if you care about compatibility.

> Well, I'm willing to negotiate, but my opening offer, which
> is what the PDOS/386 source code currently in sourceforge
> does, now that I have fixed binutils 2.14a to stop stripping
> relocation information, so that I could disable the VM code
> that Alica wrote, is at the same level as 16-bit MSDOS - the
> OS and applications all see the exact same flat memory
> space, starting at location 0 (ie where you will find real
> mode interrupt vectors, which are not the protected mode
> interrupt vectors, which are currently not in a fixed location
> so can't be directly manipulated by applications - but that's
> not necessarily a bad thing).
>
> Very simple. No memory protection. You can write directly
> to 0xb8000 and the SVGA graphics card without any fuss
> at all. As you can in 16-bit MSDOS if you make it
> 0xb800:0x0000
>
> This is 32-bit MSDOS, not 32-bit Windows.
>
> Actually I have a 32-bit Windows proposal too, but forget
> about that for now, and let's agree what 32-bit MSDOS
> should look like.

OK.

So, what if you treat segment fields as the upper 16-bit of the 32-bit flat
address?

On Wednesday, May 5, 2021 at 8:05:40 PM UTC+10, JJ wrote:

> > Ok, true, you can do that. But if you do that, you can
> > avoid the CMDLINE altogether and just create a new
> > INT 21H function, can't you? And maybe that is the
> > superior solution, so that we can fix this "envseg"
> > issue in the parm block at the same time.

> Sure, the CMDLINE can be omitted and be replaced with a more elegant method,
> but didn't you said you want to make it easy to port programs to your OS? If
> you remove CMDLINE, you'll have more work porting those programs.

Sure, it's a tradeoff. I'm not expecting every MSDOS
program to work unchanged in the transition from
16-bit to 32-bit.

But e.g. every MSDOS program that was written in C90
will port with zero changes whatsoever, other than the
C library itself, which is to be expected.

But C90 doesn't give you the ability to retrieve file
attributes. But can that be done in a portable manner,
sticking reasonable close to INT 21H AH=43H. All it
needs is a wrapper function, ie:

int PosGetFileAttributes(const char *fnm,int *attr)

That seems perfectly reasonable to me. Gates could
have created that API function above and told everyone
to start using that instead of setting ds/dx manually,
in preparation for a move to 32-bit, and even a move
to 64-bit. The function above will work even for 256-bit.

So to the question of CMDLINE - I don't think much
application code is spend doing direct exec() calls
with long parameters. It is more likely to be hidden
in a system() call, so you just need the C runtime
library author to make that change, once.

I really don't care how difficult it is for a C runtime
library author to convert from 16-bit MSDOS to
32-bit and 64-bit. I only care about the application
programmer.

> > I don't care about the size of either. What I care about is
> > compatibility.

> In your case, there's no way to keep 100% compatibility due to platform
> difference. What you can do is to minimize the incompatibilities due to that

That's true for the 32-bit move, but the CMDLINE
solution works even for old versions of 16-bit
MSDOS, which seems like a good solution to me.

> > Very simple. No memory protection. You can write directly
> > to 0xb8000 and the SVGA graphics card without any fuss
> > at all. As you can in 16-bit MSDOS if you make it
> > 0xb800:0x0000
> >
> > This is 32-bit MSDOS, not 32-bit Windows.
> >
> > Actually I have a 32-bit Windows proposal too, but forget
> > about that for now, and let's agree what 32-bit MSDOS
> > should look like.

> OK.
>
> So, what if you treat segment fields as the upper 16-bit of the 32-bit flat
> address?

Is this just for exec() or in general?

It's a lot of work to go to just for exec(), and it still won't
work anyway. Because if you only provide the upper
16 bits, it means you need to be able to allocate memory
on a 64k boundary, requiring a non-standard call. As soon
as you start doing non-standard stuff, you may as well
just write the conditional code.

In addition, when you move to 64-bit, you will be presented
with the same problem. Are you going to make the segment
the upper 16 bits of a 64-bit address? Or perhaps arrange
for memory allocation below 4 GB so that the upper 32 bits
are all 0, the next 16 bits will come from the segment, and
the lower 16 bits will be 0. This manipulation requires
conditional compilation. And basically buys nothing.

BFN. Paul.

On Wed, 5 May 2021 04:52:25 -0700 (PDT), muta...@gmail.com wrote:
>
> I really don't care how difficult it is for a C runtime
> library author to convert from 16-bit MSDOS to
> 32-bit and 64-bit. I only care about the application
> programmer.

Well you can't have both an entirely different specification, and
compatibility. You'll have to choose one and sacrifice the other. Whichever
is easier for software developers.

> Is this just for exec() or in general?

I meant DOS data structures which have segment fields instead of pointer
fields. IOTW, special handling for those type of DOS structures only.
Nothing more.

> It's a lot of work to go to just for exec(), and it still won't
> work anyway. Because if you only provide the upper
> 16 bits, it means you need to be able to allocate memory
> on a 64k boundary, requiring a non-standard call.

That is the downside, unfortunately.

Either way, it's like what I've mentioned earlier. You can't have both.
You'll have to choose one. Do you want to keep DOS compatibility, or (third
party) software compatibility? Whichever it's easier for the software
developer.

On Thursday, May 6, 2021 at 8:58:56 PM UTC+10, JJ wrote:

> > I really don't care how difficult it is for a C runtime
> > library author to convert from 16-bit MSDOS to
> > 32-bit and 64-bit. I only care about the application
> > programmer.

> Well you can't have both an entirely different specification, and
> compatibility. You'll have to choose one and sacrifice the other. Whichever
> is easier for software developers.

I'm having trouble understanding your position.

What options are available for software developers,
just considering these two "concepts":

int PosGetFileAttributes(const char *fnm, int *attr)
0x43

void PosExec(char *prog, POSEXEC_PARMBLOCK *parmblock)
0x4b

Noting that we want to support 16, 32 and 64-bit
versions of MSDOS, and we expect a recompile
of applications for each of those 3 targets.

> > Is this just for exec() or in general?

> I meant DOS data structures which have segment fields instead of pointer
> fields. IOTW, special handling for those type of DOS structures only.
> Nothing more.

I don't think there are many of those.

> > It's a lot of work to go to just for exec(), and it still won't
> > work anyway. Because if you only provide the upper
> > 16 bits, it means you need to be able to allocate memory
> > on a 64k boundary, requiring a non-standard call.

> That is the downside, unfortunately.

The downside is the same either way, so you may as
well use the opportunity to do it properly.

> Either way, it's like what I've mentioned earlier. You can't have both.
> You'll have to choose one. Do you want to keep DOS compatibility, or (third
> party) software compatibility? Whichever it's easier for the software
> developer.

It depends what you mean by "DOS compatibility".

I'm not expecting 32-bit software to run on 16-bit
hardware, and vice-versa.

That's an assumption I didn't think to voice out, sorry,
so may alter your answer.

BFN. Paul.

On Thu, 6 May 2021 09:12:40 -0700 (PDT), muta...@gmail.com wrote:
>
> It depends what you mean by "DOS compatibility".
>
> I'm not expecting 32-bit software to run on 16-bit
> hardware, and vice-versa.

If you think "DOS compatibility" is a hardware related, then I give up.