I am interested in 32-bit windows console mode
applications that are dependent on msvcrt.dll.

Basically simple C programs. I am using this as
an example:

2021-10-18 18:54 3,584 hexdump.exe

This ships with PDOS/386.

I know that it works with win95 so long as msvcrt.dll
is installed (it is on the win95 CDROM but is not installed
by default, but if you copy it across manually, it works
fine).

Now I want to know whether I can go back even further
and have it run on windows for workgroups 3.11 with
win32s installed.

I received wfw from ebay yesterday, and downloaded
pw1118.exe from a microsoft mirror and was able to
install win32s and run the demo program freecell.
This was done under qemu. The floppy disks I read
with a USB floppy disk and running pdos/386 and
the "copy" command to read drv0:

Running hexdump at an MSDOS prompt either before
running windows or after clicking on the msdos icon
reported that I needed to run windows (hexdump has
a custom message I created).

Using file manager and clicking on hexdump came up
with a nice error about msvcrt.dll not being found. I
produce my own as part of pdpclib so I copied that
across. Now clicking on hexdump doesn't do anything
that can be visibly seen.

No error about kernel32.dll not being found either, even
though it is a dependency yet doesn't appear on the
disk (must be recognized elsewhere).

Any suggestions on what I can do to see something
from hexdump? It is supposed to produce this:

C:\winpath>hexdump
Usage: HEXDUMP file_name [start] [length]

I suspect it is starting and finishing quickly, so what I
need is to run a shell. Rather than try to organize that,
I just added an fgets from stdin to see if it would stay
active so that I could see it.

However - still no. Still the same effect of clicking in
file manager just has a delay suggesting it is doing
some work, but it behaves as if nothing happened.

Any idea whether I can obtain output from this:

__stdout->hfile = GetStdHandle(STD_OUTPUT_HANDLE);

#define STD_OUTPUT_HANDLE ((DWORD)-11)

GetStdHandle must exist, otherwise msvcrt.dll
would have failed to load (presumably, anyway).

But it apparently has nowhere to go.

I'm happy with any solution that doesn't alter hexdump.exe
itself. ie the physical executable on disk.

Thanks. Paul.

On Sat, 24 Jun 2023 07:52:05 -0700 (PDT), muta...@gmail.com wrote:
> I am interested in 32-bit windows console mode
> applications that are dependent on msvcrt.dll.
>
> Basically simple C programs. I am using this as
> an example:
>
> 2021-10-18 18:54 3,584 hexdump.exe
>
> This ships with PDOS/386.
>
> I know that it works with win95 so long as msvcrt.dll
> is installed (it is on the win95 CDROM but is not installed
> by default, but if you copy it across manually, it works
> fine).
>
> Now I want to know whether I can go back even further
> and have it run on windows for workgroups 3.11 with
> win32s installed.
>
> I received wfw from ebay yesterday, and downloaded
> pw1118.exe from a microsoft mirror and was able to
> install win32s and run the demo program freecell.
> This was done under qemu. The floppy disks I read
> with a USB floppy disk and running pdos/386 and
> the "copy" command to read drv0:
>
> Running hexdump at an MSDOS prompt either before
> running windows or after clicking on the msdos icon
> reported that I needed to run windows (hexdump has
> a custom message I created).
>
> Using file manager and clicking on hexdump came up
> with a nice error about msvcrt.dll not being found. I
> produce my own as part of pdpclib so I copied that
> across. Now clicking on hexdump doesn't do anything
> that can be visibly seen.
>
> No error about kernel32.dll not being found either, even
> though it is a dependency yet doesn't appear on the
> disk (must be recognized elsewhere).
>
> Any suggestions on what I can do to see something
> from hexdump? It is supposed to produce this:
>
> C:\winpath>hexdump
> Usage: HEXDUMP file_name [start] [length]
>
> I suspect it is starting and finishing quickly, so what I
> need is to run a shell. Rather than try to organize that,
> I just added an fgets from stdin to see if it would stay
> active so that I could see it.
>
> However - still no. Still the same effect of clicking in
> file manager just has a delay suggesting it is doing
> some work, but it behaves as if nothing happened.
>
> Any idea whether I can obtain output from this:
>
> __stdout->hfile = GetStdHandle(STD_OUTPUT_HANDLE);
>
> #define STD_OUTPUT_HANDLE ((DWORD)-11)
>
> GetStdHandle must exist, otherwise msvcrt.dll
> would have failed to load (presumably, anyway).
>
> But it apparently has nowhere to go.
>
> I'm happy with any solution that doesn't alter hexdump.exe
> itself. ie the physical executable on disk.
>
> Thanks. Paul.

Console API is not implemented in Win32s, but you may be able to hook its
functions and thunk them to Win16 land to call DOS services for console
functions.

On Sunday, June 25, 2023 at 8:13:33 PM UTC+8, JJ wrote:

> Console API is not implemented in Win32s, but you may be able to hook its
> functions and thunk them to Win16 land to call DOS services for console
> functions.

Ok, thanks for that possible solution.

I've just thought of one myself.

I don't mind having a custom version of msvcrt.dll for Win32s.

As such, how about I get msvcrt.dll to open a graphics window?

