windows

[muta...@gmail.com]

Windows 64-bit removed the ability to run RM16
DOS executables.

It might be related to VM86 not being available in
long mode.

Would it theoretically be easier to run PM16 programs
(instead of RM16) in 64-bit Windows if they had been
written "nicely"?

I'm only interested in console mode. Only interested in
programs without bugs and that follow all published
rules.

Can someone create a definition of "nice" that we could
have had in 1983?

Thanks. Paul.

[Joe Monk]

> Windows 64-bit removed the ability to run RM16
> DOS executables.
>

This is not quite true. It was actually stopped from being installed by default on Windows XP.

NTVDM is now classified as a "feature on demand". It is not automatically installed, but is still available on 32-bit versions up to Windows 10 ( There is no 32-bit version of Windows 11).

To install: open a command prompt as an administrator and type: DISM /online /enable-feature /all /featurename:NTVDM However, be aware thata the NTVDM code is no longer actively maintained, so what you get is what you get.

Joe

[muta...@gmail.com]

Ok, but I want to run 64-bit Windows, and I note that
long mode (but not legacy mode) of the x64 supports
PM16.

So I'm wondering if I can do *something*.

BFN. Paul.

[Joe Monk]

> Ok, but I want to run 64-bit Windows, and I note that
> long mode (but not legacy mode) of the x64 supports
> PM16.
>

No, it doesnt. Long mode supports CM16 (compatibility mode).

"When long mode is active and CS.L is cleared to 0, the processor is in compatibility mode, as shown in Table 14-4 on page 436. In compatibility mode, CS.D controls default operand and address sizes exactly as it does in the legacy x86 architecture. Setting CS.D to 1 specifies default operand and address sizes as 32 bits. Clearing CS.D to 0 specifies default operand and address sizes as 16 bits."

http://developer.amd.com/wordpress/media/2012/10/24593_APM_v2.pdf

Joe

[Scott Lurndal]

"muta...@gmail.com" <muta...@gmail.com> writes:
>Windows 64-bit removed the ability to run RM16
>DOS executables.
>
>It might be related to VM86 not being available in
>long mode.
>
>Would it theoretically be easier to run PM16 programs
>(instead of RM16) in 64-bit Windows if they had been
>written "nicely"?

It would be easiest to convert PM16 programs to 64-bit.

PM16 is dead, Jim.

[JJ]

On Thu, 17 Nov 2022 01:59:59 -0800 (PST), muta...@gmail.com wrote:
>
> So I'm wondering if I can do *something*.
>
> BFN. Paul.

With some hackery, and with great difficulty - considering that the kernel
internal is a black box. Keep in mind that, the kernel's task switcher is
designed only for 64-bit mode and CM32.

It'd be simpler to fork winevdm to improve its 16-bit compatibility, and add
real mode support.

[muta...@gmail.com]

On Friday, November 18, 2022 at 2:46:20 AM UTC+8, JJ wrote:
> On Thu, 17 Nov 2022 01:59:59 -0800 (PST), muta...@gmail.com wrote:
> >
> > So I'm wondering if I can do *something*.
> >
> > BFN. Paul.
> With some hackery, and with great difficulty - considering that the kernel
> internal is a black box. Keep in mind that, the kernel's task switcher is
> designed only for 64-bit mode and CM32.

Ok, in that case, could Microsoft support CM16 if they
wanted to?

And if so, what sort of things could I run under it? Would
it need a new API or would the OS/2 1.0 API be suitable
for the task at hand?

Again, I'm only interested in console mode applications.

> It'd be simpler to fork winevdm to improve its 16-bit compatibility, and add
> real mode support.

Does that run at native speed?

Thanks. Paul.

[muta...@gmail.com]

On Thursday, November 17, 2022 at 7:53:26 PM UTC+8, Joe Monk wrote:
> > Ok, but I want to run 64-bit Windows, and I note that
> > long mode (but not legacy mode) of the x64 supports
> > PM16.
> >
> No, it doesnt. Long mode supports CM16 (compatibility mode).

Is there a difference that I would care about?

BFN. Paul.

[Alexei A. Frounze]

You can build your 16-bit support on 64-bit Windows around Hyper-V.
See the API:
https://learn.microsoft.com/en-us/virtualization/api/hypervisor-platform/hypervisor-platform

Looks like QEMU, VirtualBox, WineVDM use it.

