[hercules-os380] step down on the PC

[[e-mail] [hercules-os380]]

I wonder if there is utility for 32-bit PDOS/386
applications to reside below the 1 MiB line so
that they can step down to real mode before
calling OS (or more likely, BIOS) routines
that are not 32-bit clean. But after calling the
BIOS routine they return to protected mode
where they can access the ATL application
memory, explicitly obtained with LOC=32
instead of doing the default LOC=RES that
would get them scarce BTL memory.

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
I wonder if there is utility for 32-bit PDOS/386
applications to reside below the 1 MiB line so
that they can step down to real mode before

I don't think this is necessary. MVS only has
the need to step down for the I/O routines,
not SVCs. SVCs protect themselves. MSDOS
applications always use INT to get OS/BIOS
services.

What there is a need for is to run the equivalent
of AM24 programs. ie real mode MSDOS
programs. PDOS/386 should ideally see that
a .exe is MSDOS format and step down to
real mode to execute it, before returning to
protected mode.

BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

"What there is a need for is to run the equivalent
of AM24 programs. ie real mode MSDOS
programs. PDOS/386 should ideally see that
a .exe is MSDOS format and step down to
real mode to execute it, before returning to
protected mode."

Yeah ... thats why there is this little thing called DPMI (DOS protected
mode interface). You should learn about it.

https://en.wikipedia.org/wiki/DOS_Protected_Mode_Interface

Joe