I'd like to stay in 32-bit in my code.

At some point it would be good to have a shell implemented
the exact same way, so that it can launch other 32-bit programs
that are dependent on msvcrt.dll.

And this would be a good place to implement ANSI screen
controls, which aren't available in even modern msvcrt.dll
I believe.

And if I do it this way, it should work on everything from win32s
to windows 11, right?

How do I get started with an 80 * 25 fullscreen window? Preferably
with fonts just as good as MSDOS so that nothing is lost and you
simply get a 32-bit version of MSDOS as far as the user can see.

Thanks. Paul.

On Sunday, June 25, 2023 at 11:10:02 PM UTC+8, muta...@gmail.com wrote:

> How do I get started with an 80 * 25 fullscreen window? Preferably
> with fonts just as good as MSDOS so that nothing is lost and you
> simply get a 32-bit version of MSDOS as far as the user can see.

Actually, what I want is the best possible fonts that modern
screens can handle.

Hopefully that will make it easier for me to read the screen.

My eyesight is getting bad (I'm 55) but I refuse to wear glasses.

BFN. Paul.

On Sun, 25 Jun 2023 08:10:00 -0700 (PDT), muta...@gmail.com wrote:
>
> How do I get started with an 80 * 25 fullscreen window? Preferably
> with fonts just as good as MSDOS so that nothing is lost and you
> simply get a 32-bit version of MSDOS as far as the user can see.
>
> Thanks. Paul.

You just need to save the current state of the graphic video mode which
includes screen resolution, color depth, video buffer, palettes, hardware
cursor, etc. (i.e. everything) before switching to text video mode (i.e.
fullscreen console). Restore the state of the graphics video mode when
switching back to graphic video mode (i.e. non fullscreen console). It
should also save the state of text video mode which includes cursor
position, cursor size, font, etc. (i.e. everything), if the console
application is not closed - in case it needs to switch back to text video
mode again.

On Sun, 25 Jun 2023 08:29:48 -0700 (PDT), muta...@gmail.com wrote:
>
> Actually, what I want is the best possible fonts that modern
> screens can handle.
>
> Hopefully that will make it easier for me to read the screen.
>
> My eyesight is getting bad (I'm 55) but I refuse to wear glasses.
>
> BFN. Paul.

If you're not satisfied with the font provided by the motherboard BIOS,
simply provide your own font. There's a lot of free "DOS" fonts in Walnut
Creek (check archive.org).

On Monday, June 26, 2023 at 9:25:45 PM UTC+8, JJ wrote:

> You just need to save the current state of the graphic video mode which
> includes screen resolution, color depth, video buffer, palettes, hardware
> cursor, etc. (i.e. everything) before switching to text video mode (i.e.
> fullscreen console). Restore the state of the graphics video mode when
> switching back to graphic video mode (i.e. non fullscreen console). It
> should also save the state of text video mode which includes cursor
> position, cursor size, font, etc. (i.e. everything), if the console
> application is not closed - in case it needs to switch back to text video
> mode again.

For what reason do I need to switch to text mode?

I can remember when using OS/2 2.0 that when I
switched to a command prompt the monitor
actually made a noise.

> If you're not satisfied with the font provided by the motherboard BIOS,
> simply provide your own font. There's a lot of free "DOS" fonts in Walnut
> Creek (check archive.org).

The motherboard fonts are very small, aren't they? Like 8 * 14.

Aren't there standard Windows fonts that make maximum
use of the graphic capabilities of the card/monitor? Modern
systems have something like 4000 pixels, right? So that would
be 4000/80 = 50 instead of 8 which is presumably much
crisper/clearer.

BFN. Paul.

On Tue, 27 Jun 2023 14:53:25 -0700 (PDT), muta...@gmail.com wrote:
> On Monday, June 26, 2023 at 9:25:45 PM UTC+8, JJ wrote:
>
>> You just need to save the current state of the graphic video mode which
>> includes screen resolution, color depth, video buffer, palettes, hardware
>> cursor, etc. (i.e. everything) before switching to text video mode (i.e.
>> fullscreen console). Restore the state of the graphics video mode when
>> switching back to graphic video mode (i.e. non fullscreen console). It
>> should also save the state of text video mode which includes cursor
>> position, cursor size, font, etc. (i.e. everything), if the console
>> application is not closed - in case it needs to switch back to text video
>> mode again.
>
> For what reason do I need to switch to text mode?
>
> I can remember when using OS/2 2.0 that when I
> switched to a command prompt the monitor
> actually made a noise.
>
>> If you're not satisfied with the font provided by the motherboard BIOS,
>> simply provide your own font. There's a lot of free "DOS" fonts in Walnut
>> Creek (check archive.org).
>
> The motherboard fonts are very small, aren't they? Like 8 * 14.
>
> Aren't there standard Windows fonts that make maximum
> use of the graphic capabilities of the card/monitor? Modern
> systems have something like 4000 pixels, right? So that would
> be 4000/80 = 50 instead of 8 which is presumably much
> crisper/clearer.
>
> BFN. Paul.

In that case, it'd be just a matter of choosing and configuring the console
font. There's no programming related issue.