If I understand it correctly (it's been years since I did anything in/with Hyper-V), you'll need to
implement all the necessary x86 devices yourself (PIC, PIT, DMA, VGA, serial port,
keyboard, mouse, FDC, HDC, SB, etc etc) and throw in a BIOS of some kind.

Or you could just run DOSBox or a regular VM with FreeDOS instead of reinventing everything.

Alex

[JJ]

On Thu, 17 Nov 2022 15:01:04 -0800 (PST), muta...@gmail.com wrote:
>
> Ok, in that case, could Microsoft support CM16 if they
> wanted to?

Yes, they could if they want to.

> And if so, what sort of things could I run under it? Would
> it need a new API or would the OS/2 1.0 API be suitable
> for the task at hand?

Any code which is designed for pure 16-bit protected mode.

> Again, I'm only interested in console mode applications.

16-bit windows platform doesn't have a native console. Console support are
provided for real mode programs. Same thing applies to OS/2.

> Does that run at native speed?

No. 16-bit code is run using interpreter. Although it includes support for
using Intel HAXM where 16-bit code is run using virtualization, it seems
that it's not fully working yet.

[muta...@gmail.com]

On Saturday, November 19, 2022 at 3:25:48 AM UTC+8, JJ wrote:

> > Ok, in that case, could Microsoft support CM16 if they
> > wanted to?

> Yes, they could if they want to.

Ok, thanks. In that case, maybe I'll get a 64-bit PDOS
running, and add 16-bit support, with the knowledge
that Microsoft can do it themselves if they wish.

> > And if so, what sort of things could I run under it? Would
> > it need a new API or would the OS/2 1.0 API be suitable
> > for the task at hand?

> Any code which is designed for pure 16-bit protected mode.

A C-generated executable normally doesn't manipulate
segment registers/selectors. That's what I'm interested
in. Large memory model is the main thing I want. I assume
lds still works to load a selector instead of a segment.

> > Again, I'm only interested in console mode applications.

> 16-bit windows platform doesn't have a native console. Console support are
> provided for real mode programs. Same thing applies to OS/2.

I only used OS/2 2.0, and I could do this:

unsigned long hfile; /* OS/2 file handle */

rc = DosWrite(stream->hfile, (VOID *)ptr, towrite, &tempWritten);

Did this function not exist in 1.0?

If it did exist, that's all I need, isn't it?

Windows 12/13 could support a 16-bit DosWrite that writes
to a console and supports ANSI controls for both input and
output, couldn't it?

Any other existing option besides DosWrite? Did 16-bit
Windows have nothing the equivalent of that?

> > Does that run at native speed?

> No. 16-bit code is run using interpreter. Although it includes support for
> using Intel HAXM where 16-bit code is run using virtualization, it seems
> that it's not fully working yet.

My desire is to run an unkludged executable on that CM16
at native speed.

I'm just wondering what sort of things I can stick on that.
Is anyone currently using it for anything?

Some people climb mountains because they exist.

I want to exercise CM16 because it exists.

Thanks. Paul.

[muta...@gmail.com]

On Friday, November 18, 2022 at 9:19:46 AM UTC+8, Alexei A. Frounze wrote:

> You can build your 16-bit support on 64-bit Windows around Hyper-V.

I don't want a virtual machine. I want to use the same machine
that currently lets me run 32-bit and 64-bit executables from
the command prompt.

Ideally I would not even know that I am running a 16-bit
executable (as was the case with 32-bit Windows
command prompt).

But if Microsoft is unwilling to provide 16-bit support I
am willing to design 16-bit applications that will work
under a theoretical PDOS/x64, but while waiting for
that, I could instead use a kernel mode 32-bit app to
switch to CM16 (or perhaps set the D-bits while staying
in CM32), run my 16-bit app (which does no interrupts,
since it is PDOS-generic), returns to CM32 and switches
the D-bits back without Windows even being aware
what happened.

I do something similar with MVS/380. The OS is unaware
that the app switched to AM31 and back again.

> If I understand it correctly (it's been years since I did anything in/with Hyper-V), you'll need to
> implement all the necessary x86 devices yourself (PIC, PIT, DMA, VGA, serial port,
> keyboard, mouse, FDC, HDC, SB, etc etc) and throw in a BIOS of some kind.

I want to avoid all that. I want to switch back to 32-bit
mode to service the 16-bit API call.

If Microsoft has an official API I would be happy to call
a 16-bit interrupt or DLL in that case.

BFN. Paul.

[muta...@gmail.com]

On Saturday, November 19, 2022 at 5:59:22 AM UTC+8, muta...@gmail.com wrote:

> But if Microsoft is unwilling to provide 16-bit support I
> am willing to design 16-bit applications that will work
> under a theoretical PDOS/x64, but while waiting for
> that, I could instead use a kernel mode 32-bit app to
> switch to CM16 (or perhaps set the D-bits while staying
> in CM32), run my 16-bit app (which does no interrupts,
> since it is PDOS-generic), returns to CM32 and switches
> the D-bits back without Windows even being aware
> what happened.

Actually, I just realized I could do the same thing to get
16-bit PDOS-generic apps to run under PDOS/386.
Currently there is no 16-bit support for PDOS/386.

BFN. Paul.

[muta...@gmail.com]

On Saturday, November 19, 2022 at 3:25:48 AM UTC+8, JJ wrote:

> > Again, I'm only interested in console mode applications.

> 16-bit windows platform doesn't have a native console. Console support are
> provided for real mode programs. Same thing applies to OS/2.

Hang on a second. I thought OS/2 1.0 was ONLY console
mode, and graphics was only added in OS/2 1.1?

Also, with regards to the 16-bit Windows API. Did it not
also have a WriteFile() function or similar? If so, can you
not write to stdout? If Windows didn't natively support
such a concept, could another Windows app create a
window and do a pipe or whatever to capture the output
of stdout from such a program?

That is the technique being used in PdAndro:

https://github.com/jeanmarclienher/Pdos-PdAndro

BFN. Paul.

[muta...@gmail.com]

On Thursday, November 17, 2022 at 10:53:53 PM UTC+8, Scott Lurndal wrote:

> >Would it theoretically be easier to run PM16 programs
> >(instead of RM16) in 64-bit Windows if they had been
> >written "nicely"?

> It would be easiest to convert PM16 programs to 64-bit.
>
> PM16 is dead, Jim.

People are still doing 8-bit programming.

And I just realized that those people are doing 8:8 segmentation.

I don't know if anyone is doing 16:16 programming.

But they are presumably at least doing 16-bit flat.

I like the idea of supporting and testing 16-bit toolchains
and applications on a PC. Even if you end up cross-compiling
for the target machine.

Yes, you can use an emulator instead.

And yes, you can go to the beach instead.

BFN. Paul.

[muta...@gmail.com]

Actually, how about a privileged Windows program,
hopefully 32-bit but 64-bit would be possible, that
disables interrupts, switches to CM16/PM16/RM16,
runs the PDOS-generic app until it does an API call,
then switches back to CM32/long mode, reenables
interrupts and services the API request?

I only care about well-behaved 16-bit programs.

I would need some real memory in order to do this.
Can Windows give me that?

Also, does Windows actually use the memory below
1 MB?

Thanks. Paul.

[Alexei A. Frounze]

On Friday, November 18, 2022 at 1:59:22 PM UTC-8, muta...@gmail.com wrote:
> On Friday, November 18, 2022 at 9:19:46 AM UTC+8, Alexei A. Frounze wrote:
>
> > You can build your 16-bit support on 64-bit Windows around Hyper-V.
> I don't want a virtual machine. I want to use the same machine
> that currently lets me run 32-bit and 64-bit executables from
> the command prompt.

The modern Windows doesn't support your scenario.
Which is in part because the modern x86 CPU doesn't support it.

And the modern PC doesn't necessarily support it either (e.g. there can be no
BIOS or VGA on whose availability you could rely some 20 years ago,
now there's EFI).

> Ideally I would not even know that I am running a 16-bit
> executable (as was the case with 32-bit Windows
> command prompt).
>
> But if Microsoft is unwilling to provide 16-bit support I
> am willing to design 16-bit applications that will work
> under a theoretical PDOS/x64, but while waiting for
> that, I could instead use a kernel mode 32-bit app to
> switch to CM16 (or perhaps set the D-bits while staying
> in CM32), run my 16-bit app (which does no interrupts,
> since it is PDOS-generic), returns to CM32 and switches
> the D-bits back without Windows even being aware
> what happened.

Microsoft doesn't want your code running freely in kernel mode.

And that's another blow to your dreams.

> I do something similar with MVS/380. The OS is unaware
> that the app switched to AM31 and back again.
> > If I understand it correctly (it's been years since I did anything in/with Hyper-V), you'll need to
> > implement all the necessary x86 devices yourself (PIC, PIT, DMA, VGA, serial port,
> > keyboard, mouse, FDC, HDC, SB, etc etc) and throw in a BIOS of some kind.
> I want to avoid all that. I want to switch back to 32-bit
> mode to service the 16-bit API call.
>
> If Microsoft has an official API I would be happy to call
> a 16-bit interrupt or DLL in that case.

There just isn't. Get over it. Run DOSBox or a VM.
Or stick to old Windows on old PCs while you still can (if you can).

Alex

[JJ]

On Fri, 18 Nov 2022 13:37:57 -0800 (PST), muta...@gmail.com wrote:
>
> A C-generated executable normally doesn't manipulate
> segment registers/selectors. That's what I'm interested
> in. Large memory model is the main thing I want. I assume
> lds still works to load a selector instead of a segment.

It depends on which platform it's compiled for. The memory management
functions from the runtime library would treat segment registers
differently.

> I only used OS/2 2.0, and I could do this:
>
> unsigned long hfile; /* OS/2 file handle */
>
> rc = DosWrite(stream->hfile, (VOID *)ptr, towrite, &tempWritten);
>
> Did this function not exist in 1.0?
>
> If it did exist, that's all I need, isn't it?
>
> Windows 12/13 could support a 16-bit DosWrite that writes
> to a console and supports ANSI controls for both input and
> output, couldn't it?
>
> Any other existing option besides DosWrite? Did 16-bit
> Windows have nothing the equivalent of that?

Since there's no 16-bit Windows application which is a console type, there's
no equivalent function in Windows. 16-bit Windows application can not have
its own console. In 16-bit Windows, consoles only belong to DOS
applications.

> My desire is to run an unkludged executable on that CM16
> at native speed.
>
> I'm just wondering what sort of things I can stick on that.
> Is anyone currently using it for anything?
>
> Some people climb mountains because they exist.
>
> I want to exercise CM16 because it exists.
>
> Thanks. Paul.

CM16 is not quite useful. CM16 only exist for backward compatibility. It's
only useful for existing softwares. It's not useful for a new 64-bit OS
since there's no advantage of creating 16-bit applications for 64-bit OS.

[muta...@gmail.com]

On Saturday, November 19, 2022 at 11:59:09 AM UTC+8, Alexei A. Frounze wrote:

> On Friday, November 18, 2022 at 1:59:22 PM UTC-8, muta...@gmail.com wrote:
> > On Friday, November 18, 2022 at 9:19:46 AM UTC+8, Alexei A. Frounze wrote:
> >
> > > You can build your 16-bit support on 64-bit Windows around Hyper-V.
> > I don't want a virtual machine. I want to use the same machine
> > that currently lets me run 32-bit and 64-bit executables from
> > the command prompt.

> The modern Windows doesn't support your scenario.
> Which is in part because the modern x86 CPU doesn't support it.

It does - CM16.

> And the modern PC doesn't necessarily support it either (e.g. there can be no
> BIOS or VGA on whose availability you could rely some 20 years ago,
> now there's EFI).

I don't need either BIOS or VGA for PDOS-generic applications.
Or even the "INT" instruction.

> > Ideally I would not even know that I am running a 16-bit
> > executable (as was the case with 32-bit Windows
> > command prompt).
> >
> > But if Microsoft is unwilling to provide 16-bit support I
> > am willing to design 16-bit applications that will work
> > under a theoretical PDOS/x64, but while waiting for
> > that, I could instead use a kernel mode 32-bit app to
> > switch to CM16 (or perhaps set the D-bits while staying
> > in CM32), run my 16-bit app (which does no interrupts,
> > since it is PDOS-generic), returns to CM32 and switches
> > the D-bits back without Windows even being aware
> > what happened.

> Microsoft doesn't want your code running freely in kernel mode.
>
> And that's another blow to your dreams.

They don't stop me installing privileged programs currently,
I believe.

> > I do something similar with MVS/380. The OS is unaware
> > that the app switched to AM31 and back again.
> > > If I understand it correctly (it's been years since I did anything in/with Hyper-V), you'll need to
> > > implement all the necessary x86 devices yourself (PIC, PIT, DMA, VGA, serial port,
> > > keyboard, mouse, FDC, HDC, SB, etc etc) and throw in a BIOS of some kind.
> > I want to avoid all that. I want to switch back to 32-bit
> > mode to service the 16-bit API call.
> >
> > If Microsoft has an official API I would be happy to call
> > a 16-bit interrupt or DLL in that case.

> There just isn't. Get over it. Run DOSBox or a VM.
> Or stick to old Windows on old PCs while you still can (if you can).

None of those things exercise CM16, which is what I am
interested in.

BFN. Paul.

[muta...@gmail.com]

On Saturday, November 19, 2022 at 3:06:53 PM UTC+8, JJ wrote:
> On Fri, 18 Nov 2022 13:37:57 -0800 (PST), muta...@gmail.com wrote:
> >
> > A C-generated executable normally doesn't manipulate
> > segment registers/selectors. That's what I'm interested
> > in. Large memory model is the main thing I want. I assume
> > lds still works to load a selector instead of a segment.

> It depends on which platform it's compiled for. The memory management
> functions from the runtime library would treat segment registers
> differently.

I will freshly compile it for whatever works. I provide my own
runtime library.

> > I only used OS/2 2.0, and I could do this:
> >
> > unsigned long hfile; /* OS/2 file handle */
> >
> > rc = DosWrite(stream->hfile, (VOID *)ptr, towrite, &tempWritten);
> >
> > Did this function not exist in 1.0?
> >
> > If it did exist, that's all I need, isn't it?
> >
> > Windows 12/13 could support a 16-bit DosWrite that writes
> > to a console and supports ANSI controls for both input and
> > output, couldn't it?
> >
> > Any other existing option besides DosWrite? Did 16-bit
> > Windows have nothing the equivalent of that?

> Since there's no 16-bit Windows application which is a console type, there's
> no equivalent function in Windows. 16-bit Windows application can not have
> its own console. In 16-bit Windows, consoles only belong to DOS
> applications.

Do you now agree that 16-bit OS/2 supported a console
at least?

If so, that might be my target API.

> > My desire is to run an unkludged executable on that CM16
> > at native speed.
> >
> > I'm just wondering what sort of things I can stick on that.
> > Is anyone currently using it for anything?
> >
> > Some people climb mountains because they exist.
> >
> > I want to exercise CM16 because it exists.

> CM16 is not quite useful. CM16 only exist for backward compatibility. It's
> only useful for existing softwares. It's not useful for a new 64-bit OS
> since there's no advantage of creating 16-bit applications for 64-bit OS.

Backward compatibility with ... what?

What API can I use in CM16 and can I create a new API if I want?

I have no comment on whether it will be useful or not.

When I started writing PDPCLIB, someone asked me why
I was going to so much effort to create something that
came free with every compiler. I didn't have a particularly
good answer at the time.

About a decade later, gccmvs and MVS/380 were born
as a result.

BFN. Paul.

[muta...@gmail.com]

On Saturday, November 19, 2022 at 3:06:53 PM UTC+8, JJ wrote:

> > Any other existing option besides DosWrite? Did 16-bit
> > Windows have nothing the equivalent of that?

> Since there's no 16-bit Windows application which is a console type, there's
> no equivalent function in Windows. 16-bit Windows application can not have
> its own console. In 16-bit Windows, consoles only belong to DOS
> applications.

Also, I assume it was physically possible to create an executable
that did a WriteFile to something resembling stdout. But due to
the absence of a console the output just disappeared.

But if I replace 16-bit Windows with my own 16-bit Windows (that is
console mode only), would that executable suddenly start working?

Or is there something missing from the executable technically?

I assume any WriteFile to actual files works fine, even if I only
provide a console.

BFN. Paul.

[Alexei A. Frounze]

On Saturday, November 19, 2022 at 5:34:04 AM UTC-8, muta...@gmail.com wrote:
> On Saturday, November 19, 2022 at 11:59:09 AM UTC+8, Alexei A. Frounze wrote:
>
> > On Friday, November 18, 2022 at 1:59:22 PM UTC-8, muta...@gmail.com wrote:
> > > On Friday, November 18, 2022 at 9:19:46 AM UTC+8, Alexei A. Frounze wrote:
> > >
> > > > You can build your 16-bit support on 64-bit Windows around Hyper-V.
> > > I don't want a virtual machine. I want to use the same machine
> > > that currently lets me run 32-bit and 64-bit executables from
> > > the command prompt.
>
> > The modern Windows doesn't support your scenario.
> > Which is in part because the modern x86 CPU doesn't support it.
> It does - CM16.

Originally you wanted real mode if I remember correctly.
Sticking arbitrary selector values into segment registers is going to be
problematic in protected mode, unless you restrict everything to a single
pre-existing segment.
On top of that, the OS needs to know how to properly support processes
running in 16-bit compatibility mode. That support is likely absent from the kernel.
So you're looking into hacking the system into providing such a support.
This goes far beyond your " written "nicely" ".

> > And the modern PC doesn't necessarily support it either (e.g. there can be no
> > BIOS or VGA on whose availability you could rely some 20 years ago,
> > now there's EFI).
> I don't need either BIOS or VGA for PDOS-generic applications.
> Or even the "INT" instruction.

Then why do you even care about running the code natively on the CPU?
How are you going to benefit from it? Do you want to run ancient software
at speeds it was never intended for? This would be about the only benefit.
Any other I'm missing?
Emulating the i80486 instruction set (more than sufficient HW for DOS SW)
is a problem that is bound and has been solved many times. You can just
do it without hacking Windows. Plenty of CPU cycles, RAM bytes and disk
sectors to go around for this nowadays.

> > > Ideally I would not even know that I am running a 16-bit
> > > executable (as was the case with 32-bit Windows
> > > command prompt).
> > >
> > > But if Microsoft is unwilling to provide 16-bit support I
> > > am willing to design 16-bit applications that will work
> > > under a theoretical PDOS/x64, but while waiting for
> > > that, I could instead use a kernel mode 32-bit app to
> > > switch to CM16 (or perhaps set the D-bits while staying
> > > in CM32), run my 16-bit app (which does no interrupts,
> > > since it is PDOS-generic), returns to CM32 and switches
> > > the D-bits back without Windows even being aware
> > > what happened.
>
> > Microsoft doesn't want your code running freely in kernel mode.
> >
> > And that's another blow to your dreams.
> They don't stop me installing privileged programs currently,
> I believe.

You may be able to install unsigned drivers, but it's not kosher
outside of development of software for Windows.
And if not already, there may be limitations associated with it
(other than the warning messages).

> > > I do something similar with MVS/380. The OS is unaware
> > > that the app switched to AM31 and back again.
> > > > If I understand it correctly (it's been years since I did anything in/with Hyper-V), you'll need to
> > > > implement all the necessary x86 devices yourself (PIC, PIT, DMA, VGA, serial port,
> > > > keyboard, mouse, FDC, HDC, SB, etc etc) and throw in a BIOS of some kind.
> > > I want to avoid all that. I want to switch back to 32-bit
> > > mode to service the 16-bit API call.
> > >
> > > If Microsoft has an official API I would be happy to call
> > > a 16-bit interrupt or DLL in that case.
>
> > There just isn't. Get over it. Run DOSBox or a VM.
> > Or stick to old Windows on old PCs while you still can (if you can).
> None of those things exercise CM16, which is what I am
> interested in.

Using Hyper-V you get a way to run your 16-bit SW (real mode or
protected) as close to native as possible without crippling or hacking
Windows.

Alex

[muta...@gmail.com]

On Sunday, November 20, 2022 at 5:57:22 AM UTC+8, Alexei A. Frounze wrote:

> > > The modern Windows doesn't support your scenario.
> > > Which is in part because the modern x86 CPU doesn't support it.
> > It does - CM16.
> Originally you wanted real mode if I remember correctly.

Originally when? This is a new thread for a reason.
I didn't ask for RM16.

> Sticking arbitrary selector values into segment registers is going to be
> problematic in protected mode, unless you restrict everything to a single
> pre-existing segment.

I was hoping to switch the GDT. But I need to know where
to find the old one to be able to switch back.

> On top of that, the OS needs to know how to properly support processes
> running in 16-bit compatibility mode. That support is likely absent from the kernel.

It can be either added by Microsoft properly if they want,
or I can hack around without their knowledge.

> So you're looking into hacking the system into providing such a support.
> This goes far beyond your " written "nicely" ".

Sorry for the confusion.

I want the 16-bit *apps* to be written nicely.

I don't care about what happens outside of the executable
(disabling interrupts so that I can change the GDT, crashing
all of Windows on the first bug, or anything else).

> > > And the modern PC doesn't necessarily support it either (e.g. there can be no
> > > BIOS or VGA on whose availability you could rely some 20 years ago,
> > > now there's EFI).
> > I don't need either BIOS or VGA for PDOS-generic applications.
> > Or even the "INT" instruction.

> Then why do you even care about running the code natively on the CPU?
> How are you going to benefit from it? Do you want to run ancient software
> at speeds it was never intended for?

Yes, backdated 16-bit software that I write for the 8086.

I want it to fly on CM16.

> This would be about the only benefit.
> Any other I'm missing?

Nope. That's it. I want any 16-bit programs I write for
MSDOS (or at least 16-bit PDOS-generic) to run in
long mode CM16 under 64-bit PDOS-whatever, when
it eventually exists, and potentially under Windows
sooner than that.

> Emulating the i80486 instruction set (more than sufficient HW for DOS SW)
> is a problem that is bound and has been solved many times. You can just
> do it without hacking Windows. Plenty of CPU cycles, RAM bytes and disk
> sectors to go around for this nowadays.

I don't want to rely on the hardware compensating
for poor software implementation.

> > > > Ideally I would not even know that I am running a 16-bit
> > > > executable (as was the case with 32-bit Windows
> > > > command prompt).
> > > >
> > > > But if Microsoft is unwilling to provide 16-bit support I
> > > > am willing to design 16-bit applications that will work
> > > > under a theoretical PDOS/x64, but while waiting for
> > > > that, I could instead use a kernel mode 32-bit app to
> > > > switch to CM16 (or perhaps set the D-bits while staying
> > > > in CM32), run my 16-bit app (which does no interrupts,
> > > > since it is PDOS-generic), returns to CM32 and switches
> > > > the D-bits back without Windows even being aware
> > > > what happened.
> >
> > > Microsoft doesn't want your code running freely in kernel mode.
> > >
> > > And that's another blow to your dreams.
> > They don't stop me installing privileged programs currently,
> > I believe.
> You may be able to install unsigned drivers, but it's not kosher
> outside of development of software for Windows.

I'm not trying to win Miss America, I'm trying to write
16-bit applications that work on the 8086 and CM16.

If Bill Gates has a heart attack I don't care.

> And if not already, there may be limitations associated with it
> (other than the warning messages).

Ok.

> > > > I do something similar with MVS/380. The OS is unaware
> > > > that the app switched to AM31 and back again.
> > > > > If I understand it correctly (it's been years since I did anything in/with Hyper-V), you'll need to
> > > > > implement all the necessary x86 devices yourself (PIC, PIT, DMA, VGA, serial port,
> > > > > keyboard, mouse, FDC, HDC, SB, etc etc) and throw in a BIOS of some kind.
> > > > I want to avoid all that. I want to switch back to 32-bit
> > > > mode to service the 16-bit API call.
> > > >
> > > > If Microsoft has an official API I would be happy to call
> > > > a 16-bit interrupt or DLL in that case.
> >
> > > There just isn't. Get over it. Run DOSBox or a VM.
> > > Or stick to old Windows on old PCs while you still can (if you can).
> > None of those things exercise CM16, which is what I am
> > interested in.

> Using Hyper-V you get a way to run your 16-bit SW (real mode or
> protected) as close to native as possible without crippling or hacking
> Windows.

I don't want to rely on the existence of such a feature.

BFN. Paul.

[JJ]

On Sat, 19 Nov 2022 08:49:48 -0800 (PST), muta...@gmail.com wrote:
>
> Also, I assume it was physically possible to create an executable
> that did a WriteFile to something resembling stdout. But due to
> the absence of a console the output just disappeared.

16-bit Windows doesn't have standard output/input handles. It only has
pipes. DOS devices such as `con` and `aux` are named pipes. They're not
recognized as standard output/input. 16-bit Windows doesn't have any
`GetStdHandle()` function or constants such as `STD_OUTPUT_HANDLE`.

> But if I replace 16-bit Windows with my own 16-bit Windows (that is
> console mode only), would that executable suddenly start working?
>
> Or is there something missing from the executable technically?

16-bit Windows NE module does not support a Console flag for the program
type. 16-bit Windows programs can not have their own console(s), by design.
Only DOS programs do. Period.

> I assume any WriteFile to actual files works fine, even if I only
> provide a console.

Yes, but that console would have to be provided by a separate DOS program.
If you're developing you own OS, then you can do whatever you want.

[muta...@gmail.com]

On Sunday, November 20, 2022 at 9:52:20 PM UTC+8, JJ wrote:
> On Sat, 19 Nov 2022 08:49:48 -0800 (PST), muta...@gmail.com wrote:
> >
> > Also, I assume it was physically possible to create an executable
> > that did a WriteFile to something resembling stdout. But due to
> > the absence of a console the output just disappeared.

> 16-bit Windows doesn't have standard output/input handles. It only has
> pipes. DOS devices such as `con` and `aux` are named pipes. They're not
> recognized as standard output/input. 16-bit Windows doesn't have any
> `GetStdHandle()` function or constants such as `STD_OUTPUT_HANDLE`.

Named pipes may be good enough.

> > But if I replace 16-bit Windows with my own 16-bit Windows (that is
> > console mode only), would that executable suddenly start working?
> >
> > Or is there something missing from the executable technically?

> 16-bit Windows NE module does not support a Console flag for the program
> type. 16-bit Windows programs can not have their own console(s), by design.
> Only DOS programs do. Period.

Are you saying there aren't enough bits to assign one
in the executable header, or that Microsoft simply
didn't assign one?

If the latter, I would be happy to assign one myself to
say "console".

I would also be happy to simply ignore the flags and
assume console.

> > I assume any WriteFile to actual files works fine, even if I only
> > provide a console.

> Yes, but that console would have to be provided by a separate DOS program.
> If you're developing you own OS, then you can do whatever you want.

I am indeed developing my own OS, so I will do whatever
I want.

However, I would like to produce a 16-bit Windows
executable. I've never actually done that before, but
it seems that Open Watcom 1.6 supports that as a
target.

But I still need to make modifications to PDPCLIB,
in the absence of GetStdHandle().

It sounds like I would need to write to a pipe called "con".

But instead of having a DOS application waiting on the
other end of the "con" pipe, that is something that
PDOS/86 provides as standard (and in fact, only).

Is that feasible?

If so, I may soon be in Win16 executable business.

And later I may wish to run that in CM16. But I'll
start with RM16.

Unless I'm missing something?

Thanks. Paul.

[JJ]

On Sun, 20 Nov 2022 13:02:01 -0800 (PST), muta...@gmail.com wrote:
>
> Are you saying there aren't enough bits to assign one
> in the executable header, or that Microsoft simply
> didn't assign one?

There is none. There's nothing in 16-bit Windows NE module which is similar
to PE module's subsystem field which define a console. Microsoft doesn't
define any for 16-bit Windows NE module. 16-bit Windows NE module is always
a GUI program.

> If the latter, I would be happy to assign one myself to
> say "console".

You can add one for your own OS as long as there still an unused module type
number or flag.

> But instead of having a DOS application waiting on the
> other end of the "con" pipe, that is something that
> PDOS/86 provides as standard (and in fact, only).
>
> Is that feasible?

Yes, the CON pipe would be precreated for each application process created.
And if the module is of your console type, the system would automatically
create the console window and connect it to the CON pipe for the
application.

> And later I may wish to run that in CM16. But I'll
> start with RM16.
>
> Unless I'm missing something?

Real mode is not possible in CM16, since V86 is absent in CM16. CM16 is pure
protected mode. The closest thing is Unreal Mode.

[muta...@gmail.com]

On Monday, November 21, 2022 at 9:16:29 AM UTC+8, JJ wrote:

> There is none. There's nothing in 16-bit Windows NE module which is similar
> to PE module's subsystem field which define a console. Microsoft doesn't
> define any for 16-bit Windows NE module. 16-bit Windows NE module is always
> a GUI program.

I think if that's their attitude, my attitude will just be
that a 16-bit Windows NE module is always a
console mode program when run on PDOS/86
(or some 16-bit variant).

> > But instead of having a DOS application waiting on the
> > other end of the "con" pipe, that is something that
> > PDOS/86 provides as standard (and in fact, only).
> >
> > Is that feasible?

> Yes, the CON pipe would be precreated for each application process created.
> And if the module is of your console type, the system would automatically
> create the console window and connect it to the CON pipe for the
> application.

Ok, cool. So what does my Windows NE module need
to do to write to that pre-allocated CON pipe to
display a "hello world"?

Is it still a call to WriteFile?

> > And later I may wish to run that in CM16. But I'll
> > start with RM16.
> >
> > Unless I'm missing something?

> Real mode is not possible in CM16, since V86 is absent in CM16. CM16 is pure
> protected mode. The closest thing is Unreal Mode.

I don't need real mode in order to run a 16-bit Windows NE
module writing to a CON pipe, do I?

I can create a 16/32/64-bit pseudo-OS that exists between
64-bit Windows and the 16-bit Windows NE application.

Or 64-bit Windows is replaced by 64-bit PDOS if that's
the only realistic way to get CM16 exercised.

BFN. Paul.

[JJ]

On Sun, 20 Nov 2022 18:14:35 -0800 (PST), muta...@gmail.com wrote:
>
> Ok, cool. So what does my Windows NE module need
> to do to write to that pre-allocated CON pipe to
> display a "hello world"?
>
> Is it still a call to WriteFile?

Implement the concept of standard input, output, and error handles. Add more
if needed. IIRC, *nix has more than 3 standard handles.

>>> And later I may wish to run that in CM16. But I'll
>>> start with RM16.
>>>
>>> Unless I'm missing something?
>
>> Real mode is not possible in CM16, since V86 is absent in CM16. CM16 is pure
>> protected mode. The closest thing is Unreal Mode.
>
> I don't need real mode in order to run a 16-bit Windows NE
> module writing to a CON pipe, do I?

Pipe is an application level implementation. It's not related to CPU
execution mode.

> Or 64-bit Windows is replaced by 64-bit PDOS if that's
> the only realistic way to get CM16 exercised.

It's best to have the main OS kernel in the execution mode where it has
access to all memory address space. Otherwise it would take more effort to
access all of them. Or worse, be limited.

[muta...@gmail.com]

On Monday, November 21, 2022 at 7:53:09 PM UTC+8, JJ wrote:

> > Ok, cool. So what does my Windows NE module need
> > to do to write to that pre-allocated CON pipe to
> > display a "hello world"?
> >
> > Is it still a call to WriteFile?

> Implement the concept of standard input, output, and error handles. Add more
> if needed. IIRC, *nix has more than 3 standard handles.

Sorry, I don't understand.

First, I'm only interested in C90, so there's only the 3 handles
to be concerned with, and the concept already exists.

What I want to do is make use of existing practice to give
applications somewhere to write to.

It is my C library, PDPCLIB, that will do the actual writing.
Actual C90 applications will not be aware that a named
pipe is involved. There is no need to provide applications
with a GetStdHandle API or any such thing. It's all hidden
in the C library.

Existing practice is a "con" pipe that ends up on a DOS
window. That's an interesting setup.

But I only need to know the interface that the Windows
NE executable sees in such an arrangement.

I will be marrying the fairly-standard 16-bit Windows NE
executable up to something completely different.

Let's start with PDOS/PM16.

When operating in this "con pipe" mode, what does the
NE executable see/do? Does it call a DLL? What's the
name of the DLL?

PDOS/PM16 will provide an artificial DLL to satisfy that.

But what is the actual DLL call? Is it OpenFile("pipe:con")
or an INT 21H or what?

> It's best to have the main OS kernel in the execution mode where it has
> access to all memory address space. Otherwise it would take more effort to
> access all of them. Or worse, be limited.

Sure. Let me start with PM16 and I'll see if CM16 is
useful another day. At least I'll actually have something
to be backward-compatible with when I get there!

Thanks. Paul.

[JJ]

On Mon, 21 Nov 2022 05:01:53 -0800 (PST), muta...@gmail.com wrote:
>
> When operating in this "con pipe" mode, what does the
> NE executable see/do? Does it call a DLL? What's the
> name of the DLL?

One one knows, since it's your own OS. You make your own.

[muta...@gmail.com]

Sorry, I'm confused.

Even though PDOS/386 is my own OS, I don't have any
choice but to call the DLLs kernel32.dll and msvcrt.dll,
as it is embedded in the executable.

I need to at least translate those specific names if I want
to rename the physical DLL for some reason.

What is the 16-bit equivalent?

Apparently there was a somewhat common technique to
write to a console in the Win16 days, which was opening
a con pipe and writing to it.

I'd like the details of that technique.

I tried doing a search for win16 con pipe but didn't find
a reference.

Thanks. Paul.

[JJ]

On Mon, 21 Nov 2022 14:22:35 -0800 (PST), muta...@gmail.com wrote:
>
> Even though PDOS/386 is my own OS, I don't have any
> choice but to call the DLLs kernel32.dll and msvcrt.dll,
> as it is embedded in the executable.
>
> I need to at least translate those specific names if I want
> to rename the physical DLL for some reason.
>
> What is the 16-bit equivalent?

There is none. In 16-bit Windows platform, all console related features are
handled by the kernel via Interrupt services. CON is only usable when
there's a console window open.

> Apparently there was a somewhat common technique to
> write to a console in the Win16 days, which was opening
> a con pipe and writing to it.

It's DOS days, to be precise. CON in Windows is same as DOS' CON.

> I tried doing a search for win16 con pipe but didn't find
> a reference.

CON is a character device, but it works like a pipe and can be implemented
as a pipe.

[muta...@gmail.com]

On Tuesday, November 22, 2022 at 5:36:12 PM UTC+8, JJ wrote:

> > I need to at least translate those specific names if I want
> > to rename the physical DLL for some reason.
> >
> > What is the 16-bit equivalent?

> There is none.

Ok, that's an eye opener.

> In 16-bit Windows platform, all console related features are
> handled by the kernel via Interrupt services. CON is only usable when
> there's a console window open.

> > Apparently there was a somewhat common technique to
> > write to a console in the Win16 days, which was opening
> > a con pipe and writing to it.

> It's DOS days, to be precise. CON in Windows is same as DOS' CON.

> > I tried doing a search for win16 con pipe but didn't find
> > a reference.

> CON is a character device, but it works like a pipe and can be implemented
> as a pipe.

My interpretation of the above is that a Win 16 NE executable
can call INT 21H and write to handle 1 and the output will
appear so long as there's a console window open.

I'm not sure what a console window is - I believe 16-bit Windows
allowed multiple DOS prompts.

If I write via INT 21H as above, from a Windows NE executable,
did it start writing to a random MSDOS window?

Or perhaps whichever one was in focus? So you needed to
start the Windows NE executable and then quickly switch
to the DOS prompt? Or did you simply start the Windows NE
executable from the DOS prompt and it stayed with that?

That's simple enough. I didn't know you could do that.

And these Windows NE executables - they presumably were
able to use more than 640k of memory on an 80286, because
they ran in PM16 even though they called INT 21H?

If so, that's fantastic. That's exactly what I'm after.

Thanks. Paul.

[JJ]

On Tue, 22 Nov 2022 05:46:35 -0800 (PST), muta...@gmail.com wrote:
>
> If I write via INT 21H as above, from a Windows NE executable,
> did it start writing to a random MSDOS window?

No. It'll either be ignored, or rejected. I can't recall which one exactly.

> Or perhaps whichever one was in focus? So you needed to
> start the Windows NE executable and then quickly switch
> to the DOS prompt? Or did you simply start the Windows NE
> executable from the DOS prompt and it stayed with that?

Have you tried it yourself?

[muta...@gmail.com]

On Wednesday, November 23, 2022 at 2:52:14 AM UTC+8, JJ wrote:
> On Tue, 22 Nov 2022 05:46:35 -0800 (PST), muta...@gmail.com wrote:
> >
> > If I write via INT 21H as above, from a Windows NE executable,
> > did it start writing to a random MSDOS window?

> No. It'll either be ignored, or rejected. I can't recall which one exactly.

So how do you make it work then? You said it was
possible to write to CON so long as a DOS window
was available.

> > Or perhaps whichever one was in focus? So you needed to
> > start the Windows NE executable and then quickly switch
> > to the DOS prompt? Or did you simply start the Windows NE
> > executable from the DOS prompt and it stayed with that?

> Have you tried it yourself?

No, I don't have Win16, and never did. I moved from MSDOS
to OS/2 2.0 and then Win 95.

I only ever wrote C90 programs, and they became 32-bit
with the move to OS/2. I think under Win 95 I used Cygwin
to get 32-bit. Oh, I also used Borland C which was 32-bit.
And Watcom too I think.

But I can try seeing if I can produce a Win16 executable
using Watcom and then inspect the code to see if it is
something I could support on PDOS/86.

But I still need to understand that it is technically possible
to maintain compatibility with real Win16 writing to some
sort of console via some sort of technique.

If you don't know any more details, I'll try asking in a
Windows forum.

Thanks. Paul.

[muta...@gmail.com]

I just tried:

C:\scratch\aaa>wcl -bcl=windows world.c

and got a 32k executable:

000000 4D5A8000 01000000 04000000 FFFF0000 MZ..............
000010 B8000000 00000000 40000000 00000000 ........@.......
000020 00000000 00000000 00000000 00000000 ................
000030 00000000 00000000 00000000 80000000 ................
000040 0E1FBA0E 00B409CD 21B8014C CD215468 ........!..L.!Th
000050 69732069 73206120 57696E64 6F777320 is is a Windows
000060 31362D62 69742065 78656375 7461626C 16-bit executabl
000070 650D0A24 00000000 00000000 00000000 e..$............
000080 4E450501 8F000200 00000000 02020200 NE..............
000090 00040020 7E000100 00000200 02000600 ... ~...........
0000A0 0D004000 50005000 59006500 11010000 ..@.P.P.Y.e.....
0000B0 00000100 00000200 00000000 00000003 ................
0000C0 8F00CC6E 400DCC6E DA3A0408 410D8009 ...n@..n.:..A...
0000D0 05776F72 6C640000 00010008 000D0011 .world..........
0000E0 001A0022 0000064B 45524E45 4C045553 ..."...KERNEL.US
0000F0 45520347 4449084B 4559424F 41524407 ER.GDI.KEYBOARD.
000100 434F4D4D 444C4707 57494E38 37454D00 COMMDLG.WIN87EM.
000110 0009776F 726C642E 65786500 0000CCEB ..world.exe.....
000120 FD909090 90000000 00000000 0000B804 ................
000130 00E81300 B8100050 E8400083 C40231C0 .......P.@....1.


I can't run it though on 64-bit Windows.

That KERNEL/USER/GDI look like DLL names to me.

BFN. Paul.

[Alexei A. Frounze]

On Tuesday, November 22, 2022 at 4:18:37 PM UTC-8, muta...@gmail.com wrote:
...

> But I still need to understand that it is technically possible
> to maintain compatibility with real Win16 writing to some
> sort of console via some sort of technique.

I vaguely recall that an old compiler (likely Borland/Turbo Pascal for Windows)
produced "console" programs that actually were GUI ones, just rendered the
text in a regular window.

Alex

[muta...@gmail.com]

On Wednesday, November 23, 2022 at 10:46:44 AM UTC+8, Alexei A. Frounze wrote:

> > But I still need to understand that it is technically possible
> > to maintain compatibility with real Win16 writing to some
> > sort of console via some sort of technique.

> I vaguely recall that an old compiler (likely Borland/Turbo Pascal for Windows)
> produced "console" programs that actually were GUI ones, just rendered the
> text in a regular window.

Ok, that would be another option. Provide calls so that
the executable thinks it is opening a graphics window,
but I only support one graphics window size, and it is
only capable of displaying 80 * 25 characters.

Crikey, it sounds like this knowledge is on the verge of
being lost.

Hopefully I can codify something so that there is some
sort of historical record of what the machines were
capable of.

I assume there was an API call to display text on a
graphics window.

But there's still the pipe option which sounds like a
simpler interface if I can find someone who still
remembers how it was done.

BFN. Paul.

[Alexei A. Frounze]

On Tuesday, November 22, 2022 at 9:57:07 PM UTC-8, muta...@gmail.com wrote:
...

> I assume there was an API call to display text on a
> graphics window.

It's the GDI, AFAIR.

There's no shell, no select/copy/paste... You need to emulate
everything if you want to preserve the familiar experience.

Alex

[muta...@gmail.com]

On Wednesday, November 23, 2022 at 3:08:58 PM UTC+8, Alexei A. Frounze wrote:

> > I assume there was an API call to display text on a
> > graphics window.

> It's the GDI, AFAIR.
>
> There's no shell, no select/copy/paste... You need to emulate
> everything if you want to preserve the familiar experience.

The familiar experience I want is MSDOS.

No mouse. No text selection.

I don't need to emulate anything, I just need to get the text
from A to B, and keyboard input from C to D.

Converting PDOS/86 from an MSDOS 2.0 equivalent to
64-bit Windows with 50 billion lines of code is a project
I will leave to future generations. I'll be happy to reach
MSDOS 2.0. With certain changes such as being
written in C, and needing a Turbo 186 or 80286 for practical
use etc. And because it is mostly written in C, a simple
recompile will make it fully 32-bit flat.

BFN. Paul.

[Alexei A. Frounze]

On Tuesday, November 22, 2022 at 11:25:33 PM UTC-8, muta...@gmail.com wrote:
> On Wednesday, November 23, 2022 at 3:08:58 PM UTC+8, Alexei A. Frounze wrote:
>
> > > I assume there was an API call to display text on a
> > > graphics window.
>
> > It's the GDI, AFAIR.
> >
> > There's no shell, no select/copy/paste... You need to emulate
> > everything if you want to preserve the familiar experience.
> The familiar experience I want is MSDOS.
>
> No mouse. No text selection.

Oh, I forget. To much UNIXy experience lately. :)

Alex