Post by ***@yahoo.com.au [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
I wonder if there is utility for 32-bit PDOS/386
applications to reside below the 1 MiB line so
that they can step down to real mode before

I don't think this is necessary. MVS only has
the need to step down for the I/O routines,
not SVCs. SVCs protect themselves. MSDOS
applications always use INT to get OS/BIOS
services.
What there is a need for is to run the equivalent
of AM24 programs. ie real mode MSDOS
programs. PDOS/386 should ideally see that
a .exe is MSDOS format and step down to
real mode to execute it, before returning to
protected mode.
BFN. Paul.

[[e-mail] [hercules-os380]]

Post by Joe Monk ***@gmail.com [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
What there is a need for is to run the equivalent
of AM24 programs. ie real mode MSDOS
programs. PDOS/386 should ideally see that
a .exe is MSDOS format and step down to
real mode to execute it, before returning to
protected mode."

Yeah ... thats why there is this little thing called
DPMI (DOS protected mode interface). You should
learn about it.

From your link:

Because MS-DOS (as a standalone operating system) was never updated for 32 bits, nor enabled 24- or 32-bit addressing,

Microsoft didn't see the answer to the 32-bit transition as a 32-bit DOS, but rather a 32-bit Windows with a completely different (and incompatible) API.


This is where PDOS/386 fits in - what might have
been if Microsoft had kept the API compatible.

What I actually need is the reverse of DPMI.
A PRMI - PDOS/386 Real Mode Interface, so
that apps running on my 32-bit OS can call
16-bit real mode facilities.

I think. I'm not really sure how it should all
hang together, but PDOS/386 is advancing
quickly now. It's on the verge of having the
same flat address space that MVS has,
meaning my dream of accessing 0xb8000
directly will come to be.

BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

So you didn't read all the way...

"In computing <https://en.wikipedia.org/wiki/Computing>, the *DOS Protected
Mode Interface* (*DPMI*) is a specification introduced in 1989 which allows
a DOS <https://en.wikipedia.org/wiki/DOS> program to run in protected mode
<https://en.wikipedia.org/wiki/Protected_mode>, giving access to many
features of the new PC processors of the time not available in real mode
<https://en.wikipedia.org/wiki/Real_mode>."

"DPMI allows a program to run in protected mode
<https://en.wikipedia.org/wiki/Protected_mode> on 80286 series and later
processors and make calls back to the operating system running in Real
Mode."

DPMI is EXACTLY what you want ... it allows a real mode program to run
while executing in protected mode.

Joe

Post by ***@yahoo.com.au [hercules-os380]

Post by Joe Monk ***@gmail.com [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
What there is a need for is to run the equivalent
of AM24 programs. ie real mode MSDOS
programs. PDOS/386 should ideally see that
a .exe is MSDOS format and step down to
real mode to execute it, before returning to
protected mode."

Yeah ... thats why there is this little thing called
DPMI (DOS protected mode interface). You should
learn about it.

Because MS-DOS (as a standalone operating system) was never updated for 32
bits, nor enabled 24- or 32-bit addressing,
Microsoft didn't see the answer to the 32-bit transition as a 32-bit DOS,
but rather a 32-bit Windows with a completely different (and incompatible)
API.
This is where PDOS/386 fits in - what might have
been if Microsoft had kept the API compatible.
What I actually need is the reverse of DPMI.
A PRMI - PDOS/386 Real Mode Interface, so
that apps running on my 32-bit OS can call
16-bit real mode facilities.
I think. I'm not really sure how it should all
hang together, but PDOS/386 is advancing
quickly now. It's on the verge of having the
same flat address space that MVS has,
meaning my dream of accessing 0xb8000
directly will come to be.
BFN. Paul.

[[e-mail] [hercules-os380]]

No, I don't have a problem with programs running
in protected mode. Both PDOS/386 and the 32-bit
applications running under it will all execute in
protected mode, and that is already working.

What I want is the ability for PDOS/386 to run
real mode 8086 programs as well. Just like
z/OS can run 24-bit applications too.

There is v8086 mode:

https://en.wikipedia.org/wiki/Virtual_8086_mode

but that's not what I want. I don't want to write
a monitor so that I can run 8086 applications,
I want to drop down to real mode to run them,
the same as on MVS you really drop down to
AM24 to run AM24 applications.

BFN. Paul.




---In hercules-***@yahoogroups.com, <***@gmail.com> wrote :

So you didn't read all the way...

"In computing https://en.wikipedia.org/wiki/Computing, the DOS Protected Mode Interface (DPMI) is a specification introduced in 1989 which allows a DOS https://en.wikipedia.org/wiki/DOS program to run in protected mode https://en.wikipedia.org/wiki/Protected_mode, giving access to many features of the new PC processors of the time not available in real mode https://en.wikipedia.org/wiki/Real_mode."


"DPMI allows a program to run in protected mode https://en.wikipedia.org/wiki/Protected_mode on 80286 series and later processors and make calls back to the operating system running in Real Mode."



DPMI is EXACTLY what you want ... it allows a real mode program to run while executing in protected mode.


Joe

Post by Joe Monk ***@gmail.com [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
What there is a need for is to run the equivalent
of AM24 programs. ie real mode MSDOS
programs. PDOS/386 should ideally see that
a .exe is MSDOS format and step down to
real mode to execute it, before returning to
protected mode."

Yeah ... thats why there is this little thing called
DPMI (DOS protected mode interface). You should
learn about it.

From your link:

Because MS-DOS (as a standalone operating system) was never updated for 32 bits, nor enabled 24- or 32-bit addressing,

Microsoft didn't see the answer to the 32-bit transition as a 32-bit DOS, but rather a 32-bit Windows with a completely different (and incompatible) API.

This is where PDOS/386 fits in - what might have
been if Microsoft had kept the API compatible.

What I actually need is the reverse of DPMI.
A PRMI - PDOS/386 Real Mode Interface, so
that apps running on my 32-bit OS can call
16-bit real mode facilities.

I think. I'm not really sure how it should all
hang together, but PDOS/386 is advancing
quickly now. It's on the verge of having the
same flat address space that MVS has,
meaning my dream of accessing 0xb8000
directly will come to be.

BFN. Paul.

[[e-mail] [hercules-os380]]

If some portion of PDOS/386 was still 20-bit
real mode code *and* it provided some code
to be called by the user, then it would make
some sort of sense to keep a 32-bit application
in low memory and switch to AM20 prior to
calling the function.

But since everything is done via INTs, even
if a service (like the BIOS) is still 20-bit, it
is still callable from a 32-bit application so
long as the interrupt is defined in the
32-bit OS so that it can be translated into
a 20-bit call. There's no choice in this
regard - all the interrupts need to be
defined in protected mode, as the
addresses in the interrupt vector are
defined differently for AM20 vs AM32,
unlike on MVS where AM24 and AM31
SVCs are defined the same in the SVC
table.

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
defined in protected mode, as the
addresses in the interrupt vector are
defined differently for AM20 vs AM32,
unlike on MVS where AM24 and AM31
SVCs are defined the same in the SVC
table.

Basically it is the same as z/Arch with 64-bit
addresses in the SVC table in low storage,
even if the OS service still runs in AM31.

In the MVS situation the AM24 and AM31
were both really 32-bit values so the
20 vs 32 x86 situation didn't arise until
z/Arch.

BFN. Paul.

[[e-mail] [hercules-os380]]

If z/OS was mostly 64-bit, but it still needed
to cope with 31-bit legacy apps, then at the
point of the SVC it could keep things in AM31
to protect itself from crap in the high 32 bits,
record the caller's status (AM31) and
registers, and then clear out the crap in the
top 32 bits, then switch to AM64 and call
the main z/OS functionality that resides
above 4 GiB.

PDOS/386 needs to do the same thing as
this theoretical new version of z/OS.

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
If z/OS was mostly 64-bit, but it still needed
to cope with 31-bit legacy apps, then at the
point of the SVC it could keep things in AM31
to protect itself from crap in the high 32 bits,

Actually, the SVC routines should keep things
in AM24 to protect against crap in the top 40
bits, and only switch to AM31 or AM64 when
it is operating with clean registers.

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
Actually, the SVC routines should keep things
in AM24 to protect against crap in the top 40
bits, and only switch to AM31 or AM64 when
it is operating with clean registers.

No, there is nothing special about AM24 or 31.
The OS needs to assume that the full 64 bits
are full of someone else's crap and load them
with data valid for whatever AMODE the OS
SVC is choosing to run in.

BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

"I want to drop down to real mode to run them,
the same as on MVS you really drop down to
AM24 to run AM24 applications."

"The UEFI Forum never envisioned supporting 32-bit and 64-bit architectures
on the same device. Consequently, the UEFI specification does not offer
provisions for dual-mode boot. Ultimately, it is up to the implementers to
decide which processor(s) to support. Any implementation that attempts to
provide 32-bit and 64-bit UEFI boot support on the same system would
require a proprietary solution, and therefore would not be appropriate for
an industry wide specification. From the UEFI Forum’s perspective, this
proprietary matter should ensure industry interoperability to support
technological growth."

Now you understand why SysWOW64 exists...

Joe

Post by ***@yahoo.com.au [hercules-os380]
No, I don't have a problem with programs running
in protected mode. Both PDOS/386 and the 32-bit
applications running under it will all execute in
protected mode, and that is already working.
What I want is the ability for PDOS/386 to run
real mode 8086 programs as well. Just like
z/OS can run 24-bit applications too.
https://en.wikipedia.org/wiki/Virtual_8086_mode
but that's not what I want. I don't want to write
a monitor so that I can run 8086 applications,
I want to drop down to real mode to run them,
the same as on MVS you really drop down to
AM24 to run AM24 applications.
BFN. Paul.
So you didn't read all the way...
"In computing https://en.wikipedia.org/wiki/Computing, the DOS Protected
Mode Interface (DPMI) is a specification introduced in 1989 which allows a
DOS https://en.wikipedia.org/wiki/DOS program to run in protected mode
https://en.wikipedia.org/wiki/Protected_mode, giving access to many
features of the new PC processors of the time not available in real mode
https://en.wikipedia.org/wiki/Real_mode."
"DPMI allows a program to run in protected mode
https://en.wikipedia.org/wiki/Protected_mode on 80286 series and later
processors and make calls back to the operating system running in Real
Mode."
DPMI is EXACTLY what you want ... it allows a real mode program to run
while executing in protected mode.
Joe

Post by Joe Monk ***@gmail.com [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
What there is a need for is to run the equivalent
of AM24 programs. ie real mode MSDOS
programs. PDOS/386 should ideally see that
a .exe is MSDOS format and step down to
real mode to execute it, before returning to
protected mode."

Yeah ... thats why there is this little thing called
DPMI (DOS protected mode interface). You should
learn about it.

Because MS-DOS (as a standalone operating system) was never updated for 32
bits, nor enabled 24- or 32-bit addressing,
Microsoft didn't see the answer to the 32-bit transition as a 32-bit DOS,
but rather a 32-bit Windows with a completely different (and incompatible)
API.
This is where PDOS/386 fits in - what might have
been if Microsoft had kept the API compatible.
What I actually need is the reverse of DPMI.
A PRMI - PDOS/386 Real Mode Interface, so
that apps running on my 32-bit OS can call
16-bit real mode facilities.
I think. I'm not really sure how it should all
hang together, but PDOS/386 is advancing
quickly now. It's on the verge of having the
same flat address space that MVS has,
meaning my dream of accessing 0xb8000
directly will come to be.
BFN. Paul.

[[e-mail] [hercules-os380]]

I have thought of an equivalent of step down
on the PC.

If I have a 32-bit PDOS/386 application that
wishes to do 16/20-bit BIOS calls, it will be
necessary for the program to be loaded
BTL so that it can request a step-down and
carry out the BIOS call.

HOWEVER, there is probably no need to do
this as I have made a 32-bit interface available
to the BIOS calls, and the app can just
execute those instead and stay ATL at all
times.

I guess if there were a lot of BIOS calls the
app could choose to step down itself and
do all that work before returning to AM32.
Also if the 32-bit BIOS interface was
deemed to be insufficient (perhaps the
register use is inappropriate) or some of the
calls were missing from PDOS/386.

Supporting a step-down means that obscure
vendor-specific BIOS calls will all be catered
for. As I was only planning on adding the
main ones.

And of course I'm also planning on supporting
AM20 applications such that whenever they
do a MSDOS call it gets translated into a
switch to AM32 and executed by the main
PDOS/386 code.

BFN. Paul.

[[e-mail] [hercules-os380]]

And that means I need an executable format
on the PC that has AMODE and RMODE
in it, so that I can have AM20/RM20, AM32/RM20
and AM32/RM32 applications all running.

And of course there is 64-bit to be added
at some point.

Currently the executable format I am using
is called "a.out":

http://man.cat-v.org/unix_8th/5/a.out

and it is a pure 32-bit format.

And we already have a pure AM20/RM20
format too.

What we're missing is a format that does
AM32/RM20. And we're also missing a
protocol for the AM32 application to
request a step-down to AM20 in order
to run application code. I'm not sure
whether a DOS-extender program
could qualify for that. A DOS extender
is basically a 32-bit program that was
started from AM20 mode and the
application itself remains in AM32. That's
a different concept.

BFN. Paul.

[[e-mail] [hercules-os380]]

And the A20 line on the PC was somewhat the
equivalent of storing crap in the address bits
and expecting them to be masked, effectively
meaning address wrapping.

So we could have an expectation that whenever
a 32-bit application steps down to AM20 the
A20 line is disabled. Or we can assume that
the line should stay enabled so that the
high 64k (with segment register of 0xffff) can
be addressable. Maybe the executable
format should specify whether it requires
the AM20 line disabled. Or the reverse - that
it can run with it enabled. Default to the
worst case. Or have a PDOS/386 option to
say what we should do, given that this
flag probably doesn't exist in the MSDOS
executable format (unfortunately, and
unlike MVS).

BFN. Paul.

[[e-mail] [hercules-os380]]

I thought of a difference between the PC
and mainframe.

If a 24-bit program does an SVC on z/Arch
it will invoke z/Arch low-memory interrupt
vectors allowing the OS code to be run in
AM31 or AM64.

But an AM20 program on the PC needs
low memory to contain real mode addresses.
That's just the way that "INT" works when
you're in that mode.

I was wondering whether I could get the
equivalent of z/Arch behavior by running
in 16-bit protected mode, but that appears
to be something else entirely.

So it appears that I will need glue code in
the form of 16-bit interrupt handlers that can
convert a 16-bit INT call into a 32-bit OS
call.

This seems to be a curious difference
between the PC and mainframe. It appears
that I am now in the process of trying to
make the PC the same as the mainframe. :-)

BFN. Paul.

[Gerhard Postpischil [e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
So it appears that I will need glue code in
the form of 16-bit interrupt handlers that can
convert a 16-bit INT call into a 32-bit OS
call.

There is a fairly nice book describing how OS/2 handles the interface.
Right now I couldn't find it either with Google or on amazon.com

Post by ***@yahoo.com.au [hercules-os380]
This seems to be a curious difference
between the PC and mainframe. It appears
that I am now in the process of trying to
make the PC the same as the mainframe. :-)

I doubt that you'll get very far - the hardware capabilities are just
too different.

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
https://www.avg.com

[[e-mail] [hercules-os380]]

Post by Gerhard Postpischil ***@charter.net [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
This seems to be a curious difference
between the PC and mainframe. It appears
that I am now in the process of trying to
make the PC the same as the mainframe. :-)

I doubt that you'll get very far - the hardware capabilities are just
too different.

Well I was looking at the GETMAIN internals
and I think most of that needs to be copied
in a PDOS/386 API, ie subpool number and
LOC bits. Not sure about the rest.

BFN. Paul.

[Gerhard Postpischil [e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
Well I was looking at the GETMAIN internals
and I think most of that needs to be copied
in a PDOS/386 API, ie subpool number and
LOC bits. Not sure about the rest.

I was thinking more along the likes of interrupts. concurrent I/O, and
similar.


Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
https://www.avg.com

[[e-mail] [hercules-os380]]

Post by Gerhard Postpischil ***@charter.net [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
Well I was looking at the GETMAIN internals
and I think most of that needs to be copied
in a PDOS/386 API, ie subpool number and
LOC bits. Not sure about the rest.

I was thinking more along the likes of interrupts.
concurrent I/O, and similar.

My focus is on the application programs. Why
should MVS be going to the effort of making a
Posix-compliant environment instead of Linux
being an MVS-compliant environment?

And by switching to and promoting the MSDOS
API, it helps abstract the problem.

BFN. Paul.