Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Life is difficult because it is non-linear.


devel / comp.os.msdos.programmer / extending parameters

SubjectAuthor
* extending parametersmuta...@gmail.com
+* Re: extending parametersJJ
|`* Re: extending parametersJJ
| `* Re: extending parametersmuta...@gmail.com
|  `* Re: extending parametersJJ
|   `* Re: extending parametersJJ
|    `* Re: extending parametersmuta...@gmail.com
|     `* Re: extending parametersJJ
|      `* Re: extending parametersmuta...@gmail.com
|       +* Re: extending parametersR.Wieser
|       |+- Re: extending parametersR.Wieser
|       |`* Re: extending parametersmuta...@gmail.com
|       | `* Re: extending parametersR.Wieser
|       |  `* Re: extending parametersmuta...@gmail.com
|       |   `* Re: extending parametersR.Wieser
|       |    `- Re: extending parametersmuta...@gmail.com
|       `* Re: extending parametersJJ
|        `* Re: extending parametersmuta...@gmail.com
|         `* Re: extending parametersJJ
|          `* Re: extending parametersmuta...@gmail.com
|           `* Re: extending parametersJJ
|            `* Re: extending parametersmuta...@gmail.com
|             `* Re: extending parametersJJ
|              `* Re: extending parametersmuta...@gmail.com
|               `* Re: extending parametersJJ
|                `* Re: extending parametersmuta...@gmail.com
|                 `- Re: extending parametersJJ
`- Re: extending parametersAlexei A. Frounze

Pages:12
extending parameters

<32913dab-8517-4ca2-8e4c-b7d01b517cb6n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=9918&group=comp.os.msdos.programmer#9918

  copy link   Newsgroups: comp.os.msdos.programmer
X-Received: by 2002:a05:622a:94:: with SMTP id o20mr21186040qtw.158.1619512538779;
Tue, 27 Apr 2021 01:35:38 -0700 (PDT)
X-Received: by 2002:a0c:f00d:: with SMTP id z13mr835872qvk.0.1619512538566;
Tue, 27 Apr 2021 01:35:38 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.os.msdos.programmer
Date: Tue, 27 Apr 2021 01:35:38 -0700 (PDT)
Injection-Info: google-groups.googlegroups.com; posting-host=202.169.113.201; posting-account=CeHKkQoAAAAowY1GfiJYG55VVc0s1zaG
NNTP-Posting-Host: 202.169.113.201
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <32913dab-8517-4ca2-8e4c-b7d01b517cb6n@googlegroups.com>
Subject: extending parameters
From: mutazi...@gmail.com (muta...@gmail.com)
Injection-Date: Tue, 27 Apr 2021 08:35:38 +0000
Content-Type: text/plain; charset="UTF-8"
 by: muta...@gmail.com - Tue, 27 Apr 2021 08:35 UTC

Looking at the code for PDPCLIB and PDOS,
it seems that when a program does a:

system("fred abc");

that the maximum length of "abc" is governed
by what can fit in the PSP, starting at 0x80,
which means from 128 bytes you need to
subtract 1 byte for the length indicator itself,
and 1 byte for a compulsory '\r', so there are
126 bytes for the caller, and that is what is put
in the first byte.

I'd like to support more than that. Actually the
limit of a single byte is enough for me at the
moment, ie 254, but maybe it should be extended
even further, ie if someone puts 255 in that spot,
it means that the real length is in cmd[1] and
cmd[2]. And if both of those are x'FF' then the
real length is in cmd[3..6].

Anyway, if the length is anything above 126, then
how about calling a new INT 21H function to
retrieve an "extended parameter"?

I see there is already an extension for PDOS/386,
and it is isolated in the AH=F6H for PDOS/x86
extensions. Maybe that's where it should stay.

Any suggestions on the best way forward?

Is there any prior art for this? Maybe I can just
copy an existing solution. Unless it has some
disadvantage.

Thanks. Paul.

/* F6,3F - Get Command Line String For The Current Process */
char *PosGetCommandLine(void)
{ union REGS regsin;
union REGS regsout;

regsin.h.ah = 0xF6;
regsin.h.al = 0x3F;

int86(0x21, &regsin, &regsout);
return ((char *)(regsout.d.eax));
}

Re: extending parameters

<oavz329kvjp5$.o2a75nvbugyr$.dlg@40tude.net>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=9921&group=comp.os.msdos.programmer#9921

  copy link   Newsgroups: comp.os.msdos.programmer
Path: i2pn2.org!i2pn.org!aioe.org!6eYFYPoi7ueEcuwV9LvI3A.user.gioia.aioe.org.POSTED!not-for-mail
From: jj4pub...@gmail.com (JJ)
Newsgroups: comp.os.msdos.programmer
Subject: Re: extending parameters
Date: Tue, 27 Apr 2021 18:21:30 +0700
Organization: Aioe.org NNTP Server
Lines: 15
Message-ID: <oavz329kvjp5$.o2a75nvbugyr$.dlg@40tude.net>
References: <32913dab-8517-4ca2-8e4c-b7d01b517cb6n@googlegroups.com>
NNTP-Posting-Host: 6eYFYPoi7ueEcuwV9LvI3A.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: 40tude_Dialog/2.0.15.84
X-Face: \*\`0(1j~VfYC>ebz[&O.]=,Nm\oRM{of,liRO#7Eqi4|!]!(Gs=Akgh{J)605>C9Air?pa d{sSZ09u+A7f<^paR"/NH_#<mE1S"hde\c6PZLUB[t/s5-+Iu5DSc?P0+4%,Hl
X-Notice: Filtered by postfilter v. 0.9.2
X-Bitcoin: 1LcqwCQBQmhcWfWsVEAeyLchkAY8ZfuMnS
 by: JJ - Tue, 27 Apr 2021 11:21 UTC

On Tue, 27 Apr 2021 01:35:38 -0700 (PDT), muta...@gmail.com wrote:
>
> I see there is already an extension for PDOS/386,
> and it is isolated in the AH=F6H for PDOS/x86
> extensions. Maybe that's where it should stay.
>
> Any suggestions on the best way forward?
>
> Is there any prior art for this? Maybe I can just
> copy an existing solution. Unless it has some
> disadvantage.

MS-DOS 7.x already specify a standard for this via CMDLINE environment
variable. It's also supported by the already popular 4DOS software. So, it
should be supported by all new DOS compatible OS projects.

Re: extending parameters

<1913a35d-cc86-475b-a2aa-282986c8fda0n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=9922&group=comp.os.msdos.programmer#9922

  copy link   Newsgroups: comp.os.msdos.programmer
X-Received: by 2002:ad4:5588:: with SMTP id e8mr23161767qvx.10.1619525382184;
Tue, 27 Apr 2021 05:09:42 -0700 (PDT)
X-Received: by 2002:a37:d4e:: with SMTP id 75mr22467612qkn.110.1619525382007;
Tue, 27 Apr 2021 05:09:42 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.os.msdos.programmer
Date: Tue, 27 Apr 2021 05:09:41 -0700 (PDT)
In-Reply-To: <32913dab-8517-4ca2-8e4c-b7d01b517cb6n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=24.4.130.174; posting-account=r_UqYQoAAADroB0Qe_EzH25J5Oyuce4G
NNTP-Posting-Host: 24.4.130.174
References: <32913dab-8517-4ca2-8e4c-b7d01b517cb6n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <1913a35d-cc86-475b-a2aa-282986c8fda0n@googlegroups.com>
Subject: Re: extending parameters
From: alexfrun...@gmail.com (Alexei A. Frounze)
Injection-Date: Tue, 27 Apr 2021 12:09:42 +0000
Content-Type: text/plain; charset="UTF-8"
 by: Alexei A. Frounze - Tue, 27 Apr 2021 12:09 UTC

On Tuesday, April 27, 2021 at 1:35:39 AM UTC-7, muta...@gmail.com wrote:
> Looking at the code for PDPCLIB and PDOS,
> it seems that when a program does a:
>
> system("fred abc");
>
> that the maximum length of "abc" is governed
> by what can fit in the PSP, starting at 0x80,
> which means from 128 bytes you need to
> subtract 1 byte for the length indicator itself,
> and 1 byte for a compulsory '\r', so there are
> 126 bytes for the caller, and that is what is put
> in the first byte.
>
> I'd like to support more than that. Actually the
> limit of a single byte is enough for me at the
> moment, ie 254, but maybe it should be extended
> even further, ie if someone puts 255 in that spot,
> it means that the real length is in cmd[1] and
> cmd[2]. And if both of those are x'FF' then the
> real length is in cmd[3..6].
....
> Any suggestions on the best way forward?

DJGPP had a few ways of doing it, look it up.
Smaller C uses the one where @foo on the command line
expands into the contents of file foo.

Alex

Re: extending parameters

<1m2w5abax2z33$.1k9p9fnzeypqx$.dlg@40tude.net>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=9924&group=comp.os.msdos.programmer#9924

  copy link   Newsgroups: comp.os.msdos.programmer
Path: i2pn2.org!i2pn.org!aioe.org!6eYFYPoi7ueEcuwV9LvI3A.user.gioia.aioe.org.POSTED!not-for-mail
From: jj4pub...@gmail.com (JJ)
Newsgroups: comp.os.msdos.programmer
Subject: Re: extending parameters
Date: Wed, 28 Apr 2021 13:18:35 +0700
Organization: Aioe.org NNTP Server
Lines: 11
Message-ID: <1m2w5abax2z33$.1k9p9fnzeypqx$.dlg@40tude.net>
References: <32913dab-8517-4ca2-8e4c-b7d01b517cb6n@googlegroups.com> <oavz329kvjp5$.o2a75nvbugyr$.dlg@40tude.net> <8bde3e8f-547e-4773-9901-9eae7f112256n@googlegroups.com>
NNTP-Posting-Host: 6eYFYPoi7ueEcuwV9LvI3A.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: 40tude_Dialog/2.0.15.84
X-Notice: Filtered by postfilter v. 0.9.2
X-Bitcoin: 1LcqwCQBQmhcWfWsVEAeyLchkAY8ZfuMnS
X-Face: \*\`0(1j~VfYC>ebz[&O.]=,Nm\oRM{of,liRO#7Eqi4|!]!(Gs=Akgh{J)605>C9Air?pa d{sSZ09u+A7f<^paR"/NH_#<mE1S"hde\c6PZLUB[t/s5-+Iu5DSc?P0+4%,Hl
 by: JJ - Wed, 28 Apr 2021 06:18 UTC

On Tue, 27 Apr 2021 05:52:40 -0700 (PDT), muta...@gmail.com wrote:
>
> Ok, thanks. I found that referenced here:
>
> https://en.wikipedia.org/wiki/Environment_variable
>
> But I haven't yet found the rules for setting the PSP.
>
> BFN. Paul.

Ralf Browns's PSP table described it in details.

Re: extending parameters

<acc4dabc-28f5-4e83-a5f4-73698f80aebfn@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=9925&group=comp.os.msdos.programmer#9925

  copy link   Newsgroups: comp.os.msdos.programmer
X-Received: by 2002:a37:688:: with SMTP id 130mr17235569qkg.499.1619597137844; Wed, 28 Apr 2021 01:05:37 -0700 (PDT)
X-Received: by 2002:a37:8181:: with SMTP id c123mr27665140qkd.287.1619597137671; Wed, 28 Apr 2021 01:05:37 -0700 (PDT)
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.os.msdos.programmer
Date: Wed, 28 Apr 2021 01:05:37 -0700 (PDT)
In-Reply-To: <1m2w5abax2z33$.1k9p9fnzeypqx$.dlg@40tude.net>
Injection-Info: google-groups.googlegroups.com; posting-host=202.169.113.201; posting-account=CeHKkQoAAAAowY1GfiJYG55VVc0s1zaG
NNTP-Posting-Host: 202.169.113.201
References: <32913dab-8517-4ca2-8e4c-b7d01b517cb6n@googlegroups.com> <oavz329kvjp5$.o2a75nvbugyr$.dlg@40tude.net> <8bde3e8f-547e-4773-9901-9eae7f112256n@googlegroups.com> <1m2w5abax2z33$.1k9p9fnzeypqx$.dlg@40tude.net>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <acc4dabc-28f5-4e83-a5f4-73698f80aebfn@googlegroups.com>
Subject: Re: extending parameters
From: mutazi...@gmail.com (muta...@gmail.com)
Injection-Date: Wed, 28 Apr 2021 08:05:37 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 28
 by: muta...@gmail.com - Wed, 28 Apr 2021 08:05 UTC

On Wednesday, April 28, 2021 at 4:20:15 PM UTC+10, JJ wrote:

> > But I haven't yet found the rules for setting the PSP.

> Ralf Browns's PSP table described it in details.

Ok, now I know the format:

http://www.ctyme.com/intr/rb-2682.htm

But who is responsible for setting this? I assume there
is no new INT 21H call to replace AH=4BH. So it falls
to the system() implementer to set the parmblock
according to the above rules, and also set the CMDLINE
environment variable.

I noticed that there doesn't seem to be a facility to
set the environment variable. I know how to read
environment variables (the pointer is provided in
the PSP). Looking at this:

http://www.ctyme.com/intr/rb-2939.htm

I'm guessing system() needs to allocate a new area
of memory for environment variables, copy the old
environments, add/replace CMDLINE, and put the
segment into the parameter block.

BFN. Paul.

Re: extending parameters

<1ltwm68v43wrq.ib33n7k7gmgw.dlg@40tude.net>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=9931&group=comp.os.msdos.programmer#9931

  copy link   Newsgroups: comp.os.msdos.programmer
Path: i2pn2.org!i2pn.org!aioe.org!6eYFYPoi7ueEcuwV9LvI3A.user.gioia.aioe.org.POSTED!not-for-mail
From: jj4pub...@gmail.com (JJ)
Newsgroups: comp.os.msdos.programmer
Subject: Re: extending parameters
Date: Thu, 29 Apr 2021 17:07:57 +0700
Organization: Aioe.org NNTP Server
Lines: 15
Message-ID: <1ltwm68v43wrq.ib33n7k7gmgw.dlg@40tude.net>
References: <32913dab-8517-4ca2-8e4c-b7d01b517cb6n@googlegroups.com> <oavz329kvjp5$.o2a75nvbugyr$.dlg@40tude.net> <8bde3e8f-547e-4773-9901-9eae7f112256n@googlegroups.com> <1m2w5abax2z33$.1k9p9fnzeypqx$.dlg@40tude.net> <acc4dabc-28f5-4e83-a5f4-73698f80aebfn@googlegroups.com>
NNTP-Posting-Host: 6eYFYPoi7ueEcuwV9LvI3A.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: 40tude_Dialog/2.0.15.84
X-Bitcoin: 1LcqwCQBQmhcWfWsVEAeyLchkAY8ZfuMnS
X-Notice: Filtered by postfilter v. 0.9.2
X-Face: \*\`0(1j~VfYC>ebz[&O.]=,Nm\oRM{of,liRO#7Eqi4|!]!(Gs=Akgh{J)605>C9Air?pa d{sSZ09u+A7f<^paR"/NH_#<mE1S"hde\c6PZLUB[t/s5-+Iu5DSc?P0+4%,Hl
 by: JJ - Thu, 29 Apr 2021 10:07 UTC

On Wed, 28 Apr 2021 01:05:37 -0700 (PDT), muta...@gmail.com wrote:
>
> But who is responsible for setting this?

It's COMMAND.COM, actually - and unfortunately.

Don't know why it's not implemented within the DOS interrupt service itself.
Probably because it's problematic enough, or it was a rushed solution.

> I'm guessing system() needs to allocate a new area
> of memory for environment variables, copy the old
> environments, add/replace CMDLINE, and put the
> segment into the parameter block.

Yes.

Re: extending parameters

<17x60hjtjd6dh.vfxs294kth7t.dlg@40tude.net>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=9932&group=comp.os.msdos.programmer#9932

  copy link   Newsgroups: comp.os.msdos.programmer
Path: i2pn2.org!i2pn.org!aioe.org!UDIVNECBuvPfa9ViJDv4OQ.user.gioia.aioe.org.POSTED!not-for-mail
From: jj4pub...@gmail.com (JJ)
Newsgroups: comp.os.msdos.programmer
Subject: Re: extending parameters
Date: Fri, 30 Apr 2021 16:56:27 +0700
Organization: Aioe.org NNTP Server
Lines: 18
Message-ID: <17x60hjtjd6dh.vfxs294kth7t.dlg@40tude.net>
References: <32913dab-8517-4ca2-8e4c-b7d01b517cb6n@googlegroups.com> <oavz329kvjp5$.o2a75nvbugyr$.dlg@40tude.net> <8bde3e8f-547e-4773-9901-9eae7f112256n@googlegroups.com> <1m2w5abax2z33$.1k9p9fnzeypqx$.dlg@40tude.net> <acc4dabc-28f5-4e83-a5f4-73698f80aebfn@googlegroups.com> <1ltwm68v43wrq.ib33n7k7gmgw.dlg@40tude.net> <60f490eb-728d-4767-90f2-5adaf20720f7n@googlegroups.com>
NNTP-Posting-Host: UDIVNECBuvPfa9ViJDv4OQ.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: 40tude_Dialog/2.0.15.84
X-Face: \*\`0(1j~VfYC>ebz[&O.]=,Nm\oRM{of,liRO#7Eqi4|!]!(Gs=Akgh{J)605>C9Air?pa d{sSZ09u+A7f<^paR"/NH_#<mE1S"hde\c6PZLUB[t/s5-+Iu5DSc?P0+4%,Hl
X-Bitcoin: 1LcqwCQBQmhcWfWsVEAeyLchkAY8ZfuMnS
X-Notice: Filtered by postfilter v. 0.9.2
 by: JJ - Fri, 30 Apr 2021 09:56 UTC

On Thu, 29 Apr 2021 08:38:46 -0700 (PDT), muta...@gmail.com wrote:
>
> Could you please explain what you think would
> have been a better design?

I'd keep the CMDLINE environment variable as the full command line storage.
Mainly because it's MS-DOS v7.x compatible, and it can also be used in
earlier and other DOS versions to run programs which support the variable.

That will make other programs which support the variable, easy to port to
other DOS-like OSes, because the command line storage is the same.

But implement the code which prepare the CMDLINE variable in the DOS
interrupt service itself (i.e. in Int-214B), rather than the command
interpreter, so that it's OS native. Otherwise, if the user decide to use
other command interpreter which doesn't support the CMDLINE environment
variable. Long command line won't be available for programs which already
support the CMDLINE variable.

Re: extending parameters

<c13ece80-33f2-4ab5-bcb7-c68120339391n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=9933&group=comp.os.msdos.programmer#9933

  copy link   Newsgroups: comp.os.msdos.programmer
X-Received: by 2002:ad4:5aa1:: with SMTP id u1mr1155862qvg.23.1619786094654;
Fri, 30 Apr 2021 05:34:54 -0700 (PDT)
X-Received: by 2002:a0c:e749:: with SMTP id g9mr4983881qvn.13.1619786094508;
Fri, 30 Apr 2021 05:34:54 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.os.msdos.programmer
Date: Fri, 30 Apr 2021 05:34:54 -0700 (PDT)
In-Reply-To: <17x60hjtjd6dh.vfxs294kth7t.dlg@40tude.net>
Injection-Info: google-groups.googlegroups.com; posting-host=202.169.113.201; posting-account=CeHKkQoAAAAowY1GfiJYG55VVc0s1zaG
NNTP-Posting-Host: 202.169.113.201
References: <32913dab-8517-4ca2-8e4c-b7d01b517cb6n@googlegroups.com>
<oavz329kvjp5$.o2a75nvbugyr$.dlg@40tude.net> <8bde3e8f-547e-4773-9901-9eae7f112256n@googlegroups.com>
<1m2w5abax2z33$.1k9p9fnzeypqx$.dlg@40tude.net> <acc4dabc-28f5-4e83-a5f4-73698f80aebfn@googlegroups.com>
<1ltwm68v43wrq.ib33n7k7gmgw.dlg@40tude.net> <60f490eb-728d-4767-90f2-5adaf20720f7n@googlegroups.com>
<17x60hjtjd6dh.vfxs294kth7t.dlg@40tude.net>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <c13ece80-33f2-4ab5-bcb7-c68120339391n@googlegroups.com>
Subject: Re: extending parameters
From: mutazi...@gmail.com (muta...@gmail.com)
Injection-Date: Fri, 30 Apr 2021 12:34:54 +0000
Content-Type: text/plain; charset="UTF-8"
 by: muta...@gmail.com - Fri, 30 Apr 2021 12:34 UTC

On Friday, April 30, 2021 at 7:58:20 PM UTC+10, JJ wrote:

> But implement the code which prepare the CMDLINE variable in the DOS
> interrupt service itself (i.e. in Int-214B), rather than the command
> interpreter, so that it's OS native. Otherwise, if the user decide to use
> other command interpreter which doesn't support the CMDLINE environment
> variable. Long command line won't be available for programs which already
> support the CMDLINE variable.

The way things currently work, one long-parm-aware
program can invoke another long-parm-aware program
regardless of MSDOS version.

If the change was made in the MSDOS interrupt itself,
the calling program's system() would STILL need to
do something special, to invoke the new functionality
of Int-214B, and the called program would STILL need
to do something special to receive it, AND you need
to be on a particular version of MSDOS that knows
about this new facility.

How would this be better? Or am I missing something?

BFN. Paul.

Re: extending parameters

<d2snh6xuzu23$.1cfkbxt6yxhk4.dlg@40tude.net>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=9934&group=comp.os.msdos.programmer#9934

  copy link   Newsgroups: comp.os.msdos.programmer
Path: i2pn2.org!i2pn.org!aioe.org!f7zphqYq9M0B9iPPzB9Gkg.user.gioia.aioe.org.POSTED!not-for-mail
From: jj4pub...@gmail.com (JJ)
Newsgroups: comp.os.msdos.programmer
Subject: Re: extending parameters
Date: Sat, 1 May 2021 18:18:46 +0700
Organization: Aioe.org NNTP Server
Lines: 19
Message-ID: <d2snh6xuzu23$.1cfkbxt6yxhk4.dlg@40tude.net>
References: <32913dab-8517-4ca2-8e4c-b7d01b517cb6n@googlegroups.com> <oavz329kvjp5$.o2a75nvbugyr$.dlg@40tude.net> <8bde3e8f-547e-4773-9901-9eae7f112256n@googlegroups.com> <1m2w5abax2z33$.1k9p9fnzeypqx$.dlg@40tude.net> <acc4dabc-28f5-4e83-a5f4-73698f80aebfn@googlegroups.com> <1ltwm68v43wrq.ib33n7k7gmgw.dlg@40tude.net> <60f490eb-728d-4767-90f2-5adaf20720f7n@googlegroups.com> <17x60hjtjd6dh.vfxs294kth7t.dlg@40tude.net> <c13ece80-33f2-4ab5-bcb7-c68120339391n@googlegroups.com>
NNTP-Posting-Host: f7zphqYq9M0B9iPPzB9Gkg.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: 40tude_Dialog/2.0.15.84
X-Face: \*\`0(1j~VfYC>ebz[&O.]=,Nm\oRM{of,liRO#7Eqi4|!]!(Gs=Akgh{J)605>C9Air?pa d{sSZ09u+A7f<^paR"/NH_#<mE1S"hde\c6PZLUB[t/s5-+Iu5DSc?P0+4%,Hl
X-Bitcoin: 1LcqwCQBQmhcWfWsVEAeyLchkAY8ZfuMnS
X-Notice: Filtered by postfilter v. 0.9.2
 by: JJ - Sat, 1 May 2021 11:18 UTC

On Fri, 30 Apr 2021 05:34:54 -0700 (PDT), muta...@gmail.com wrote:
>
> If the change was made in the MSDOS interrupt itself,
> the calling program's system() would STILL need to
> do something special, to invoke the new functionality
> of Int-214B, and the called program would STILL need
> to do something special to receive it, AND you need
> to be on a particular version of MSDOS that knows
> about this new facility.
>
> How would this be better? Or am I missing something?

Aw, crap. I overlooked the fact that Int-214B separates between the program
name and (the limited) command tail.

I'm beginning to believe that Microsoft's implementation is actually a
rushed solution. They should really have added an additional field in the
Parameter Block for the full command line or extended command tail. Albeit
requires that other programs handle program execution differently.

Re: extending parameters

<d2dba42b-d2bb-42d7-8bdd-9f433eefc4fan@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=9935&group=comp.os.msdos.programmer#9935

  copy link   Newsgroups: comp.os.msdos.programmer
X-Received: by 2002:ad4:5be1:: with SMTP id k1mr10414610qvc.55.1619876486953;
Sat, 01 May 2021 06:41:26 -0700 (PDT)
X-Received: by 2002:a05:620a:ccd:: with SMTP id b13mr10676744qkj.310.1619876486830;
Sat, 01 May 2021 06:41:26 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.os.msdos.programmer
Date: Sat, 1 May 2021 06:41:26 -0700 (PDT)
In-Reply-To: <d2snh6xuzu23$.1cfkbxt6yxhk4.dlg@40tude.net>
Injection-Info: google-groups.googlegroups.com; posting-host=202.169.113.201; posting-account=CeHKkQoAAAAowY1GfiJYG55VVc0s1zaG
NNTP-Posting-Host: 202.169.113.201
References: <32913dab-8517-4ca2-8e4c-b7d01b517cb6n@googlegroups.com>
<oavz329kvjp5$.o2a75nvbugyr$.dlg@40tude.net> <8bde3e8f-547e-4773-9901-9eae7f112256n@googlegroups.com>
<1m2w5abax2z33$.1k9p9fnzeypqx$.dlg@40tude.net> <acc4dabc-28f5-4e83-a5f4-73698f80aebfn@googlegroups.com>
<1ltwm68v43wrq.ib33n7k7gmgw.dlg@40tude.net> <60f490eb-728d-4767-90f2-5adaf20720f7n@googlegroups.com>
<17x60hjtjd6dh.vfxs294kth7t.dlg@40tude.net> <c13ece80-33f2-4ab5-bcb7-c68120339391n@googlegroups.com>
<d2snh6xuzu23$.1cfkbxt6yxhk4.dlg@40tude.net>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <d2dba42b-d2bb-42d7-8bdd-9f433eefc4fan@googlegroups.com>
Subject: Re: extending parameters
From: mutazi...@gmail.com (muta...@gmail.com)
Injection-Date: Sat, 01 May 2021 13:41:26 +0000
Content-Type: text/plain; charset="UTF-8"
 by: muta...@gmail.com - Sat, 1 May 2021 13:41 UTC

On Saturday, May 1, 2021 at 9:20:41 PM UTC+10, JJ wrote:
> On Fri, 30 Apr 2021 05:34:54 -0700 (PDT), muta...@gmail.com wrote:
> >
> > If the change was made in the MSDOS interrupt itself,
> > the calling program's system() would STILL need to
> > do something special, to invoke the new functionality
> > of Int-214B, and the called program would STILL need
> > to do something special to receive it, AND you need
> > to be on a particular version of MSDOS that knows
> > about this new facility.
> >
> > How would this be better? Or am I missing something?

> Aw, crap. I overlooked the fact that Int-214B separates between the program
> name and (the limited) command tail.
>
> I'm beginning to believe that Microsoft's implementation is actually a
> rushed solution. They should really have added an additional field in the
> Parameter Block for the full command line or extended command tail. Albeit
> requires that other programs handle program execution differently.

Once again, an additional field in the parameter block
would require all 3 components (caller, OS and called)
to be aware of the additional field. How is that better
than CMDLINE?

Regardless, for PDOS/386 there is an opportunity for a
fresh start. The "environment" field, a 2-byte segment,
cannot be used by hook or crook, and needs to be a
4-byte pointer instead. And everything necessarily needs
to be recompiled for 80386 anyway, so there is no harm
in doing it differently.

But the objective is still to make it easy for programmers
to target both 16-bit MSDOS and a theoretical 32-bit
MSDOS. Here is what I currently have:

typedef struct {
#ifdef __32BIT__
char *env;
#else
short env;
#endif
unsigned char *cmdtail;
char *fcb1;
char *fcb2;
} POSEXEC_PARMBLOCK;

void PosExec(char *prog, POSEXEC_PARMBLOCK *parmblock)
{ union REGS regsin;
union REGS regsout;
struct SREGS sregs;

regsin.h.ah = 0x4b;
regsin.h.al = 0;
#ifdef __32BIT__
regsin.d.edx = (int)prog;
regsin.d.ebx = (int)parmblock;
#else
sregs.ds = FP_SEG(prog);
regsin.x.dx = FP_OFF(prog);
sregs.es = FP_SEG(parmblock);
regsin.x.bx = FP_OFF(parmblock);
#endif
int86x(0x21, &regsin, &regsout, &sregs);
return;
}

I'm thinking 32-bit should drop the fcb1/2, as they seem to
be outdated, and specify that the cmdtail doesn't have a
length in the first byte, and just relies on NUL-termination.
And no '\r' either.

BFN. Paul.

Re: extending parameters

<s6jrdc$16bi$1@gioia.aioe.org>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=9936&group=comp.os.msdos.programmer#9936

  copy link   Newsgroups: comp.os.msdos.programmer
Path: i2pn2.org!i2pn.org!aioe.org!wIgm+2MIUUYkuZKIR0Uhug.user.gioia.aioe.org.POSTED!not-for-mail
From: addr...@not.available (R.Wieser)
Newsgroups: comp.os.msdos.programmer
Subject: Re: extending parameters
Date: Sat, 1 May 2021 17:16:58 +0200
Organization: Aioe.org NNTP Server
Lines: 27
Message-ID: <s6jrdc$16bi$1@gioia.aioe.org>
References: <32913dab-8517-4ca2-8e4c-b7d01b517cb6n@googlegroups.com> <oavz329kvjp5$.o2a75nvbugyr$.dlg@40tude.net> <8bde3e8f-547e-4773-9901-9eae7f112256n@googlegroups.com> <1m2w5abax2z33$.1k9p9fnzeypqx$.dlg@40tude.net> <acc4dabc-28f5-4e83-a5f4-73698f80aebfn@googlegroups.com> <1ltwm68v43wrq.ib33n7k7gmgw.dlg@40tude.net> <60f490eb-728d-4767-90f2-5adaf20720f7n@googlegroups.com> <17x60hjtjd6dh.vfxs294kth7t.dlg@40tude.net> <c13ece80-33f2-4ab5-bcb7-c68120339391n@googlegroups.com> <d2snh6xuzu23$.1cfkbxt6yxhk4.dlg@40tude.net> <d2dba42b-d2bb-42d7-8bdd-9f433eefc4fan@googlegroups.com>
NNTP-Posting-Host: wIgm+2MIUUYkuZKIR0Uhug.user.gioia.aioe.org
X-Complaints-To: abuse@aioe.org
X-Notice: Filtered by postfilter v. 0.9.2
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512
X-Priority: 3
X-RFC2646: Format=Flowed; Original
X-Newsreader: Microsoft Outlook Express 6.00.2900.5512
X-MSMail-Priority: Normal
 by: R.Wieser - Sat, 1 May 2021 15:16 UTC

Muta,

> Once again, an additional field in the parameter
> block would require all 3 components (caller, OS
> and called)

Why do you think so ? AFAIKS the *pointer* field doesn't care how long the
pointed-to string is ...

Add a "give me a pointer to the extended command-tail string" for the called
program (the PSP can only hold 126 chars so it needs to be stored somewhere
else) and it should be enough - if it fails than there is no support. It
can be used by the caller, to determine if it should apply the CMDLINE
environment variable hack, as well as by the callee, for the same reason.

> I'm thinking 32-bit should drop the fcb1/2, as they seem
> to be outdated, and specify that the cmdtail doesn't have
> a length in the first byte, and just relies on NUL-termination.
> And no '\r' either.

As long as you're busy upgrading stuff, do consider changing 2109 to a
zero-terminated string too.

Regards,
Rudy Wieser

Re: extending parameters

<s6jula$njl$1@gioia.aioe.org>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=9937&group=comp.os.msdos.programmer#9937

  copy link   Newsgroups: comp.os.msdos.programmer
Path: i2pn2.org!i2pn.org!aioe.org!wIgm+2MIUUYkuZKIR0Uhug.user.gioia.aioe.org.POSTED!not-for-mail
From: addr...@not.available (R.Wieser)
Newsgroups: comp.os.msdos.programmer
Subject: Re: extending parameters
Date: Sat, 1 May 2021 18:12:24 +0200
Organization: Aioe.org NNTP Server
Lines: 8
Message-ID: <s6jula$njl$1@gioia.aioe.org>
References: <32913dab-8517-4ca2-8e4c-b7d01b517cb6n@googlegroups.com> <oavz329kvjp5$.o2a75nvbugyr$.dlg@40tude.net> <8bde3e8f-547e-4773-9901-9eae7f112256n@googlegroups.com> <1m2w5abax2z33$.1k9p9fnzeypqx$.dlg@40tude.net> <acc4dabc-28f5-4e83-a5f4-73698f80aebfn@googlegroups.com> <1ltwm68v43wrq.ib33n7k7gmgw.dlg@40tude.net> <60f490eb-728d-4767-90f2-5adaf20720f7n@googlegroups.com> <17x60hjtjd6dh.vfxs294kth7t.dlg@40tude.net> <c13ece80-33f2-4ab5-bcb7-c68120339391n@googlegroups.com> <d2snh6xuzu23$.1cfkbxt6yxhk4.dlg@40tude.net> <d2dba42b-d2bb-42d7-8bdd-9f433eefc4fan@googlegroups.com> <s6jrdc$16bi$1@gioia.aioe.org>
NNTP-Posting-Host: wIgm+2MIUUYkuZKIR0Uhug.user.gioia.aioe.org
X-Complaints-To: abuse@aioe.org
X-Notice: Filtered by postfilter v. 0.9.2
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512
X-Priority: 3
X-RFC2646: Format=Flowed; Response
X-Newsreader: Microsoft Outlook Express 6.00.2900.5512
 by: R.Wieser - Sat, 1 May 2021 16:12 UTC

> Add a "give me a pointer to the extended command-tail string"

Forgot to include the word INT at the the above end.

Regards,
Rudy Wieser

Re: extending parameters

<515364ed-e0cc-420c-be8d-61a40c8e1dbcn@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=9938&group=comp.os.msdos.programmer#9938

  copy link   Newsgroups: comp.os.msdos.programmer
X-Received: by 2002:a37:b685:: with SMTP id g127mr11620995qkf.42.1619893714376;
Sat, 01 May 2021 11:28:34 -0700 (PDT)
X-Received: by 2002:a05:622a:1108:: with SMTP id e8mr9649963qty.177.1619893714191;
Sat, 01 May 2021 11:28:34 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.os.msdos.programmer
Date: Sat, 1 May 2021 11:28:33 -0700 (PDT)
In-Reply-To: <s6jrdc$16bi$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=202.169.113.201; posting-account=CeHKkQoAAAAowY1GfiJYG55VVc0s1zaG
NNTP-Posting-Host: 202.169.113.201
References: <32913dab-8517-4ca2-8e4c-b7d01b517cb6n@googlegroups.com>
<oavz329kvjp5$.o2a75nvbugyr$.dlg@40tude.net> <8bde3e8f-547e-4773-9901-9eae7f112256n@googlegroups.com>
<1m2w5abax2z33$.1k9p9fnzeypqx$.dlg@40tude.net> <acc4dabc-28f5-4e83-a5f4-73698f80aebfn@googlegroups.com>
<1ltwm68v43wrq.ib33n7k7gmgw.dlg@40tude.net> <60f490eb-728d-4767-90f2-5adaf20720f7n@googlegroups.com>
<17x60hjtjd6dh.vfxs294kth7t.dlg@40tude.net> <c13ece80-33f2-4ab5-bcb7-c68120339391n@googlegroups.com>
<d2snh6xuzu23$.1cfkbxt6yxhk4.dlg@40tude.net> <d2dba42b-d2bb-42d7-8bdd-9f433eefc4fan@googlegroups.com>
<s6jrdc$16bi$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <515364ed-e0cc-420c-be8d-61a40c8e1dbcn@googlegroups.com>
Subject: Re: extending parameters
From: mutazi...@gmail.com (muta...@gmail.com)
Injection-Date: Sat, 01 May 2021 18:28:34 +0000
Content-Type: text/plain; charset="UTF-8"
 by: muta...@gmail.com - Sat, 1 May 2021 18:28 UTC

On Sunday, May 2, 2021 at 1:17:04 AM UTC+10, R.Wieser wrote:

Hi Rudy. Are you going to answer my question about
the technical barrier to ctrl-c checking for programs
that loop without doing output? I'd really like to know
that.

> > Once again, an additional field in the parameter
> > block would require all 3 components (caller, OS
> > and called)

> Why do you think so ?

For the same reason I gave before?

> AFAIKS the *pointer* field doesn't care how long the
> pointed-to string is ...

Sure.

> Add a "give me a pointer to the extended command-tail string (INT)" for the called
> program (the PSP can only hold 126 chars so it needs to be stored somewhere
> else) and it should be enough - if it fails than there is no support. It
> can be used by the caller, to determine if it should apply the CMDLINE
> environment variable hack, as well as by the callee, for the same reason.

So both caller and called require two techniques
instead of one, and the OS indeed can have 0 or 1.

This can in fact be added to the existing system
at any time if you think it is a good idea.

> > I'm thinking 32-bit should drop the fcb1/2, as they seem
> > to be outdated, and specify that the cmdtail doesn't have
> > a length in the first byte, and just relies on NUL-termination.
> > And no '\r' either.

> As long as you're busy upgrading stuff, do consider changing 2109 to a
> zero-terminated string too.

Currently I can go:

PosDisplayString("Hello$");

and it will work on both 16-bit and 32-bit MSDOS.

What is the advantage of forcing programmers to code:

#ifdef __32BIT__
PosDisplayString("Hello");
#else
PosDisplayString("Hello$");
#endif

?

More code to achieve what?

BFN. Paul.

Re: extending parameters

<s6kfgc$9ko$2@gioia.aioe.org>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=9941&group=comp.os.msdos.programmer#9941

  copy link   Newsgroups: comp.os.msdos.programmer
Path: i2pn2.org!i2pn.org!aioe.org!wIgm+2MIUUYkuZKIR0Uhug.user.gioia.aioe.org.POSTED!not-for-mail
From: addr...@not.available (R.Wieser)
Newsgroups: comp.os.msdos.programmer
Subject: Re: extending parameters
Date: Sat, 1 May 2021 22:59:40 +0200
Organization: Aioe.org NNTP Server
Lines: 65
Message-ID: <s6kfgc$9ko$2@gioia.aioe.org>
References: <32913dab-8517-4ca2-8e4c-b7d01b517cb6n@googlegroups.com> <oavz329kvjp5$.o2a75nvbugyr$.dlg@40tude.net> <8bde3e8f-547e-4773-9901-9eae7f112256n@googlegroups.com> <1m2w5abax2z33$.1k9p9fnzeypqx$.dlg@40tude.net> <acc4dabc-28f5-4e83-a5f4-73698f80aebfn@googlegroups.com> <1ltwm68v43wrq.ib33n7k7gmgw.dlg@40tude.net> <60f490eb-728d-4767-90f2-5adaf20720f7n@googlegroups.com> <17x60hjtjd6dh.vfxs294kth7t.dlg@40tude.net> <c13ece80-33f2-4ab5-bcb7-c68120339391n@googlegroups.com> <d2snh6xuzu23$.1cfkbxt6yxhk4.dlg@40tude.net> <d2dba42b-d2bb-42d7-8bdd-9f433eefc4fan@googlegroups.com> <s6jrdc$16bi$1@gioia.aioe.org> <515364ed-e0cc-420c-be8d-61a40c8e1dbcn@googlegroups.com>
NNTP-Posting-Host: wIgm+2MIUUYkuZKIR0Uhug.user.gioia.aioe.org
X-Complaints-To: abuse@aioe.org
X-MSMail-Priority: Normal
X-Priority: 3
X-Newsreader: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512
X-RFC2646: Format=Flowed; Original
X-Notice: Filtered by postfilter v. 0.9.2
 by: R.Wieser - Sat, 1 May 2021 20:59 UTC

Muta,

> Hi Rudy. Are you going to answer my question about
> the technical barrier to ctrl-c checking for programs
> that loop without doing output? I'd really like to know
> that.

Done.

>> > Once again, an additional field in the parameter
>> > block would require all 3 components (caller, OS
>> > and called)
>
>> Why do you think so ?
>
> For the same reason I gave before?

No, not who should be aware of that extra field, but why that extra field is
needed in the first place.

> So both caller and called require two techniques
> instead of one, and the OS indeed can have 0 or 1.

Required ? No. A good idea to have them both *if* you want to have your
program to also run on DOSes which do not support the extended command-tail
? Yes.

Did I already mention that I regard the CMDLINE method to be an hack (and an
ugly one to boot) ? And have you ever thought about how clumsy changing
the environment and retrieving from it is for a to-be-executed program is in
a plain DOS version ?

Than again, most of that is hidden from you by the C{something} environment
you're programming in ...

>> As long as you're busy upgrading stuff, do consider changing 2109 to a
>> zero-terminated string too.
>
> Currently I can go:
>
> PosDisplayString("Hello$");
>
> and it will work on both 16-bit and 32-bit MSDOS.

Yeah, it does. You know what /won't/ work ? Displaying the current, or
your proposed extended command-tail that way.

But lets put it differently : you're introducing a /third/ string form. Why
? And of you think that a zero-terminated string works better than why not
update that ancient '$' ended string too ? Better yet, change all three to
the same, zero-terminated form.

Than again, if you would do that you would lose compatibility with all of
the other DOSes ... so maybe don't.

> More code to achieve what?

Nope, less code. One set of functions that will handle the single string
form, instead of having three different ones. Also, no permutations needed
to combine/append one string form with/to another.

Regards,
Rudy Wieser

Re: extending parameters

<4f24c208-e223-427c-a41c-98008a776403n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=9943&group=comp.os.msdos.programmer#9943

  copy link   Newsgroups: comp.os.msdos.programmer
X-Received: by 2002:ac8:5cc4:: with SMTP id s4mr10225926qta.214.1619906010502; Sat, 01 May 2021 14:53:30 -0700 (PDT)
X-Received: by 2002:ad4:4ee8:: with SMTP id dv8mr12123464qvb.46.1619906010331; Sat, 01 May 2021 14:53:30 -0700 (PDT)
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.os.msdos.programmer
Date: Sat, 1 May 2021 14:53:30 -0700 (PDT)
In-Reply-To: <s6kfgc$9ko$2@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=202.169.113.201; posting-account=CeHKkQoAAAAowY1GfiJYG55VVc0s1zaG
NNTP-Posting-Host: 202.169.113.201
References: <32913dab-8517-4ca2-8e4c-b7d01b517cb6n@googlegroups.com> <oavz329kvjp5$.o2a75nvbugyr$.dlg@40tude.net> <8bde3e8f-547e-4773-9901-9eae7f112256n@googlegroups.com> <1m2w5abax2z33$.1k9p9fnzeypqx$.dlg@40tude.net> <acc4dabc-28f5-4e83-a5f4-73698f80aebfn@googlegroups.com> <1ltwm68v43wrq.ib33n7k7gmgw.dlg@40tude.net> <60f490eb-728d-4767-90f2-5adaf20720f7n@googlegroups.com> <17x60hjtjd6dh.vfxs294kth7t.dlg@40tude.net> <c13ece80-33f2-4ab5-bcb7-c68120339391n@googlegroups.com> <d2snh6xuzu23$.1cfkbxt6yxhk4.dlg@40tude.net> <d2dba42b-d2bb-42d7-8bdd-9f433eefc4fan@googlegroups.com> <s6jrdc$16bi$1@gioia.aioe.org> <515364ed-e0cc-420c-be8d-61a40c8e1dbcn@googlegroups.com> <s6kfgc$9ko$2@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <4f24c208-e223-427c-a41c-98008a776403n@googlegroups.com>
Subject: Re: extending parameters
From: mutazi...@gmail.com (muta...@gmail.com)
Injection-Date: Sat, 01 May 2021 21:53:30 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 84
 by: muta...@gmail.com - Sat, 1 May 2021 21:53 UTC

On Sunday, May 2, 2021 at 7:00:00 AM UTC+10, R.Wieser wrote:

> Did I already mention that I regard the CMDLINE method to be an hack (and an
> ugly one to boot) ? And have you ever thought about how clumsy changing
> the environment and retrieving from it is for a to-be-executed program is in
> a plain DOS version ?

I think we need to distinguish between:

1. How MSDOS would ideally have been written starting with version 1.0.

2. How to maintain compatibility with the CMDLINE solution
introduced in MSDOS 7.0.

3. What alternative could have been chosen knowing the
"mistakes" of 1.0 and before the 7.0 solution has been
set in stone.

> > PosDisplayString("Hello$");
> >
> > and it will work on both 16-bit and 32-bit MSDOS.

> Yeah, it does. You know what /won't/ work ? Displaying the current, or
> your proposed extended command-tail that way.

Sure. This is not the function for that. There isn't any
choice but to use an alternative. Is that a problem?
You can't go changing the MSDOS API, at least not
for the 16-bit version, at least not if you want to
maintain compatibility with any version of genuine
MSDOS at all. Or any existing version of Freedos for
that matter.

> But lets put it differently : you're introducing a /third/ string form. Why
> ?

Because the '\r' is useless either way and needs to
be removed. I'm only talking about the command
line processing, which is necessarily different
between 16-bit and 32-bit anyway.

There's no need for the CMDLINE kludge either in the
32-bit version. The PSP needs to be changed, and
everything needs to be recompiled anyway.

If we (as I do) theorize that Microsoft had created a
nice C API like the Pos* functions, instead of only
providing an assembler interface, what would that
API actually look like?

The Pos* functions:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/src/pos.c

are my guess at answering that question, but I'm open
to suggestions.

> And of you think that a zero-terminated string works better than why not
> update that ancient '$' ended string too ? Better yet, change all three to
> the same, zero-terminated form.
>
> Than again, if you would do that you would lose compatibility with all of
> the other DOSes ... so maybe don't.

Correct.

I guess we need to ask what a sensible objective is in
the first place. I just have a vague idea of "32-bit MSDOS".

And part of that is an expectation that you can display
a "$" terminated string on both real 16-bit MSDOS and
newly-invented 32-bit MSDOS.

> > More code to achieve what?

> Nope, less code. One set of functions that will handle the single string
> form, instead of having three different ones. Also, no permutations needed
> to combine/append one string form with/to another.

I am not providing an API to print a NUL-terminated
string. I'm just setting rules for INT 21H 4BH.

At the moment, anyway.

BFN. Paul.

Re: extending parameters

<s6lsoc$1e34$1@gioia.aioe.org>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=9946&group=comp.os.msdos.programmer#9946

  copy link   Newsgroups: comp.os.msdos.programmer
Path: i2pn2.org!i2pn.org!aioe.org!wIgm+2MIUUYkuZKIR0Uhug.user.gioia.aioe.org.POSTED!not-for-mail
From: addr...@not.available (R.Wieser)
Newsgroups: comp.os.msdos.programmer
Subject: Re: extending parameters
Date: Sun, 2 May 2021 11:52:06 +0200
Organization: Aioe.org NNTP Server
Lines: 75
Message-ID: <s6lsoc$1e34$1@gioia.aioe.org>
References: <32913dab-8517-4ca2-8e4c-b7d01b517cb6n@googlegroups.com> <oavz329kvjp5$.o2a75nvbugyr$.dlg@40tude.net> <8bde3e8f-547e-4773-9901-9eae7f112256n@googlegroups.com> <1m2w5abax2z33$.1k9p9fnzeypqx$.dlg@40tude.net> <acc4dabc-28f5-4e83-a5f4-73698f80aebfn@googlegroups.com> <1ltwm68v43wrq.ib33n7k7gmgw.dlg@40tude.net> <60f490eb-728d-4767-90f2-5adaf20720f7n@googlegroups.com> <17x60hjtjd6dh.vfxs294kth7t.dlg@40tude.net> <c13ece80-33f2-4ab5-bcb7-c68120339391n@googlegroups.com> <d2snh6xuzu23$.1cfkbxt6yxhk4.dlg@40tude.net> <d2dba42b-d2bb-42d7-8bdd-9f433eefc4fan@googlegroups.com> <s6jrdc$16bi$1@gioia.aioe.org> <515364ed-e0cc-420c-be8d-61a40c8e1dbcn@googlegroups.com> <s6kfgc$9ko$2@gioia.aioe.org> <4f24c208-e223-427c-a41c-98008a776403n@googlegroups.com>
NNTP-Posting-Host: wIgm+2MIUUYkuZKIR0Uhug.user.gioia.aioe.org
X-Complaints-To: abuse@aioe.org
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512
X-RFC2646: Format=Flowed; Original
X-Priority: 3
X-MSMail-Priority: Normal
X-Notice: Filtered by postfilter v. 0.9.2
X-Newsreader: Microsoft Outlook Express 6.00.2900.5512
 by: R.Wieser - Sun, 2 May 2021 09:52 UTC

Muta,

> I think we need to distinguish between:
>
> 1. How MSDOS would ideally have been written starting with version 1.0.
....
> 3. What alternative could have been chosen knowing the
> "mistakes" of 1.0 and before the 7.0 solution has been
> set in stone.

No, definitily not. I have no wish to talk that way about stuff I cannot
alter. Also, it would be bashing those thanwhile choices with our current
knowledge. Thats simply not fair. Also, in your case its would be tainted
with what you think your own OS should be capable of / looking like.

> 2. How to maintain compatibility with the CMDLINE
> solution introduced in MSDOS 7.0.

Can you come up with a way to make a program incompatible with it ? If
not than that requirement is moot.

> Sure. This is not the function for that. There isn't any
> choice but to use an alternative. Is that a problem?

Lol. *you* are introducing a new sting type, and than claim you have no
choice to use another function ? What about *NOT* introducing a new
string type ?

> Because the '\r' is useless either way and needs
> to be removed.

The same goes for that '$' terminating a string. Your point ?

But as I already mentioned, such a change (for either or both of the above
strings) would have dire consequences. Which might easily be prohibitonary.

> There's no need for the CMDLINE kludge either in
> the 32-bit version.

Thanks. That means I can just ignore any references you make to the 32-bit
version.

> If we (as I do) theorize that Microsoft had created
> a nice C API like the Pos* functions, instead of only
> providing an assembler interface, what would that
> API actually look like?

Nope, not going to engage in that. For several reasons.

One question though : whats, according to you, the difference between the
above "C API" and "assembler interface" ?

> I guess we need to ask what a sensible objective is in
> the first place. I just have a vague idea of "32-bit MSDOS".

And as that one, as you have just mentioned yourself, doesn't need the
CMDLINE kludge it means that our current conversation is a waste of our
time. :-(

> I am not providing an API to print a NUL-terminated
> string.

Which makes the problem bigger. Introducing something new, but not adding
support for it.

> I'm just setting rules for INT 21H 4BH.

And I've mentioned (and explained!) to you that changes to support an
extended command-tail are not needed . If you think otherwise I would like
to hear why.

Regards,
Rudy Wieser

Re: extending parameters

<idq1p6llgqfv.1vkgq1lrlx8sv.dlg@40tude.net>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=9947&group=comp.os.msdos.programmer#9947

  copy link   Newsgroups: comp.os.msdos.programmer
Path: i2pn2.org!i2pn.org!aioe.org!f7zphqYq9M0B9iPPzB9Gkg.user.gioia.aioe.org.POSTED!not-for-mail
From: jj4pub...@gmail.com (JJ)
Newsgroups: comp.os.msdos.programmer
Subject: Re: extending parameters
Date: Sun, 2 May 2021 18:55:08 +0700
Organization: Aioe.org NNTP Server
Lines: 37
Message-ID: <idq1p6llgqfv.1vkgq1lrlx8sv.dlg@40tude.net>
References: <32913dab-8517-4ca2-8e4c-b7d01b517cb6n@googlegroups.com> <oavz329kvjp5$.o2a75nvbugyr$.dlg@40tude.net> <8bde3e8f-547e-4773-9901-9eae7f112256n@googlegroups.com> <1m2w5abax2z33$.1k9p9fnzeypqx$.dlg@40tude.net> <acc4dabc-28f5-4e83-a5f4-73698f80aebfn@googlegroups.com> <1ltwm68v43wrq.ib33n7k7gmgw.dlg@40tude.net> <60f490eb-728d-4767-90f2-5adaf20720f7n@googlegroups.com> <17x60hjtjd6dh.vfxs294kth7t.dlg@40tude.net> <c13ece80-33f2-4ab5-bcb7-c68120339391n@googlegroups.com> <d2snh6xuzu23$.1cfkbxt6yxhk4.dlg@40tude.net> <d2dba42b-d2bb-42d7-8bdd-9f433eefc4fan@googlegroups.com>
NNTP-Posting-Host: f7zphqYq9M0B9iPPzB9Gkg.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: 40tude_Dialog/2.0.15.84
X-Bitcoin: 1LcqwCQBQmhcWfWsVEAeyLchkAY8ZfuMnS
X-Face: \*\`0(1j~VfYC>ebz[&O.]=,Nm\oRM{of,liRO#7Eqi4|!]!(Gs=Akgh{J)605>C9Air?pa d{sSZ09u+A7f<^paR"/NH_#<mE1S"hde\c6PZLUB[t/s5-+Iu5DSc?P0+4%,Hl
X-Notice: Filtered by postfilter v. 0.9.2
 by: JJ - Sun, 2 May 2021 11:55 UTC

On Sat, 1 May 2021 06:41:26 -0700 (PDT), muta...@gmail.com wrote:
>
> Once again, an additional field in the parameter block
> would require all 3 components (caller, OS and called)
> to be aware of the additional field.

Yes, I'm aware of that now.

> How is that better than CMDLINE?

It's not. That isn't the point. It's a better way (than what MS-DOS 7.x) to
implement the code which provide CMDLINE. So that it doesn't depend on the
command interpreter to do it. It also off-load the code to the DOS kernel,
making programs a bit smaller. Yes, it does require the 3 components. That
can not be helped.

> Regardless, for PDOS/386 there is an opportunity for a
> fresh start. The "environment" field, a 2-byte segment,
> cannot be used by hook or crook, and needs to be a
> 4-byte pointer instead. And everything necessarily needs
> to be recompiled for 80386 anyway, so there is no harm
> in doing it differently.

If backward compatibility is not kept, it'll add more work to port existing
softwares.

> But the objective is still to make it easy for programmers
> to target both 16-bit MSDOS and a theoretical 32-bit
> MSDOS.
[snip]
> I'm thinking 32-bit should drop the fcb1/2, as they seem to
> be outdated, and specify that the cmdtail doesn't have a
> length in the first byte, and just relies on NUL-termination.
> And no '\r' either.

Yes, but that only applies to programs which are created from scratch. It
doesn't apply to existing programs.

Re: extending parameters

<4568cc17-447e-4823-a8ce-1fb69af318cdn@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=9948&group=comp.os.msdos.programmer#9948

  copy link   Newsgroups: comp.os.msdos.programmer
X-Received: by 2002:a05:622a:207:: with SMTP id b7mr13156360qtx.254.1619963178349;
Sun, 02 May 2021 06:46:18 -0700 (PDT)
X-Received: by 2002:a05:622a:1108:: with SMTP id e8mr12506774qty.177.1619963178171;
Sun, 02 May 2021 06:46:18 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.os.msdos.programmer
Date: Sun, 2 May 2021 06:46:17 -0700 (PDT)
In-Reply-To: <idq1p6llgqfv.1vkgq1lrlx8sv.dlg@40tude.net>
Injection-Info: google-groups.googlegroups.com; posting-host=202.169.113.201; posting-account=CeHKkQoAAAAowY1GfiJYG55VVc0s1zaG
NNTP-Posting-Host: 202.169.113.201
References: <32913dab-8517-4ca2-8e4c-b7d01b517cb6n@googlegroups.com>
<oavz329kvjp5$.o2a75nvbugyr$.dlg@40tude.net> <8bde3e8f-547e-4773-9901-9eae7f112256n@googlegroups.com>
<1m2w5abax2z33$.1k9p9fnzeypqx$.dlg@40tude.net> <acc4dabc-28f5-4e83-a5f4-73698f80aebfn@googlegroups.com>
<1ltwm68v43wrq.ib33n7k7gmgw.dlg@40tude.net> <60f490eb-728d-4767-90f2-5adaf20720f7n@googlegroups.com>
<17x60hjtjd6dh.vfxs294kth7t.dlg@40tude.net> <c13ece80-33f2-4ab5-bcb7-c68120339391n@googlegroups.com>
<d2snh6xuzu23$.1cfkbxt6yxhk4.dlg@40tude.net> <d2dba42b-d2bb-42d7-8bdd-9f433eefc4fan@googlegroups.com>
<idq1p6llgqfv.1vkgq1lrlx8sv.dlg@40tude.net>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <4568cc17-447e-4823-a8ce-1fb69af318cdn@googlegroups.com>
Subject: Re: extending parameters
From: mutazi...@gmail.com (muta...@gmail.com)
Injection-Date: Sun, 02 May 2021 13:46:18 +0000
Content-Type: text/plain; charset="UTF-8"
 by: muta...@gmail.com - Sun, 2 May 2021 13:46 UTC

On Sunday, May 2, 2021 at 9:57:06 PM UTC+10, JJ wrote:

> > How is that better than CMDLINE?

> It's not. That isn't the point. It's a better way (than what MS-DOS 7.x) to
> implement the code which provide CMDLINE. So that it doesn't depend on the
> command interpreter to do it. It also off-load the code to the DOS kernel,
> making programs a bit smaller. Yes, it does require the 3 components. That
> can not be helped.

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

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

> > Regardless, for PDOS/386 there is an opportunity for a
> > fresh start. The "environment" field, a 2-byte segment,
> > cannot be used by hook or crook, and needs to be a
> > 4-byte pointer instead. And everything necessarily needs
> > to be recompiled for 80386 anyway, so there is no harm
> > in doing it differently.

> If backward compatibility is not kept, it'll add more work to port existing
> softwares.

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

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.

> > But the objective is still to make it easy for programmers
> > to target both 16-bit MSDOS and a theoretical 32-bit
> > MSDOS.
> [snip]
> > I'm thinking 32-bit should drop the fcb1/2, as they seem to
> > be outdated, and specify that the cmdtail doesn't have a
> > length in the first byte, and just relies on NUL-termination.
> > And no '\r' either.

> Yes, but that only applies to programs which are created from scratch. It
> doesn't apply to existing programs.

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.

BFN. Paul.

Re: extending parameters

<d9a8cf3d-a9f0-47a2-b234-110ad18c0ca6n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=9949&group=comp.os.msdos.programmer#9949

  copy link   Newsgroups: comp.os.msdos.programmer
X-Received: by 2002:a0c:f802:: with SMTP id r2mr14972898qvn.50.1619963840011;
Sun, 02 May 2021 06:57:20 -0700 (PDT)
X-Received: by 2002:a37:b203:: with SMTP id b3mr9695193qkf.110.1619963839817;
Sun, 02 May 2021 06:57:19 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.os.msdos.programmer
Date: Sun, 2 May 2021 06:57:19 -0700 (PDT)
In-Reply-To: <s6lsoc$1e34$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=202.169.113.201; posting-account=CeHKkQoAAAAowY1GfiJYG55VVc0s1zaG
NNTP-Posting-Host: 202.169.113.201
References: <32913dab-8517-4ca2-8e4c-b7d01b517cb6n@googlegroups.com>
<oavz329kvjp5$.o2a75nvbugyr$.dlg@40tude.net> <8bde3e8f-547e-4773-9901-9eae7f112256n@googlegroups.com>
<1m2w5abax2z33$.1k9p9fnzeypqx$.dlg@40tude.net> <acc4dabc-28f5-4e83-a5f4-73698f80aebfn@googlegroups.com>
<1ltwm68v43wrq.ib33n7k7gmgw.dlg@40tude.net> <60f490eb-728d-4767-90f2-5adaf20720f7n@googlegroups.com>
<17x60hjtjd6dh.vfxs294kth7t.dlg@40tude.net> <c13ece80-33f2-4ab5-bcb7-c68120339391n@googlegroups.com>
<d2snh6xuzu23$.1cfkbxt6yxhk4.dlg@40tude.net> <d2dba42b-d2bb-42d7-8bdd-9f433eefc4fan@googlegroups.com>
<s6jrdc$16bi$1@gioia.aioe.org> <515364ed-e0cc-420c-be8d-61a40c8e1dbcn@googlegroups.com>
<s6kfgc$9ko$2@gioia.aioe.org> <4f24c208-e223-427c-a41c-98008a776403n@googlegroups.com>
<s6lsoc$1e34$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <d9a8cf3d-a9f0-47a2-b234-110ad18c0ca6n@googlegroups.com>
Subject: Re: extending parameters
From: mutazi...@gmail.com (muta...@gmail.com)
Injection-Date: Sun, 02 May 2021 13:57:19 +0000
Content-Type: text/plain; charset="UTF-8"
 by: muta...@gmail.com - Sun, 2 May 2021 13:57 UTC

On Sunday, May 2, 2021 at 7:52:14 PM UTC+10, R.Wieser wrote:

> > I think we need to distinguish between:
> >
> > 1. How MSDOS would ideally have been written starting with version 1.0.
> ...
> > 3. What alternative could have been chosen knowing the
> > "mistakes" of 1.0 and before the 7.0 solution has been
> > set in stone.

> No, definitily not. I have no wish to talk that way about stuff I cannot
> alter. Also, it would be bashing those thanwhile choices with our current
> knowledge. Thats simply not fair.

I don't consider it to be bashing. I'd like to understand what
the ideal solution would have been, understand what was
actually done, potentially bridge any gap, and write down
a set of principles if history ever repeats for some reason.

> > Sure. This is not the function for that. There isn't any
> > choice but to use an alternative. Is that a problem?

> Lol. *you* are introducing a new sting type, and than claim you have no
> choice to use another function ? What about *NOT* introducing a new
> string type ?

For 16-bit MSDOS you have to use cmdtail[0] to get
to the '\r' so that you can remove it.

For 32-bit MSDOS there is no cmdtail[0], and there's
no particular reason to insert a useless '\r' so that
someone can then remove it.

I don't see any issue.

But if you can explain why putting a useless '\r' so that
people have to remove it is actually helpful for
compatibility with something, I'm all ears.

> > Because the '\r' is useless either way and needs
> > to be removed.

> The same goes for that '$' terminating a string. Your point ?

$-terminated strings are a separate issue, and the
solution is identical for 16-bit and 32-bit MSDOS.
There is no issue whatsoever there.

The only issue is exec()/PosExec().

> But as I already mentioned, such a change (for either or both of the above
> strings) would have dire consequences. Which might easily be prohibitonary.

The parameter block to exec() in 32-bit has to change.
And recompilation has to be done too.

What specifically are you proposing for 32-bit programming
under 32-bit MSDOS?

> > If we (as I do) theorize that Microsoft had created
> > a nice C API like the Pos* functions, instead of only
> > providing an assembler interface, what would that
> > API actually look like?

> Nope, not going to engage in that. For several reasons.
>
> One question though : whats, according to you, the difference between the
> above "C API" and "assembler interface" ?

The C API merely requires a recompile for almost
all INT 21H services when switching from 16-bit
MSDOS to 32-bit MSDOS.

> > I am not providing an API to print a NUL-terminated
> > string.

> Which makes the problem bigger. Introducing something new, but not adding
> support for it.

It's all new. 32-bit exec() is all new. Necessarily.

> > I'm just setting rules for INT 21H 4BH.

> And I've mentioned (and explained!) to you that changes to support an
> extended command-tail are not needed . If you think otherwise I would like
> to hear why.

To start with, the parameter block to exec() has a
2-byte "segment" pointing to an environment block.

That can't work in a 32-bit flat address space. You
need a 4-byte flat pointer.

Maybe the source of confusion is that you think I am
talking about 32-bit applications calling real 16-bit
MSDOS. That is not the case. I am talking about
32-bit applications calling 32-bit MSDOS. Microsoft
never produced such a thing, but I have attempted to.
It's called PDOS/386.

BFN. Paul.

Re: extending parameters

<yf3qmurg0zwy$.z2wj9truynqj$.dlg@40tude.net>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=9952&group=comp.os.msdos.programmer#9952

  copy link   Newsgroups: comp.os.msdos.programmer
Path: i2pn2.org!i2pn.org!aioe.org!esscOFPPHccfjlxlZhKy2Q.user.gioia.aioe.org.POSTED!not-for-mail
From: jj4pub...@gmail.com (JJ)
Newsgroups: comp.os.msdos.programmer
Subject: Re: extending parameters
Date: Mon, 3 May 2021 22:45:19 +0700
Organization: Aioe.org NNTP Server
Lines: 43
Message-ID: <yf3qmurg0zwy$.z2wj9truynqj$.dlg@40tude.net>
References: <32913dab-8517-4ca2-8e4c-b7d01b517cb6n@googlegroups.com> <oavz329kvjp5$.o2a75nvbugyr$.dlg@40tude.net> <8bde3e8f-547e-4773-9901-9eae7f112256n@googlegroups.com> <1m2w5abax2z33$.1k9p9fnzeypqx$.dlg@40tude.net> <acc4dabc-28f5-4e83-a5f4-73698f80aebfn@googlegroups.com> <1ltwm68v43wrq.ib33n7k7gmgw.dlg@40tude.net> <60f490eb-728d-4767-90f2-5adaf20720f7n@googlegroups.com> <17x60hjtjd6dh.vfxs294kth7t.dlg@40tude.net> <c13ece80-33f2-4ab5-bcb7-c68120339391n@googlegroups.com> <d2snh6xuzu23$.1cfkbxt6yxhk4.dlg@40tude.net> <d2dba42b-d2bb-42d7-8bdd-9f433eefc4fan@googlegroups.com> <idq1p6llgqfv.1vkgq1lrlx8sv.dlg@40tude.net> <4568cc17-447e-4823-a8ce-1fb69af318cdn@googlegroups.com>
NNTP-Posting-Host: esscOFPPHccfjlxlZhKy2Q.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: 40tude_Dialog/2.0.15.84
X-Face: \*\`0(1j~VfYC>ebz[&O.]=,Nm\oRM{of,liRO#7Eqi4|!]!(Gs=Akgh{J)605>C9Air?pa d{sSZ09u+A7f<^paR"/NH_#<mE1S"hde\c6PZLUB[t/s5-+Iu5DSc?P0+4%,Hl
X-Bitcoin: 1LcqwCQBQmhcWfWsVEAeyLchkAY8ZfuMnS
X-Notice: Filtered by postfilter v. 0.9.2
 by: JJ - Mon, 3 May 2021 15:45 UTC

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.

Re: extending parameters

<82703a67-99fb-4488-8b39-09cae5c57af7n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=9953&group=comp.os.msdos.programmer#9953

  copy link   Newsgroups: comp.os.msdos.programmer
X-Received: by 2002:a37:63d2:: with SMTP id x201mr6740350qkb.202.1620058282953; Mon, 03 May 2021 09:11:22 -0700 (PDT)
X-Received: by 2002:ac8:7484:: with SMTP id v4mr17301997qtq.357.1620058282803; Mon, 03 May 2021 09:11:22 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.os.msdos.programmer
Date: Mon, 3 May 2021 09:11:22 -0700 (PDT)
In-Reply-To: <yf3qmurg0zwy$.z2wj9truynqj$.dlg@40tude.net>
Injection-Info: google-groups.googlegroups.com; posting-host=202.169.113.201; posting-account=CeHKkQoAAAAowY1GfiJYG55VVc0s1zaG
NNTP-Posting-Host: 202.169.113.201
References: <32913dab-8517-4ca2-8e4c-b7d01b517cb6n@googlegroups.com> <oavz329kvjp5$.o2a75nvbugyr$.dlg@40tude.net> <8bde3e8f-547e-4773-9901-9eae7f112256n@googlegroups.com> <1m2w5abax2z33$.1k9p9fnzeypqx$.dlg@40tude.net> <acc4dabc-28f5-4e83-a5f4-73698f80aebfn@googlegroups.com> <1ltwm68v43wrq.ib33n7k7gmgw.dlg@40tude.net> <60f490eb-728d-4767-90f2-5adaf20720f7n@googlegroups.com> <17x60hjtjd6dh.vfxs294kth7t.dlg@40tude.net> <c13ece80-33f2-4ab5-bcb7-c68120339391n@googlegroups.com> <d2snh6xuzu23$.1cfkbxt6yxhk4.dlg@40tude.net> <d2dba42b-d2bb-42d7-8bdd-9f433eefc4fan@googlegroups.com> <idq1p6llgqfv.1vkgq1lrlx8sv.dlg@40tude.net> <4568cc17-447e-4823-a8ce-1fb69af318cdn@googlegroups.com> <yf3qmurg0zwy$.z2wj9truynqj$.dlg@40tude.net>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <82703a67-99fb-4488-8b39-09cae5c57af7n@googlegroups.com>
Subject: Re: extending parameters
From: mutazi...@gmail.com (muta...@gmail.com)
Injection-Date: Mon, 03 May 2021 16:11:22 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 66
 by: muta...@gmail.com - Mon, 3 May 2021 16:11 UTC

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.

Re: extending parameters

<guop7qojrijt$.iwcz72x3sz1v.dlg@40tude.net>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=9954&group=comp.os.msdos.programmer#9954

  copy link   Newsgroups: comp.os.msdos.programmer
Path: i2pn2.org!i2pn.org!aioe.org!esscOFPPHccfjlxlZhKy2Q.user.gioia.aioe.org.POSTED!not-for-mail
From: jj4pub...@gmail.com (JJ)
Newsgroups: comp.os.msdos.programmer
Subject: Re: extending parameters
Date: Tue, 4 May 2021 18:48:57 +0700
Organization: Aioe.org NNTP Server
Lines: 38
Message-ID: <guop7qojrijt$.iwcz72x3sz1v.dlg@40tude.net>
References: <32913dab-8517-4ca2-8e4c-b7d01b517cb6n@googlegroups.com> <oavz329kvjp5$.o2a75nvbugyr$.dlg@40tude.net> <8bde3e8f-547e-4773-9901-9eae7f112256n@googlegroups.com> <1m2w5abax2z33$.1k9p9fnzeypqx$.dlg@40tude.net> <acc4dabc-28f5-4e83-a5f4-73698f80aebfn@googlegroups.com> <1ltwm68v43wrq.ib33n7k7gmgw.dlg@40tude.net> <60f490eb-728d-4767-90f2-5adaf20720f7n@googlegroups.com> <17x60hjtjd6dh.vfxs294kth7t.dlg@40tude.net> <c13ece80-33f2-4ab5-bcb7-c68120339391n@googlegroups.com> <d2snh6xuzu23$.1cfkbxt6yxhk4.dlg@40tude.net> <d2dba42b-d2bb-42d7-8bdd-9f433eefc4fan@googlegroups.com> <idq1p6llgqfv.1vkgq1lrlx8sv.dlg@40tude.net> <4568cc17-447e-4823-a8ce-1fb69af318cdn@googlegroups.com> <yf3qmurg0zwy$.z2wj9truynqj$.dlg@40tude.net> <82703a67-99fb-4488-8b39-09cae5c57af7n@googlegroups.com>
NNTP-Posting-Host: esscOFPPHccfjlxlZhKy2Q.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: 40tude_Dialog/2.0.15.84
X-Face: \*\`0(1j~VfYC>ebz[&O.]=,Nm\oRM{of,liRO#7Eqi4|!]!(Gs=Akgh{J)605>C9Air?pa d{sSZ09u+A7f<^paR"/NH_#<mE1S"hde\c6PZLUB[t/s5-+Iu5DSc?P0+4%,Hl
X-Bitcoin: 1LcqwCQBQmhcWfWsVEAeyLchkAY8ZfuMnS
X-Notice: Filtered by postfilter v. 0.9.2
 by: JJ - Tue, 4 May 2021 11:48 UTC

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.

Re: extending parameters

<e31f089b-e953-4a20-9cf7-cfaa7596df8en@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=9955&group=comp.os.msdos.programmer#9955

  copy link   Newsgroups: comp.os.msdos.programmer
X-Received: by 2002:ac8:7612:: with SMTP id t18mr23494358qtq.102.1620142763776; Tue, 04 May 2021 08:39:23 -0700 (PDT)
X-Received: by 2002:a05:622a:c8:: with SMTP id p8mr23086429qtw.145.1620142763637; Tue, 04 May 2021 08:39:23 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.os.msdos.programmer
Date: Tue, 4 May 2021 08:39:23 -0700 (PDT)
In-Reply-To: <guop7qojrijt$.iwcz72x3sz1v.dlg@40tude.net>
Injection-Info: google-groups.googlegroups.com; posting-host=202.169.113.201; posting-account=CeHKkQoAAAAowY1GfiJYG55VVc0s1zaG
NNTP-Posting-Host: 202.169.113.201
References: <32913dab-8517-4ca2-8e4c-b7d01b517cb6n@googlegroups.com> <oavz329kvjp5$.o2a75nvbugyr$.dlg@40tude.net> <8bde3e8f-547e-4773-9901-9eae7f112256n@googlegroups.com> <1m2w5abax2z33$.1k9p9fnzeypqx$.dlg@40tude.net> <acc4dabc-28f5-4e83-a5f4-73698f80aebfn@googlegroups.com> <1ltwm68v43wrq.ib33n7k7gmgw.dlg@40tude.net> <60f490eb-728d-4767-90f2-5adaf20720f7n@googlegroups.com> <17x60hjtjd6dh.vfxs294kth7t.dlg@40tude.net> <c13ece80-33f2-4ab5-bcb7-c68120339391n@googlegroups.com> <d2snh6xuzu23$.1cfkbxt6yxhk4.dlg@40tude.net> <d2dba42b-d2bb-42d7-8bdd-9f433eefc4fan@googlegroups.com> <idq1p6llgqfv.1vkgq1lrlx8sv.dlg@40tude.net> <4568cc17-447e-4823-a8ce-1fb69af318cdn@googlegroups.com> <yf3qmurg0zwy$.z2wj9truynqj$.dlg@40tude.net> <82703a67-99fb-4488-8b39-09cae5c57af7n@googlegroups.com> <guop7qojrijt$.iwcz72x3sz1v.dlg@40tude.net>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <e31f089b-e953-4a20-9cf7-cfaa7596df8en@googlegroups.com>
Subject: Re: extending parameters
From: mutazi...@gmail.com (muta...@gmail.com)
Injection-Date: Tue, 04 May 2021 15:39:23 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 81
 by: muta...@gmail.com - Tue, 4 May 2021 15:39 UTC

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.

Re: extending parameters

<1l84xf45qgjea.soxkdjp1wiyz$.dlg@40tude.net>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=9956&group=comp.os.msdos.programmer#9956

  copy link   Newsgroups: comp.os.msdos.programmer
Path: i2pn2.org!i2pn.org!aioe.org!VOaEgAd/dsqvGSjWN9W6Og.user.gioia.aioe.org.POSTED!not-for-mail
From: jj4pub...@gmail.com (JJ)
Newsgroups: comp.os.msdos.programmer
Subject: Re: extending parameters
Date: Wed, 5 May 2021 17:05:36 +0700
Organization: Aioe.org NNTP Server
Lines: 46
Message-ID: <1l84xf45qgjea.soxkdjp1wiyz$.dlg@40tude.net>
References: <32913dab-8517-4ca2-8e4c-b7d01b517cb6n@googlegroups.com> <oavz329kvjp5$.o2a75nvbugyr$.dlg@40tude.net> <8bde3e8f-547e-4773-9901-9eae7f112256n@googlegroups.com> <1m2w5abax2z33$.1k9p9fnzeypqx$.dlg@40tude.net> <acc4dabc-28f5-4e83-a5f4-73698f80aebfn@googlegroups.com> <1ltwm68v43wrq.ib33n7k7gmgw.dlg@40tude.net> <60f490eb-728d-4767-90f2-5adaf20720f7n@googlegroups.com> <17x60hjtjd6dh.vfxs294kth7t.dlg@40tude.net> <c13ece80-33f2-4ab5-bcb7-c68120339391n@googlegroups.com> <d2snh6xuzu23$.1cfkbxt6yxhk4.dlg@40tude.net> <d2dba42b-d2bb-42d7-8bdd-9f433eefc4fan@googlegroups.com> <idq1p6llgqfv.1vkgq1lrlx8sv.dlg@40tude.net> <4568cc17-447e-4823-a8ce-1fb69af318cdn@googlegroups.com> <yf3qmurg0zwy$.z2wj9truynqj$.dlg@40tude.net> <82703a67-99fb-4488-8b39-09cae5c57af7n@googlegroups.com> <guop7qojrijt$.iwcz72x3sz1v.dlg@40tude.net> <e31f089b-e953-4a20-9cf7-cfaa7596df8en@googlegroups.com>
NNTP-Posting-Host: VOaEgAd/dsqvGSjWN9W6Og.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: 40tude_Dialog/2.0.15.84
X-Bitcoin: 1LcqwCQBQmhcWfWsVEAeyLchkAY8ZfuMnS
X-Notice: Filtered by postfilter v. 0.9.2
X-Face: \*\`0(1j~VfYC>ebz[&O.]=,Nm\oRM{of,liRO#7Eqi4|!]!(Gs=Akgh{J)605>C9Air?pa d{sSZ09u+A7f<^paR"/NH_#<mE1S"hde\c6PZLUB[t/s5-+Iu5DSc?P0+4%,Hl
 by: JJ - Wed, 5 May 2021 10:05 UTC

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?

Re: extending parameters

<e5297418-06c7-49fe-b845-e6793ffc6a90n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=9957&group=comp.os.msdos.programmer#9957

  copy link   Newsgroups: comp.os.msdos.programmer
X-Received: by 2002:ac8:5ccc:: with SMTP id s12mr2580774qta.362.1620215546287; Wed, 05 May 2021 04:52:26 -0700 (PDT)
X-Received: by 2002:a05:622a:174a:: with SMTP id l10mr26827279qtk.349.1620215546142; Wed, 05 May 2021 04:52:26 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.os.msdos.programmer
Date: Wed, 5 May 2021 04:52:25 -0700 (PDT)
In-Reply-To: <1l84xf45qgjea.soxkdjp1wiyz$.dlg@40tude.net>
Injection-Info: google-groups.googlegroups.com; posting-host=202.169.113.201; posting-account=CeHKkQoAAAAowY1GfiJYG55VVc0s1zaG
NNTP-Posting-Host: 202.169.113.201
References: <32913dab-8517-4ca2-8e4c-b7d01b517cb6n@googlegroups.com> <oavz329kvjp5$.o2a75nvbugyr$.dlg@40tude.net> <8bde3e8f-547e-4773-9901-9eae7f112256n@googlegroups.com> <1m2w5abax2z33$.1k9p9fnzeypqx$.dlg@40tude.net> <acc4dabc-28f5-4e83-a5f4-73698f80aebfn@googlegroups.com> <1ltwm68v43wrq.ib33n7k7gmgw.dlg@40tude.net> <60f490eb-728d-4767-90f2-5adaf20720f7n@googlegroups.com> <17x60hjtjd6dh.vfxs294kth7t.dlg@40tude.net> <c13ece80-33f2-4ab5-bcb7-c68120339391n@googlegroups.com> <d2snh6xuzu23$.1cfkbxt6yxhk4.dlg@40tude.net> <d2dba42b-d2bb-42d7-8bdd-9f433eefc4fan@googlegroups.com> <idq1p6llgqfv.1vkgq1lrlx8sv.dlg@40tude.net> <4568cc17-447e-4823-a8ce-1fb69af318cdn@googlegroups.com> <yf3qmurg0zwy$.z2wj9truynqj$.dlg@40tude.net> <82703a67-99fb-4488-8b39-09cae5c57af7n@googlegroups.com> <guop7qojrijt$.iwcz72x3sz1v.dlg@40tude.net> <e31f089b-e953-4a20-9cf7-cfaa7596df8en@googlegroups.com> <1l84xf45qgjea.soxkdjp1wiyz$.dlg@40tude.net>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <e5297418-06c7-49fe-b845-e6793ffc6a90n@googlegroups.com>
Subject: Re: extending parameters
From: mutazi...@gmail.com (muta...@gmail.com)
Injection-Date: Wed, 05 May 2021 11:52:26 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 87
 by: muta...@gmail.com - Wed, 5 May 2021 11:52 UTC

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.


devel / comp.os.msdos.programmer / extending parameters

Pages:12
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor