info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
win32 via odin
65 views
Skip to first unread message
Paul Edwards
Jul 13, 2023, 4:46:10 PM7/13/23
to
Hi folks.
I started using OS/2 2.0 when it was still in beta, but I
stopped using it in 1999 I think.
Since then I have developed my own OS, PDOS/386
(http://pdos.org), which runs a subset of win32
console mode applications.
An obscure sequence of events led to me purchasing
ArcaOS to see what a commercially supported rival
to Windows looked like, when I saw that it now ran
(some) win32 programs, via the pre-installed Odin.
I can't find any evidence that Odin is still being developed,
although it hasn't been that long (6 years) since the last
release.
My win32 programs (e.g. hexdump), that are dependent
on msvcrt.dll, did indeed work (when prefixed by "pec").
Note that I provide my own msvcrt.dll (that I wrote
myself - part of PDPCLIB) - ArcaOS doesn't ship with one.
However, programs of mine that use ANSI escape codes
do not work properly - the ESC appears to be ignored/
swallowed.
In addition, the doco says that the driver is no longer
working, so I need to run everything via pec. Which
probably means I need to provide my own shell.
Which I can probably do, as I have 3 flavors of my
shell already (for 3 different flavors of PDOS).
But that won't really work without ANSI escapes.
Well - I believe it will work to some extent.
Another thing I haven't figured out yet is how to get
LFN working on my FAT partition. There is supposedly
a "longname" extended attribute to allow this.
Any thoughts on how to create a win32 console
environment?
Thanks. Paul.
I started using OS/2 2.0 when it was still in beta, but I
stopped using it in 1999 I think.
Since then I have developed my own OS, PDOS/386
(http://pdos.org), which runs a subset of win32
console mode applications.
An obscure sequence of events led to me purchasing
ArcaOS to see what a commercially supported rival
to Windows looked like, when I saw that it now ran
(some) win32 programs, via the pre-installed Odin.
I can't find any evidence that Odin is still being developed,
although it hasn't been that long (6 years) since the last
release.
My win32 programs (e.g. hexdump), that are dependent
on msvcrt.dll, did indeed work (when prefixed by "pec").
Note that I provide my own msvcrt.dll (that I wrote
myself - part of PDPCLIB) - ArcaOS doesn't ship with one.
However, programs of mine that use ANSI escape codes
do not work properly - the ESC appears to be ignored/
swallowed.
In addition, the doco says that the driver is no longer
working, so I need to run everything via pec. Which
probably means I need to provide my own shell.
Which I can probably do, as I have 3 flavors of my
shell already (for 3 different flavors of PDOS).
But that won't really work without ANSI escapes.
Well - I believe it will work to some extent.
Another thing I haven't figured out yet is how to get
LFN working on my FAT partition. There is supposedly
a "longname" extended attribute to allow this.
Any thoughts on how to create a win32 console
environment?
Thanks. Paul.
Dave Yeo
Jul 13, 2023, 11:30:42 PM7/13/23
to
Hi Paul, note I'm not the most knowledgeable user, not many of us
monitoring usenet now though hopefully others can chime in. There are a
couple of mailing lists and the OS2world forum as well where you might
get help.
Paul Edwards wrote:
> Hi folks.
>
> I started using OS/2 2.0 when it was still in beta, but I
> stopped using it in 1999 I think.
>
> Since then I have developed my own OS, PDOS/386
> (http://pdos.org), which runs a subset of win32
> console mode applications.
>
> An obscure sequence of events led to me purchasing
> ArcaOS to see what a commercially supported rival
> to Windows looked like, when I saw that it now ran
> (some) win32 programs, via the pre-installed Odin.
>
> I can't find any evidence that Odin is still being developed,
> although it hasn't been that long (6 years) since the last
> release.
As far as I know, it is not being developed anymore. It can be forked
and development continued. The last development was by Bitwise, things
like building OpenJDK, a Flash wrapper and running Flash and earlier by
Innotek, running Adobe Acrobat.
Note that it is quite possible to use Odin to build native OS/2 Win32
applications such as was done with OpenJDK, x:\Programs\OpenJDK on your
ArcaOS install or for source, https://trac.netlabs.org/java.
Development is usually done with GCC but OpenWatcom should work as well
with the right calling conventions.
>
> My win32 programs (e.g. hexdump), that are dependent
> on msvcrt.dll, did indeed work (when prefixed by "pec").
>
> Note that I provide my own msvcrt.dll (that I wrote
> myself - part of PDPCLIB) - ArcaOS doesn't ship with one.
Something that could be added to Odin (msvcrt.dll that is) :)
>
> However, programs of mine that use ANSI escape codes
> do not work properly - the ESC appears to be ignored/
> swallowed.
Not sure about that one, perhaps someone else has some insight.
>
> In addition, the doco says that the driver is no longer
> working, so I need to run everything via pec. Which
> probably means I need to provide my own shell.
> Which I can probably do, as I have 3 flavors of my
> shell already (for 3 different flavors of PDOS).
Wonder if it is possible to run PDOS in a DOS session?
>
> But that won't really work without ANSI escapes.
> Well - I believe it will work to some extent.
>
> Another thing I haven't figured out yet is how to get
> LFN working on my FAT partition. There is supposedly
> a "longname" extended attribute to allow this.
The longname extended attribute is only used by the WPS and there can be
problems with file systems that are not FAT, namely when the longname
and actual filename get out of sync.
Generally the FAT support is in the kernel but there are IFS's that
support vfat such as the FAT32.IFS, https://trac.netlabs.org/fat32 this
is related to the FAT32.IFS that ships with ArcaOS but Arca Noae didn't
like the chances of patent problems with the exfat support so forked it.
>
> Any thoughts on how to create a win32 console
> environment?
There has been various shells written/ported to OS/2, there are the
limits of a VIO window if you go that route. The only source of one I
can think of is https://github.com/komh/kshell which might give some ideas.
Also could use a regular Presentation Manager window to display your shell
Dave
monitoring usenet now though hopefully others can chime in. There are a
couple of mailing lists and the OS2world forum as well where you might
get help.
Paul Edwards wrote:
> Hi folks.
>
> I started using OS/2 2.0 when it was still in beta, but I
> stopped using it in 1999 I think.
>
> Since then I have developed my own OS, PDOS/386
> (http://pdos.org), which runs a subset of win32
> console mode applications.
>
> An obscure sequence of events led to me purchasing
> ArcaOS to see what a commercially supported rival
> to Windows looked like, when I saw that it now ran
> (some) win32 programs, via the pre-installed Odin.
>
> I can't find any evidence that Odin is still being developed,
> although it hasn't been that long (6 years) since the last
> release.
and development continued. The last development was by Bitwise, things
like building OpenJDK, a Flash wrapper and running Flash and earlier by
Innotek, running Adobe Acrobat.
Note that it is quite possible to use Odin to build native OS/2 Win32
applications such as was done with OpenJDK, x:\Programs\OpenJDK on your
ArcaOS install or for source, https://trac.netlabs.org/java.
Development is usually done with GCC but OpenWatcom should work as well
with the right calling conventions.
>
> My win32 programs (e.g. hexdump), that are dependent
> on msvcrt.dll, did indeed work (when prefixed by "pec").
>
> Note that I provide my own msvcrt.dll (that I wrote
> myself - part of PDPCLIB) - ArcaOS doesn't ship with one.
>
> However, programs of mine that use ANSI escape codes
> do not work properly - the ESC appears to be ignored/
> swallowed.
>
> In addition, the doco says that the driver is no longer
> working, so I need to run everything via pec. Which
> probably means I need to provide my own shell.
> Which I can probably do, as I have 3 flavors of my
> shell already (for 3 different flavors of PDOS).
>
> But that won't really work without ANSI escapes.
> Well - I believe it will work to some extent.
>
> Another thing I haven't figured out yet is how to get
> LFN working on my FAT partition. There is supposedly
> a "longname" extended attribute to allow this.
problems with file systems that are not FAT, namely when the longname
and actual filename get out of sync.
Generally the FAT support is in the kernel but there are IFS's that
support vfat such as the FAT32.IFS, https://trac.netlabs.org/fat32 this
is related to the FAT32.IFS that ships with ArcaOS but Arca Noae didn't
like the chances of patent problems with the exfat support so forked it.
>
> Any thoughts on how to create a win32 console
> environment?
limits of a VIO window if you go that route. The only source of one I
can think of is https://github.com/komh/kshell which might give some ideas.
Also could use a regular Presentation Manager window to display your shell
Dave
Paul Edwards
Jul 15, 2023, 1:02:14 AM7/15/23
to
On Friday, July 14, 2023 at 11:30:42 AM UTC+8, Dave Yeo wrote:
Hi Dave. Thanks for your reply.
> Hi Paul, note I'm not the most knowledgeable user, not many of us
> monitoring usenet now though hopefully others can chime in. There are a
> couple of mailing lists and the OS2world forum as well where you might
> get help.
I prefer newsgroups which are basically public domain,
publicly available, and uncensored as far as I know.
But yeah - I signed up to os2world as well, but I think I
was supposed to get a verification email that never arrived.
I'll chase it up if/when required.
> > I can't find any evidence that Odin is still being developed,
> > although it hasn't been that long (6 years) since the last
> > release.
> As far as I know, it is not being developed anymore. It can be forked
> and development continued. The last development was by Bitwise, things
> like building OpenJDK, a Flash wrapper and running Flash and earlier by
> Innotek, running Adobe Acrobat.
> Note that it is quite possible to use Odin to build native OS/2 Win32
> applications such as was done with OpenJDK, x:\Programs\OpenJDK on your
> ArcaOS install or for source, https://trac.netlabs.org/java.
> Development is usually done with GCC but OpenWatcom should work as well
> with the right calling conventions.
Ok. I have had success in getting my old development
environment up and running. I can once again produce
native OS/2 executables using Open Watcom and my
own C library.
And I had instead an idea to replace Odin, with the
limited scope I have in mind. Because I already have
much of the infrastructure in place (e.g. code to load
a win32 executable), as part of PDOS/386. I largely
just need to replace the not-very-big kernel32.c with
one that does OS/2 calls instead of PDOS calls. There
are a few other things.
> > However, programs of mine that use ANSI escape codes
> > do not work properly - the ESC appears to be ignored/
> > swallowed.
> Not sure about that one, perhaps someone else has some insight.
I have confirmed that when I build my own OS/2 native
executables, the escape sequences take effect.
So if I go the route of writing a public domain, somewhat
minimal, win32 environment for OS/2, I know that the
escapes will get through.
However, I still have a problem with keyboard input. I
need to get ANSI escapes - or at least - something -
when I press the different cursor keys. Otherwise my
version of microemacs 3.6 (also public domain - that
older version) won't work.
So I wrote a test program, and if I build it as a win32
executable (using pdpclib) and run it under "pec", all
the cursor keys generate a x'e0'.
If I instead build an OS/2 native executable (also with
pdpclib), I don't get any input at all.
The "keys off" command doesn't change either of
the above.
PDPCLIB is using this code:
C:\devel\pdos\pdpclib>git diff stdio.c
diff --git a/pdpclib/stdio.c b/pdpclib/stdio.c
index 685e3e4c..f6b837e6 100644
--- a/pdpclib/stdio.c
+++ b/pdpclib/stdio.c
@@ -1921,6 +1921,7 @@ static void iread(FILE *stream, void *ptr, size_t toread, size_t *actualRead)
#ifdef __OS2__
+printf("about to do dosread of %d\n", (int)stream->hfile);
rc = DosRead(stream->hfile, ptr, toread, &tempRead);
if (rc != 0)
{
C:\devel\pdos\pdpclib>
ie doing a DosRead from handle 0.
I thought there might be a DosDevIOCtl that governs this
behavior, so I went looking for the documentation.
I was surprised that this was all I could find online:
http://www.edm2.com/index.php/DosDevIOCtl
which is insufficient. I actually need three things for
a fullscreen editor like microemacs:
1. Cursor keys to come through with unique codes.
2. Echo switched off.
3. Line buffering switched off.
On MSDOS I can use INT 21H AH=44H to change those
last two things. But without documentation I don't know
if the equivalent exists in OS/2. I know what is required
in Windows too.
> > In addition, the doco says that the driver is no longer
> > working, so I need to run everything via pec. Which
> > probably means I need to provide my own shell.
> > Which I can probably do, as I have 3 flavors of my
> > shell already (for 3 different flavors of PDOS).
> Wonder if it is possible to run PDOS in a DOS session?
PDOS/86 is an 8086 OS, so it would be a replacement
for OS/2's DOS, and not be useful regardless.
But PDOS/386 has the infrastructure to do 32-bit for
Windows, so as above - I can potentially do what I want
in an OS/2 window.
Although - I just realized while typing this that I could
possibly install HX into a DOS window to run everything.
I come close to being able to do that in Freedos+HX
already.
> > But that won't really work without ANSI escapes.
> > Well - I believe it will work to some extent.
> >
> > Another thing I haven't figured out yet is how to get
> > LFN working on my FAT partition. There is supposedly
> > a "longname" extended attribute to allow this.
> The longname extended attribute is only used by the WPS and there can be
> problems with file systems that are not FAT, namely when the longname
> and actual filename get out of sync.
> Generally the FAT support is in the kernel but there are IFS's that
> support vfat such as the FAT32.IFS, https://trac.netlabs.org/fat32 this
> is related to the FAT32.IFS that ships with ArcaOS but Arca Noae didn't
> like the chances of patent problems with the exfat support so forked it.
It took me a while to realize that fat32.ifs already came
installed in ArcaOS and all I needed to do was
format /fs:fat32
instead of the fat that you see with "format /?".
And now long filenames work perfectly fine on the FAT32-formatted disk!
> > Any thoughts on how to create a win32 console
> > environment?
> There has been various shells written/ported to OS/2, there are the
> limits of a VIO window if you go that route. The only source of one I
> can think of is https://github.com/komh/kshell which might give some ideas.
> Also could use a regular Presentation Manager window to display your shell
I think the VIO thing is what is swallowing the ESC character.
And what I need to do is switch to standard streams.
Any thoughts welcome!
Thanks. Paul.
Hi Dave. Thanks for your reply.
> Hi Paul, note I'm not the most knowledgeable user, not many of us
> monitoring usenet now though hopefully others can chime in. There are a
> couple of mailing lists and the OS2world forum as well where you might
> get help.
publicly available, and uncensored as far as I know.
But yeah - I signed up to os2world as well, but I think I
was supposed to get a verification email that never arrived.
I'll chase it up if/when required.
> > I can't find any evidence that Odin is still being developed,
> > although it hasn't been that long (6 years) since the last
> > release.
> As far as I know, it is not being developed anymore. It can be forked
> and development continued. The last development was by Bitwise, things
> like building OpenJDK, a Flash wrapper and running Flash and earlier by
> Innotek, running Adobe Acrobat.
> Note that it is quite possible to use Odin to build native OS/2 Win32
> applications such as was done with OpenJDK, x:\Programs\OpenJDK on your
> ArcaOS install or for source, https://trac.netlabs.org/java.
> Development is usually done with GCC but OpenWatcom should work as well
> with the right calling conventions.
environment up and running. I can once again produce
native OS/2 executables using Open Watcom and my
own C library.
And I had instead an idea to replace Odin, with the
limited scope I have in mind. Because I already have
much of the infrastructure in place (e.g. code to load
a win32 executable), as part of PDOS/386. I largely
just need to replace the not-very-big kernel32.c with
one that does OS/2 calls instead of PDOS calls. There
are a few other things.
> > However, programs of mine that use ANSI escape codes
> > do not work properly - the ESC appears to be ignored/
> > swallowed.
> Not sure about that one, perhaps someone else has some insight.
executables, the escape sequences take effect.
So if I go the route of writing a public domain, somewhat
minimal, win32 environment for OS/2, I know that the
escapes will get through.
However, I still have a problem with keyboard input. I
need to get ANSI escapes - or at least - something -
when I press the different cursor keys. Otherwise my
version of microemacs 3.6 (also public domain - that
older version) won't work.
So I wrote a test program, and if I build it as a win32
executable (using pdpclib) and run it under "pec", all
the cursor keys generate a x'e0'.
If I instead build an OS/2 native executable (also with
pdpclib), I don't get any input at all.
The "keys off" command doesn't change either of
the above.
PDPCLIB is using this code:
C:\devel\pdos\pdpclib>git diff stdio.c
diff --git a/pdpclib/stdio.c b/pdpclib/stdio.c
index 685e3e4c..f6b837e6 100644
--- a/pdpclib/stdio.c
+++ b/pdpclib/stdio.c
@@ -1921,6 +1921,7 @@ static void iread(FILE *stream, void *ptr, size_t toread, size_t *actualRead)
#ifdef __OS2__
+printf("about to do dosread of %d\n", (int)stream->hfile);
rc = DosRead(stream->hfile, ptr, toread, &tempRead);
if (rc != 0)
{
C:\devel\pdos\pdpclib>
ie doing a DosRead from handle 0.
I thought there might be a DosDevIOCtl that governs this
behavior, so I went looking for the documentation.
I was surprised that this was all I could find online:
http://www.edm2.com/index.php/DosDevIOCtl
which is insufficient. I actually need three things for
a fullscreen editor like microemacs:
1. Cursor keys to come through with unique codes.
2. Echo switched off.
3. Line buffering switched off.
On MSDOS I can use INT 21H AH=44H to change those
last two things. But without documentation I don't know
if the equivalent exists in OS/2. I know what is required
in Windows too.
> > In addition, the doco says that the driver is no longer
> > working, so I need to run everything via pec. Which
> > probably means I need to provide my own shell.
> > Which I can probably do, as I have 3 flavors of my
> > shell already (for 3 different flavors of PDOS).
> Wonder if it is possible to run PDOS in a DOS session?
for OS/2's DOS, and not be useful regardless.
But PDOS/386 has the infrastructure to do 32-bit for
Windows, so as above - I can potentially do what I want
in an OS/2 window.
Although - I just realized while typing this that I could
possibly install HX into a DOS window to run everything.
I come close to being able to do that in Freedos+HX
already.
> > But that won't really work without ANSI escapes.
> > Well - I believe it will work to some extent.
> >
> > Another thing I haven't figured out yet is how to get
> > LFN working on my FAT partition. There is supposedly
> > a "longname" extended attribute to allow this.
> The longname extended attribute is only used by the WPS and there can be
> problems with file systems that are not FAT, namely when the longname
> and actual filename get out of sync.
> Generally the FAT support is in the kernel but there are IFS's that
> support vfat such as the FAT32.IFS, https://trac.netlabs.org/fat32 this
> is related to the FAT32.IFS that ships with ArcaOS but Arca Noae didn't
> like the chances of patent problems with the exfat support so forked it.
installed in ArcaOS and all I needed to do was
format /fs:fat32
instead of the fat that you see with "format /?".
And now long filenames work perfectly fine on the FAT32-formatted disk!
> > Any thoughts on how to create a win32 console
> > environment?
> There has been various shells written/ported to OS/2, there are the
> limits of a VIO window if you go that route. The only source of one I
> can think of is https://github.com/komh/kshell which might give some ideas.
> Also could use a regular Presentation Manager window to display your shell
And what I need to do is switch to standard streams.
Any thoughts welcome!
Thanks. Paul.
xhajt03
Jul 15, 2023, 6:34:16 PM7/15/23
to
On Saturday, July 15, 2023 at 7:02:14 UTC+2, Paul Edwards wrote:
.
> > > But that won't really work without ANSI escapes. ;-----;;;;;;;
> I think the VIO thing is what is swallowing the ESC character.
> And what I need to do is switch to standard streams.
I don't think that you can ever get cursor keys from stdin under OS/2 - only regular characters are delivered that way. You'd need to use the (16-bit) kbdcalls with thunking, or some wrapper around it (EMXWRAP.DLL from EMX runtime, or something else).
Tomas
.
.
> > > However, programs of mine that use ANSI escape codes
> > > do not work properly - the ESC appears to be ignored/
> > > swallowed.
>
> > Not sure about that one, perhaps someone else has some insight.
> I have confirmed that when I build my own OS/2 native
> executables, the escape sequences take effect.
I believe that Win32 console applications executed via Odin are actually run in a PM window rather than a real OS/2 console window and ANSI codes are probably not interpreted there.
> > > However, programs of mine that use ANSI escape codes
> > > do not work properly - the ESC appears to be ignored/
> > > swallowed.
>
> > Not sure about that one, perhaps someone else has some insight.
> I have confirmed that when I build my own OS/2 native
> executables, the escape sequences take effect.
> I think the VIO thing is what is swallowing the ESC character.
> And what I need to do is switch to standard streams.
Tomas
Paul Edwards
Jul 15, 2023, 7:05:09 PM7/15/23
to
On Sunday, July 16, 2023 at 6:34:16 AM UTC+8, xhajt03 wrote:
> > > Not sure about that one, perhaps someone else has some insight.
> > I have confirmed that when I build my own OS/2 native
> > executables, the escape sequences take effect.
> I believe that Win32 console applications executed via Odin are actually run in a PM window rather than a real OS/2 console window and ANSI codes are probably not interpreted there.
When running from an OS/2 command prompt, "pe" is used
> > > Not sure about that one, perhaps someone else has some insight.
> > I have confirmed that when I build my own OS/2 native
> > executables, the escape sequences take effect.
> I believe that Win32 console applications executed via Odin are actually run in a PM window rather than a real OS/2 console window and ANSI codes are probably not interpreted there.
for Win32 graphics programs, and "pec" is used to run
console mode programs. "pec" does not open a new window
and it looks totally like it stays in the OS/2 command prompt.
But I may be mistaken.
> > I think the VIO thing is what is swallowing the ESC character.
> > And what I need to do is switch to standard streams.
> I don't think that you can ever get cursor keys from stdin under OS/2 - only regular characters are delivered that way. You'd need to use the (16-bit) kbdcalls with thunking, or some wrapper around it (EMXWRAP.DLL from EMX runtime, or something else).
Ok, thanks for the tip. If that's what I need to use, so be it.
It will all be hidden in my C library anyway.
Thanks. Paul.
Paul Edwards
Jul 15, 2023, 8:56:34 PM7/15/23
to
I had some luck.
I finally found the programming documentation:
http://www.os2museum.com/wp/os2-history/os2-library/os2-2-0-technical-library/
and now I know (PDF scan) why google searching didn't find it.
I thought this was the right manual:
http://www.os2museum.com/files/docs/os220tl/os2-2.0-pdd-ref-1992.pdf
page 18-93
But this code:
APIRET rc;
ULONG tempRead;
USHORT parm = 1;
ULONG parmlen = sizeof parm;
KBDKEYINFO cd;
ULONG datalen = 0;
printf("about to ioctl\n");
rc = DosDevIOCtl(0 /* handle */,
4, /* category */
0x74, /* function */
&parm, /* parm area */
sizeof parm,
&parmlen, /* potentially output */
&cd, /* data area */
sizeof cd, /* maximum size */
&datalen); /* potentially output */
printf("rc is %d\n", rc);
gave me a return code of 22, which I found out from the
Watcom header is UNKNOWN_COMMAND, and that
seems to be documented here:
This function returns an UNKNOWN_ COMMAND error if the caller is in the Presentation Manager session
Even though I'm running via command prompt. I tried opening
a fullscreen window, but that didn't change anything, ie still
rc 22.
Then I had the idea that maybe I'm not supposed to be using
the Physical Device Driver Reference and I should instead be
using either the Virtual Device or Presentation.
I'm currently downloading those manuals and it's taking a while.
I also checked the Watcom header and found:
bsesub.h: USHORT APIENTRY16 KbdCharIn(PKBDKEYINFO,USHORT,HKBD);
So it's the 16-bit call that was mentioned, and Watcom
must do auto-thunking.
Ideally I wouldn't rely on that and would switch to 32-bit
DosDevIOCtl:
bsedos.h: APIRET APIENTRY DosDevIOCtl(HFILE,ULONG,ULONG,PVOID,ULONG,PULONG,PVOID,ULONG,PULONG);
(note APIENTRY, not APIENTRY16)
BFN. Paul.
I finally found the programming documentation:
http://www.os2museum.com/wp/os2-history/os2-library/os2-2-0-technical-library/
and now I know (PDF scan) why google searching didn't find it.
I thought this was the right manual:
http://www.os2museum.com/files/docs/os220tl/os2-2.0-pdd-ref-1992.pdf
page 18-93
But this code:
APIRET rc;
ULONG tempRead;
USHORT parm = 1;
ULONG parmlen = sizeof parm;
KBDKEYINFO cd;
ULONG datalen = 0;
printf("about to ioctl\n");
rc = DosDevIOCtl(0 /* handle */,
4, /* category */
0x74, /* function */
&parm, /* parm area */
sizeof parm,
&parmlen, /* potentially output */
&cd, /* data area */
sizeof cd, /* maximum size */
&datalen); /* potentially output */
printf("rc is %d\n", rc);
gave me a return code of 22, which I found out from the
Watcom header is UNKNOWN_COMMAND, and that
seems to be documented here:
This function returns an UNKNOWN_ COMMAND error if the caller is in the Presentation Manager session
Even though I'm running via command prompt. I tried opening
a fullscreen window, but that didn't change anything, ie still
rc 22.
Then I had the idea that maybe I'm not supposed to be using
the Physical Device Driver Reference and I should instead be
using either the Virtual Device or Presentation.
I'm currently downloading those manuals and it's taking a while.
I also checked the Watcom header and found:
bsesub.h: USHORT APIENTRY16 KbdCharIn(PKBDKEYINFO,USHORT,HKBD);
So it's the 16-bit call that was mentioned, and Watcom
must do auto-thunking.
Ideally I wouldn't rely on that and would switch to 32-bit
DosDevIOCtl:
bsedos.h: APIRET APIENTRY DosDevIOCtl(HFILE,ULONG,ULONG,PVOID,ULONG,PULONG,PVOID,ULONG,PULONG);
(note APIENTRY, not APIENTRY16)
BFN. Paul.
Paul Edwards
Jul 15, 2023, 9:29:44 PM7/15/23
to
Nope. Neither of those manuals seemed to be useful.
I tried this:
stdio.c(1932): Warning! W131: No prototype found for function 'VDHDevIOCtl'
but got a link error.
The only other thing I can think of is to create a logical keyboard.
I saw that mentioned.
BFN. Paul.
I tried this:
stdio.c(1932): Warning! W131: No prototype found for function 'VDHDevIOCtl'
but got a link error.
The only other thing I can think of is to create a logical keyboard.
I saw that mentioned.
BFN. Paul.
xhajt03
Jul 15, 2023, 11:43:58 PM7/15/23
to
On July 16, 2023 at 2:56:32 +0200, Paul Edwards wrote:
> I had some luck.
>
> I finally found the programming documentation:
I'm pretty sure the docs must be elsewhere as well and not only scans. Try searching for "OS/2 Control Program Reference".
> I had some luck.
>
> I finally found the programming documentation:
.
.
> gave me a return code of 22, which I found out from the
> Watcom header is UNKNOWN_COMMAND, and that
> seems to be documented here:
>
> This function returns an UNKNOWN_ COMMAND error if the caller is in the Presentation Manager session
>
>
> Even though I'm running via command prompt. I tried opening
> a fullscreen window, but that didn't change anything, ie still
> rc 22.
Have you made sure to set the application type to "VIO" (or "VIO compatible", or whatever it's named there - not PM and not FS) in the Watcom compiler when compiling your application? It doesn't depend on where you start it, the application type must be set correctly in the EXE header. But anyway - don't try to read keyboard using DosDevIOCtl - that may be used for device drivers trying to intervene with keyboard input (the manual you found is for creating physical device drivers!), but simple console programs are not supposed to do that. Sticking to my recommendation to use kbdcalls.dll would be much more useful...
> Watcom header is UNKNOWN_COMMAND, and that
> seems to be documented here:
>
> This function returns an UNKNOWN_ COMMAND error if the caller is in the Presentation Manager session
>
>
> Even though I'm running via command prompt. I tried opening
> a fullscreen window, but that didn't change anything, ie still
> rc 22.
> Then I had the idea that maybe I'm not supposed to be using
> the Physical Device Driver Reference and I should instead be
> using either the Virtual Device or Presentation.
> I'm currently downloading those manuals and it's taking a while.
>
> I also checked the Watcom header and found:
>
> bsesub.h: USHORT APIENTRY16 KbdCharIn(PKBDKEYINFO,USHORT,HKBD);
>
> So it's the 16-bit call that was mentioned, and Watcom
> must do auto-thunking.
> Ideally I wouldn't rely on that and would switch to 32-bit
> DosDevIOCtl:
>
> bsedos.h: APIRET APIENTRY DosDevIOCtl(HFILE,ULONG,ULONG,PVOID,ULONG,PULONG,PVOID,ULONG,PULONG);
>
> (note APIENTRY, not APIENTRY16)
Tomas
Paul Edwards
Jul 16, 2023, 2:17:12 AM7/16/23
to
On Sunday, July 16, 2023 at 11:43:58 AM UTC+8, xhajt03 wrote:
> I'm pretty sure the docs must be elsewhere as well and not only scans. Try searching for "OS/2 Control Program Reference".
Although a google search didn't find it, I eventually found it here:
> I'm pretty sure the docs must be elsewhere as well and not only scans. Try searching for "OS/2 Control Program Reference".
http://www.edm2.com/
(auto-redirects to:)
http://www.edm2.com/index.php/Main_Page
(click on "List of OS/2 Documentation")
http://www.edm2.com/index.php/List_of_OS/2_Documentation
(click on "IBM Publications")
http://www.edm2.com/index.php/IBM_Publications
(under "BM OS/2 Toolkit Information (IBM External Submission #24167)"
click on "Control Program Programming Guide and Reference")
http://www.edm2.com/index.php/Control_Program_Programming_Guide_and_Reference
(and then click on things on the right)
> Have you made sure to set the application type to "VIO" (or "VIO compatible",
> or whatever it's named there - not PM and not FS)
form ::= "OS2" ["FLat"|"LE"|"LX"] ["PHYSdevice" | "VIRTdevice"
| ["DLl"["INITGlobal"|"INITInstance" ["TERMInstance"|"TERMGlobal"]]
| "PM" | "PMCompatible" | "FULLscreen"]
"fullscreen" opens a full screen when I tried, so that's not
the default. I tried "PMC" and that had no effect from the
original. I didn't see any VIO mentioned.
C:\devel\pdos\pdpclib>wlink /? | grep -i vio
C:\devel\pdos\pdpclib>
> but simple console programs are not supposed to do that.
of my C runtime library (pdpclib) for OS/2 so that any app that
links with it can do a setvbuf NBF and it automatically switches
off echo and returns keystrokes, which is exactly what is needed
for fullscreen apps like the microemacs editor. At the same time
I wish to present those apps with ANSI escapes, e.g. ESC [ A, for
cursor keys, the same way as ANSI escapes are already being
handled automatically for output.
Basically the C library hides any "deficiencies" in the OS.
Another thing I noticed was this:
http://www.edm2.com/index.php/OS/2_Device_Driver_Frequently_Asked_Questions
How can I query the OS/2 language version at initialisation time
Question: I want my driver query the language version of the system so I can output messages in the correct language.
Answer: There are several ways to do this:
Open the keyboard driver (DosOpen ("KBD$", ...)) and pass in an IOCtl request to query the current codepage.
And here too:
http://www.edm2.com/index.php/CPGuide_-_Device_I/O#Accessing_Devices
Device Names
To open a device using DosOpen, the application must supply the reserved name for that device. For example, to open the console (both keyboard and screen), you must specify the name CON.
(it clearly says that applications can do this)
and a little further down it says:
(Applications can communicate with device drivers also, by using DosDevIOCtl. See IOCtl Interface)
Regardless, I tried to do a DosOpen of both KBD$ and CON,
but in both cases - even though that was successful - the
DosDevIOCtl failed with rc 22 still.
Here is the code I used:
#ifdef __OS2__
APIRET rc;
ULONG tempRead;
USHORT parm = 1;
ULONG parmlen = sizeof parm;
KBDKEYINFO cd;
ULONG datalen = 0;
ULONG action;
ULONG tempRead;
USHORT parm = 1;
ULONG parmlen = sizeof parm;
KBDKEYINFO cd;
ULONG datalen = 0;
ULONG newsize = 0;
ULONG fileAttr = 0;
ULONG openAction = FILE_OPEN;
ULONG openMode = 0;
#endif
#ifdef __OS2__
printf("about to open\n");
openMode = OPEN_ACCESS_READONLY | OPEN_SHARE_DENYNONE;
/* openAction |= OPEN_ACTION_OPEN_IF_EXISTS; */
/* tried KBD$ and CON */
rc = DosOpen((PSZ)"CON",
&stream->hfile,
&action,
newsize,
fileAttr,
openAction,
openMode,
NULL);
printf("rc is %d\n", rc);
printf("about to ioctl\n");
/* was Dos, try VDH */
rc = DosDevIOCtl(stream->hfile, /* handle */
4, /* category */
0x74, /* function */
&parm, /* parm area */
sizeof parm,
&parmlen, /* potentially output */
&cd, /* data area */
sizeof cd, /* maximum size */
&datalen); /* potentially output */
printf("rc is %d\n", rc);
0x74, /* function */
&parm, /* parm area */
sizeof parm,
&parmlen, /* potentially output */
&cd, /* data area */
sizeof cd, /* maximum size */
&datalen); /* potentially output */
printf("rc is %d\n", rc);
printf("about to do dosread of %d\n", (int)stream->hfile);
rc = DosRead(stream->hfile, ptr, toread, &tempRead);
rc = DosRead(stream->hfile, ptr, toread, &tempRead);
printf("rc is %d\n", rc);
There is one more thing I found before resorting to 16-bit calls:
http://www.edm2.com/index.php/Input/Output_Device_Driver_Reference/Keyboard_Device_Driver
Keystroke Monitors
Some applications need to view the raw keystrokes as they arrive from the keyboard at interrupt time. These applications might consume, modify, or replace keystrokes. This is made possible by the keystroke monitor function.
An application operating with the OS/2 system cannot register a keyboard monitor for a Presentation Manager session. When DosMonReg is issued with keyboard devices, the INDEX parameter indicates which OS/2 session, requested by the caller, is to register the monitor. The INDEX parameter indicates an OS/2 session from 0-15. (For more information on DevHlp_ DosGetInfoSeg, refer to the OS/2 Physical Device Driver Reference.)
An INDEX parameter value of -1 indicates that the session of the calling thread is being requested. If the caller requests either the Presentation Manager session or a DOS session, a MONITORS_NOT_SUPPORTED error is returned.
I will try that next I guess.
BFN. Paul.
Paul Edwards
Jul 16, 2023, 2:47:08 AM7/16/23
to
On Sunday, July 16, 2023 at 2:17:12 PM UTC+8, Paul Edwards wrote:
> When DosMonReg is issued with keyboard devices,
> When DosMonReg is issued with keyboard devices,
> I will try that next I guess.
That's also 16-bit. :-(
C:\watcom\h\os2>grep -i dosmonreg '*'
bsedos.h: #define DosMonReg DOS16MONREG
bsedos.h: USHORT APIENTRY16 DosMonReg(HMONITOR,PBYTE,PBYTE,USHORT,USHORT);
bseord.h: #define ORD_DOSMONREG 5
C:\watcom\h\os2>
BFN. Paul.
Paul Edwards
Jul 16, 2023, 5:20:13 AM7/16/23
to
On Sunday, July 16, 2023 at 2:17:12 PM UTC+8, Paul Edwards wrote:
> form ::= "OS2" ["FLat"|"LE"|"LX"] ["PHYSdevice" | "VIRTdevice"
> | ["DLl"["INITGlobal"|"INITInstance" ["TERMInstance"|"TERMGlobal"]]
> | "PM" | "PMCompatible" | "FULLscreen"]
http://www.edm2.com/index.php/CPGuide_-_Control_Program_Functions
> | ["DLl"["INITGlobal"|"INITInstance" ["TERMInstance"|"TERMGlobal"]]
> | "PM" | "PMCompatible" | "FULLscreen"]
These functions can be used in full-screen, windowed (VIO), and Presentation Manager sessions to perform basic operating-system functions, such as file input and output, memory allocation, thread control and communication, process control and communication, pipe and queue manipulation, and exception and error handling.
Sounds like windows(VIO) = "PMCompatible".
And regardless, "fullscreen" is surely the opposite of "PM session".
So how can I get a rc = 22 even when I choose fullscreen?
BFN. Paul.
xhajt03
Jul 16, 2023, 6:58:40 AM7/16/23
to
On Sunday, July 16, 2023 at 11:20:13 +0200 Paul Edwards wrote:
> On Sunday, July 16, 2023 at 2:17:12 PM UTC+8, Paul Edwards wrote:
.
> On Sunday, July 16, 2023 at 2:17:12 PM UTC+8, Paul Edwards wrote:
.
> http://www.edm2.com/index.php/CPGuide_-_Control_Program_Functions
Yes, edm2.com is a reasonable source.
.
.
> Sounds like windows(VIO) = "PMCompatible".
Yes.
> Sounds like windows(VIO) = "PMCompatible".
> And regardless, "fullscreen" is surely the opposite of "PM session".
> So how can I get a rc = 22 even when I choose fullscreen?
Tomas
Paul Edwards
Jul 16, 2023, 12:03:28 PM7/16/23
to
On Sunday, July 16, 2023 at 6:58:40 PM UTC+8, xhajt03 wrote:
> > http://www.edm2.com/index.php/CPGuide_-_Control_Program_Functions
>
> Yes, edm2.com is a reasonable source.
That link seems to have not been converted properly.
> > http://www.edm2.com/index.php/CPGuide_-_Control_Program_Functions
>
> Yes, edm2.com is a reasonable source.
The functions for controlling a COM port are there,
but not other devices like the keyboard. So you need
to go to the PDF for them.
> > So how can I get a rc = 22 even when I choose fullscreen?
> Because you try to use functions intended for device drivers in a
> regular application instead of following the received advice?
the situation.
There are lots of DosDevIOCtl things. E.g. you can set the baud
rate of a COM port. Surely this is something for regular
applications to do - not just device drivers?
Also note that other systems (MSDOS, Windows, Unix) use
ioctl for regular programs to change between canonical and
raw mode etc too. At least as an OPTION for the regular
streams.
So who is allowed to call the KBD DosDevIOCtl?
Is it documented that you're allowed to do it for serial
ports, but not keyboards?
Or have I misunderstood serial ports too? I just saw
example code doing that.
Thanks. Paul.
xhajt03
Jul 16, 2023, 5:51:21 PM7/16/23
to
On Sunday, July 16, 2023 at 18:03:28 +0200 Paul Edwards wrote:
> On Sunday, July 16, 2023 at 6:58:40 PM UTC+8, xhajt03 wrote:
> That link seems to have not been converted properly.
> The functions for controlling a COM port are there,
> but not other devices like the keyboard. So you need
> to go to the PDF for them.
You should try to find the original IBM .inf files. I believe the version extended for WSeB / MCP was freely available somewhere on the net, but I'm on a meadow with poor mobile coverage, no electricity and just a mobile phone which is not the best situation for extensive searching...
> On Sunday, July 16, 2023 at 6:58:40 PM UTC+8, xhajt03 wrote:
> That link seems to have not been converted properly.
> The functions for controlling a COM port are there,
> but not other devices like the keyboard. So you need
> to go to the PDF for them.
> > > So how can I get a rc = 22 even when I choose fullscreen?
>
> > Because you try to use functions intended for device drivers in a
> > regular application instead of following the received advice?
> I'm sorry if I appear to be difficult, but I'm trying to understand
> the situation.
>
> There are lots of DosDevIOCtl things. E.g. you can set the baud
> rate of a COM port. Surely this is something for regular
> applications to do - not just device drivers?
> Also note that other systems (MSDOS, Windows, Unix) use
> ioctl for regular programs to change between canonical and
> raw mode etc too. At least as an OPTION for the regular
> streams.
> So who is allowed to call the KBD DosDevIOCtl?
.
Sorry, I don't know, but I do know how to achieve what you stated as your goal (and that's what I suggested).
Tomas
Dave Yeo
Jul 16, 2023, 11:30:08 PM7/16/23
to
Paul Edwards wrote:
> I had some luck.
>
> I finally found the programming documentation:
>
> http://www.os2museum.com/wp/os2-history/os2-library/os2-2-0-technical-library/
>
> and now I know (PDF scan) why google searching didn't find it.
>
> I thought this was the right manual:
>
> http://www.os2museum.com/files/docs/os220tl/os2-2.0-pdd-ref-1992.pdf
Yum install os2tk45-books will give you the documentation from the os2
> I had some luck.
>
> I finally found the programming documentation:
>
> http://www.os2museum.com/wp/os2-history/os2-library/os2-2-0-technical-library/
>
> and now I know (PDF scan) why google searching didn't find it.
>
> I thought this was the right manual:
>
> http://www.os2museum.com/files/docs/os220tl/os2-2.0-pdd-ref-1992.pdf
ver 4.5 toolkit, better to use the ANPM package manager and you can
install most of the toolkit (SOM stuff is missing). The toolkit headers
and libs work fine with OW
Dave
Dave Yeo
Jul 16, 2023, 11:45:01 PM7/16/23
to
Paul Edwards wrote:
> Crikey. I thought that OS/2 2.0 had done a total switch to 32-bit.
No, there was still quite a bit of 16 bit code that needed updating and
> Crikey. I thought that OS/2 2.0 had done a total switch to 32-bit.
some never got updated even in the latest.
Another consideration is that 16 bit functions are stuck needing to be
in the lower memory range (below 1GB, or actually below 512MB - whatever
DLLs are loaded. Mem /v will show your memory).
Win32's got broken on OS/2 by MS forcing some DLL's to load above the
1GB barrier and even now some functions probably require OS/2 4.5+ for
high memory access.
Dave
Paul Edwards
Jul 17, 2023, 12:11:49 AM7/17/23
to
On Monday, July 17, 2023 at 11:45:01 AM UTC+8, Dave Yeo wrote:
> Another consideration is that 16 bit functions are stuck needing to be
> in the lower memory range (below 1GB, or actually below 512MB - whatever
> DLLs are loaded. Mem /v will show your memory).
> Win32's got broken on OS/2 by MS forcing some DLL's to load above the
> 1GB barrier and even now some functions probably require OS/2 4.5+ for
> high memory access.
Did you mean Win32s?
> Another consideration is that 16 bit functions are stuck needing to be
> in the lower memory range (below 1GB, or actually below 512MB - whatever
> DLLs are loaded. Mem /v will show your memory).
> Win32's got broken on OS/2 by MS forcing some DLL's to load above the
> 1GB barrier and even now some functions probably require OS/2 4.5+ for
> high memory access.
That works under OS/2?
Is it allowed to be installed on OS/2? Or is it native?
Noting that I already have my own msvcrt.dll, I was actually
thinking of creating a custom version of msvcrt.dll that worked
on win32s for Windows for Workgroups 3.11 (by doing text
on a graphics window).
I'm not familiar with Windows graphics programming though,
so haven't started that.
BFN. Paul.
Dave Yeo
Jul 17, 2023, 2:04:14 AM7/17/23
to
Paul Edwards wrote:
> On Monday, July 17, 2023 at 11:45:01 AM UTC+8, Dave Yeo wrote:
>
>> Another consideration is that 16 bit functions are stuck needing to be
>> in the lower memory range (below 1GB, or actually below 512MB - whatever
>> DLLs are loaded. Mem /v will show your memory).
>> Win32's got broken on OS/2 by MS forcing some DLL's to load above the
>> 1GB barrier and even now some functions probably require OS/2 4.5+ for
>> high memory access.
>
> Did you mean Win32s?
Yes
> On Monday, July 17, 2023 at 11:45:01 AM UTC+8, Dave Yeo wrote:
>
>> Another consideration is that 16 bit functions are stuck needing to be
>> in the lower memory range (below 1GB, or actually below 512MB - whatever
>> DLLs are loaded. Mem /v will show your memory).
>> Win32's got broken on OS/2 by MS forcing some DLL's to load above the
>> 1GB barrier and even now some functions probably require OS/2 4.5+ for
>> high memory access.
>
> Did you mean Win32s?
>
> That works under OS/2?
>
> Is it allowed to be installed on OS/2? Or is it native?
worked fine, Win32s 1.30 was broken due to some DLL's being hard code to
load too high for OS/2 to handle. You could have a hybrid by using some
1.25 DLL's with 1.30. Forget the specifics, should be easily searched.
>
> Noting that I already have my own msvcrt.dll, I was actually
> thinking of creating a custom version of msvcrt.dll that worked
> on win32s for Windows for Workgroups 3.11 (by doing text
> on a graphics window).
window on the desktop. Look in the cmd prompts folder and test, both
full screen and windowed. A lot of recent VGA BIOSes are missing
something so Windows won't run in a window. ArcaOS 5.1 (due to be
released soon) when booted in UEFI does use its own VGA BIOS and WinOS2
(and DOS) works well in a window. This computer I'm typing on only
displays DOS/WinOS2 in full screen mode unless I'm using a beta of 5.1
and UEFI boot.
Note that Winos2 has the same drawbacks as DOS on OS/2, no long file
names for example. Lots of memory available though and you can have
multiple sessions running at the same time.
Dave
Dave Yeo
Jul 17, 2023, 2:11:30 AM7/17/23
to
Win32s 1.25 is here,
https://hobbes.nmsu.edu/?path=%2Fpub%2Fwindows%2Fsystem%2Fwin32s
Hobbes has a lot of OS/2 software.
Dave
https://hobbes.nmsu.edu/?path=%2Fpub%2Fwindows%2Fsystem%2Fwin32s
Hobbes has a lot of OS/2 software.
Dave
Paul Edwards
Jul 17, 2023, 10:07:01 AM7/17/23
to
It wasn't clear to me what the warp32s file did, so I tried
that first and it hosed my ArcaOS.
I'm running under virtualbox so it was easily restored.
Then I ran 1.25 (which has a later date than 1.25a), and then
ran a modified PDPCLIB program that writes to a file instead
of stdout - and it worked!
Also, during installation I didn't see any license agreement.
I'm pretty sure when I installed pw1118.exe from here:
https://ftpmirror.your.org/pub/misc/ftp.microsoft.com/Softlib/MSLFILES/
on my Windows for Workgroups 3.11 that there was a license agreement
that said something about only running on Microsoft systems.
But regardless - I couldn't see the forest for the trees.
All I need to do is run pe.exe instead of pec.exe.
I did that, and that worked too, with long filename support even!
So "all" I need to do is create a custom version of my msvcrt.dll
that doesn't do this:
C:\devel\pdos\pdpclib>grep HANDLE start.c
start.c: __stdin->hfile = GetStdHandle(STD_INPUT_HANDLE);
start.c: __stdout->hfile = GetStdHandle(STD_OUTPUT_HANDLE);
start.c: __stderr->hfile = GetStdHandle(STD_ERROR_HANDLE);
C:\devel\pdos\pdpclib>
and instead does everything to an 80 * 25 graphics window with
console font, and interprets (on output) ANSI escapes itself,
and produces (on input) ANSI escapes itself, and I have what I need!
And it will cover WfW 3.11 as well as ArcaOS.
I'm not actually familiar with graphics programming, so I don't know
precisely how to do that, but I'll presumably figure it out eventually.
Thanks eveyone for your help!
BFN. Paul.
Paul Edwards
Jul 17, 2023, 10:13:07 AM7/17/23
to
On Monday, July 17, 2023 at 10:07:01 PM UTC+8, Paul Edwards wrote:
> All I need to do is run pe.exe instead of pec.exe.
Actually I realized I will have a problem with "pe" when one
> All I need to do is run pe.exe instead of pec.exe.
of my executables tries to spawn another executable - unless
I prefix the command with "pe" it will attempt to run it as an
OS/2 program.
So I may need to use this strange (origin unknown) win32s after all.
BFN. Paul.
Paul Edwards
Jul 17, 2023, 10:48:14 AM7/17/23
to
On Monday, July 17, 2023 at 10:13:07 PM UTC+8, Paul Edwards wrote:
> > All I need to do is run pe.exe instead of pec.exe.
> Actually I realized I will have a problem with "pe" when one
> of my executables tries to spawn another executable - unless
> I prefix the command with "pe" it will attempt to run it as an
> OS/2 program.
I just realized - I can simply make it part of my special msvcrt.dll
> > All I need to do is run pe.exe instead of pec.exe.
> Actually I realized I will have a problem with "pe" when one
> of my executables tries to spawn another executable - unless
> I prefix the command with "pe" it will attempt to run it as an
> OS/2 program.
to run "pe" for any program being executed.
BFN. Paul.
Paul Edwards
Jul 17, 2023, 7:50:20 PM7/17/23
to
Another thing that might be possible is to run HX
under DOS to give Win32. Maybe doslfn too.
(ie both of those things running on OS/2)
That would be for activities that don't require ANSI
keyboard input.
BFN. Paul.
under DOS to give Win32. Maybe doslfn too.
(ie both of those things running on OS/2)
That would be for activities that don't require ANSI
keyboard input.
BFN. Paul.
Paul Edwards
Dec 19, 2023, 9:35:48 PM12/19/23
to
On 16/07/23 11:43, xhajt03 wrote:
> On July 16, 2023 at 2:56:32 +0200, Paul Edwards wrote:
> On July 16, 2023 at 2:56:32 +0200, Paul Edwards wrote:
>> I think the VIO thing is what is swallowing the ESC character.
>> And what I need to do is switch to standard streams.
> I don't think that you can ever get cursor keys from stdin under OS/2
> - only regular characters are delivered that way. You'd need to use
> the (16-bit) kbdcalls with thunking, or some wrapper around it
>> And what I need to do is switch to standard streams.
> I don't think that you can ever get cursor keys from stdin under OS/2
> - only regular characters are delivered that way. You'd need to use
> the (16-bit) kbdcalls with thunking, or some wrapper around it
> EMXWRAP.DLL from EMX runtime, or something else).
...
>> Ideally I wouldn't rely on that and would switch to 32-bit
>> DosDevIOCtl:
>>
>> bsedos.h: APIRET APIENTRY DosDevIOCtl(HFILE,ULONG,ULONG,PVOID,ULONG,PULONG,PVOID,ULONG,PULONG);
>>
>> (note APIENTRY, not APIENTRY16)
>
> No, you can't (not to my knowledge anyway, and no OS/2 console programs would ever do that).
else other than researching this issue. Not even
sleeping or eating.
I did drink Jolt Cola though.
And I've finally got a sign of hope, but not
yet fully proven.
This is compiled with Microsoft C 6.0
and run under Windows 2000:
D:\devel\pdos\pdpclib>mstest
about to open
rc is 0, handle is 3
rc from focus is 0
about to get status1
rc is 0, state is 9
about to set status1
rc is 0
about to set status2
rc is 0
about to get status
rc is 0, state is 6
about to do stringin
rc is 0, char1 is e0, char2 is e0
about to charin
rc is 0, char is e0
about to ioctl1
rc is 87
chchar is e0, chscan is 48
about to ioctl2
rc is 0
about to DosRead
rc 5, len 0, bytes e0 e0 0
D:\devel\pdos\pdpclib>mstest
about to open
rc is 0, handle is 3
rc from focus is 0
about to get status1
rc is 0, state is 9
about to set status1
rc is 0
about to set status2
rc is 0
about to get status
rc is 0, state is 6
about to do stringin
rc is 0, char1 is e0, char2 is e0
about to charin
rc is 0, char is e0
about to ioctl1
rc is 87
chchar is e0, chscan is 50
about to ioctl2
rc is 0
about to DosRead
rc 5, len 0, bytes e0 e0 0
D:\devel\pdos\pdpclib>
That x'48' is when I was pressing cursor up
continuously. The x'50' was when I was pressing
cursor down continuously.
I still need to see if I can replace those
other Kbd functions with DosDevIoCtl and I
still need to prove 32-bit under OS/2 2.0+.
The trick was that I needed to open a keyboard
and also I needed to set focus to it.
As to no OS/2 program ever doing this - I'm
hoping to start a movement. :-)
D:\devel\pdos\pdpclib>cl /Lp mstest.c
Microsoft (R) C Optimizing Compiler Version 6.00A
Copyright (c) Microsoft Corp 1984-1990. All rights reserved.
mstest.c
Microsoft (R) Segmented-Executable Linker Version 5.10
Copyright (C) Microsoft Corp 1984-1990. All rights reserved.
Object Modules [.OBJ]: mstest.obj /farcall
Run File [mstest.exe]: "mstest.exe" /noi
List File [NUL.MAP]: NUL
Libraries [.LIB]: /NOD:SLIBCE SLIBCEP.LIB
Definitions File [NUL.DEF]: ;
D:\devel\pdos\pdpclib>
#include <stdio.h>
#define INCL_DOS
#define INCL_DOSDEVICES
#define INCL_KBD
#include <os2.h>
int main(void)
{
USHORT rc;
ULONG tempRead;
USHORT parm = 1;
ULONG parmlen = sizeof parm;
KBDKEYINFO cd;
ULONG datalen = 0;
unsigned char data[200];
USHORT parm = 1;
ULONG parmlen = sizeof parm;
KBDKEYINFO cd;
ULONG datalen = 0;
unsigned char parmdata[200];
/* WORD */ SHORT parmword = 1;
BYTE bb = 0x80;
static KBDINFO kinfo;
static STRINGINBUF si;
HKBD hk = 0;
USHORT len;
#if 1
printf("about to open\n");
rc = KbdOpen(&hk);
printf("rc is %d, handle is %x\n", rc, (int)hk);
rc = KbdGetFocus(IO_WAIT, hk);
printf("rc from focus is %d\n", rc);
#endif
/*kinfo.cb = 10;*/
/*kinfo.fsMask = 0;*/
memset(&kinfo, 0x00, sizeof kinfo);
kinfo.cb = 10;
kinfo.fsMask = 0xffffU;
printf("about to get status1\n");
rc = KbdGetStatus(&kinfo, /* 0 */ hk);
printf("rc is %d, state is %x\n", rc, kinfo.fsMask /* kinfo.fsState */);
kinfo.cb = 10;
/*kinfo.fsState = 2;*/
kinfo.fsMask = 2;
printf("about to set status1\n");
rc = KbdSetStatus(&kinfo, hk);
printf("rc is %d\n", rc);
kinfo.cb = 10;
/*kinfo.fsState = 4;*/
kinfo.fsMask = 4;
printf("about to set status2\n");
rc = KbdSetStatus(&kinfo, hk);
printf("rc is %d\n", rc);
kinfo.cb = 10;
kinfo.fsMask = 0xffffU;
/*kinfo.fsMask = 0;*/
/*memset(&kinfo, 0x00, sizeof kinfo);*/
kinfo.cb = 10;
printf("about to get status\n");
rc = KbdGetStatus(&kinfo, hk);
printf("rc is %d, state is %x\n", rc, kinfo.fsMask /* kinfo.fsState */);
si.cb = 2;
printf("about to do stringin\n");
rc = KbdStringIn(data, &si, 0, hk);
printf("rc is %d, char1 is %x, char2 is %x\n", rc, data[0], data[1]);
printf("about to charin\n");
rc = KbdCharIn(&cd, 0, hk);
printf("rc is %d, char is %x\n", rc, cd.chChar);
printf("about to ioctl1\n");
rc = DosDevIOCtl(&bb,
&cd, /* &parmword, */
0x51, /* function */
4, /* category - 4 = keyboard - not supported in FAPI */
hk); /* handle */
printf("rc is %d\n", rc);
printf("about to ioctl2\n");
rc = DosDevIOCtl(&cd,
&parmword,
0x74, /* function */
4, /* category - 4 = keyboard - not supported in FAPI */
hk); /* handle */
printf("rc is %d\n", rc);
printf("about to DosRead\n");
rc = DosRead(hk, data, 3, &len);
printf("rc %d, len %d, bytes %x %x %x\n", rc, len, data[0], data[1],
data[2]);
return 0;
}
BFN. Paul.
Paul Edwards
Dec 20, 2023, 1:16:19 AM12/20/23
to
I'm very close.
So close that it is working fine for
both 16-bit and 32-bit in a fullscreen
window.
However in a normal window, in both
cases, it works until the DosRead (when
I want things to be back to normal), and
hangs. The keyboard no longer works.
I suspect I have a new issue.
Like I need to create a logical keyboard
or something like that before I do the
DevIoCtl. But that theory doesn't explain
why it is necessary, given that I put
things back to normal already.
cl /Lp mstest.c /link /pm:vio
#include <stdio.h>
#define INCL_DOS
#define INCL_DOSDEVICES
#define INCL_KBD
#include <os2.h>
int main(void)
{
USHORT rc;
ULONG tempRead;
USHORT parm = 1;
ULONG parmlen = sizeof parm;
KBDKEYINFO cd;
ULONG datalen = 0;
unsigned char data[200];
unsigned char parmdata[200];
/* WORD */ SHORT parmword = 1;
BYTE bb = 0x80;
static KBDINFO kinfo;
static STRINGINBUF si;
HKBD hk = 0;
USHORT len = 0;
static USHORT newkeyb[2];
USHORT action;
USHORT fileAttr = 0;
USHORT openAction = 0;
USHORT openMode = 0;
ULONG newsize = 0;
#if 1
printf("about to DosOpen\n");
openMode = OPEN_ACCESS_READONLY | OPEN_SHARE_DENYNONE;
openAction |= OPEN_ACTION_OPEN_IF_EXISTS;
rc = DosOpen((PSZ)"KBD$",
&hk,
printf("rc is %d, hk is %x\n", rc, (int)hk);
#endif
#if 0
printf("about to get input mode\n");
/* equivalent of KbdSetStatus - just for
ASCII/binary - echo not relevant */
rc = DosDevIOCtl(&bb,
NULL, /* &cd, */
0x71, /* function */
#endif
#if 1
printf("about to set binary mode\n");
/* set binary mode */
bb = 0x80;
/* equivalent of KbdSetStatus - only setting
binary - echo not really relevant */
rc = DosDevIOCtl(NULL,
&bb,
#if 1
printf("about to read via 4/74\n");
/* read character records */
#if 1
printf("about to set back to ASCII\n");
/* note that failure to set back to ASCII
causes subsequent DosRead to remain in
binary mode, even after this handle is closed */
bb = 0;
/* equivalent of KbdSetStatus - only setting
ASCII - echo not changed/relevant */
rc = DosDevIOCtl(NULL,
&bb,
#if 1
printf("about to DosClose\n");
rc = DosClose(hk);
printf("about to DosRead\n");
rc = DosRead(0 /* hk */, data, 7, &len);
#include <stdio.h>
#define INCL_DOS
#define INCL_DOSDEVICES
#define INCL_KBD
#include <os2.h>
int main(void)
{
USHORT rc;
ULONG tempRead;
USHORT parm = 1;
USHORT len = 0;
static USHORT newkeyb[2];
ULONG action;
ULONG fileAttr = 0;
ULONG openAction = 0;
ULONG openMode = 0;
ULONG newsize = 0;
ULONG datamax;
ULONG parmmax;
ULONG parmlen;
#if 1
printf("about to DosOpen\n");
openMode = OPEN_ACCESS_READONLY | OPEN_SHARE_DENYNONE;
openAction |= OPEN_ACTION_OPEN_IF_EXISTS;
rc = DosOpen((PSZ)"KBD$",
&hk,
printf("rc is %d, hk is %x\n", rc, (int)hk);
#endif
#if 1
printf("about to set binary mode\n");
/* set binary mode */
bb = 0x80;
/* equivalent of KbdSetStatus - only setting
binary - echo not really relevant */
rc = DosDevIOCtl(hk,
&bb,
1,
&parmlen,
NULL,
0,
&datalen
#if 1
printf("about to read via 4/74\n");
/* read character records */
parmmax = sizeof parmword;
parmlen = 0;
rc = DosDevIOCtl(hk,
&parmword,
parmmax,
&parmlen,
&cd,
sizeof cd,
&datalen
#if 1
printf("about to set back to ASCII\n");
/* note that failure to set back to ASCII
causes subsequent DosRead to remain in
binary mode, even after this handle is closed */
bb = 0;
datalen = 0;
/* equivalent of KbdSetStatus - only setting
ASCII - echo not changed/relevant */
rc = DosDevIOCtl(hk,
&bb,
1,
&parmlen,
NULL,
0,
&datalen
#if 1
printf("about to DosClose\n");
rc = DosClose(hk);
/* in a fullscreen window, this works fine.
in a normal window, dosread hangs */
printf("about to DosRead\n");
rc = DosRead(0 /* hk */, data, 7, &tempRead);
printf("rc %d, len %d, bytes %x %x %x\n", rc, tempRead, data[0],
Thanks. Paul.
So close that it is working fine for
both 16-bit and 32-bit in a fullscreen
window.
However in a normal window, in both
cases, it works until the DosRead (when
I want things to be back to normal), and
hangs. The keyboard no longer works.
I suspect I have a new issue.
Like I need to create a logical keyboard
or something like that before I do the
DevIoCtl. But that theory doesn't explain
why it is necessary, given that I put
things back to normal already.
cl /Lp mstest.c /link /pm:vio
#include <stdio.h>
#define INCL_DOS
#define INCL_DOSDEVICES
#define INCL_KBD
#include <os2.h>
int main(void)
{
USHORT rc;
ULONG tempRead;
USHORT parm = 1;
ULONG parmlen = sizeof parm;
KBDKEYINFO cd;
ULONG datalen = 0;
unsigned char data[200];
unsigned char parmdata[200];
/* WORD */ SHORT parmword = 1;
BYTE bb = 0x80;
static KBDINFO kinfo;
static STRINGINBUF si;
HKBD hk = 0;
static USHORT newkeyb[2];
USHORT action;
USHORT fileAttr = 0;
USHORT openAction = 0;
USHORT openMode = 0;
ULONG newsize = 0;
#if 1
printf("about to DosOpen\n");
openMode = OPEN_ACCESS_READONLY | OPEN_SHARE_DENYNONE;
openAction |= OPEN_ACTION_OPEN_IF_EXISTS;
/* tried KBD$ and CON */
/* replacement - not really equivalent of KbdOpen */
rc = DosOpen((PSZ)"KBD$",
&hk,
&action,
newsize,
fileAttr,
openAction,
openMode,
0);
newsize,
fileAttr,
openAction,
openMode,
printf("rc is %d, hk is %x\n", rc, (int)hk);
#endif
#if 0
printf("about to get input mode\n");
/* equivalent of KbdSetStatus - just for
ASCII/binary - echo not relevant */
rc = DosDevIOCtl(&bb,
NULL, /* &cd, */
0x71, /* function */
4, /* category - 4 = keyboard - not supported in FAPI */
hk); /* handle */
printf("rc is %d, bb is %x\n", rc, bb);
hk); /* handle */
#endif
#if 1
printf("about to set binary mode\n");
/* set binary mode */
bb = 0x80;
/* equivalent of KbdSetStatus - only setting
binary - echo not really relevant */
rc = DosDevIOCtl(NULL,
&bb,
0x51, /* function */
4, /* category - 4 = keyboard - not supported in FAPI */
hk); /* handle */
printf("rc is %d\n", rc);
#endif
4, /* category - 4 = keyboard - not supported in FAPI */
hk); /* handle */
printf("rc is %d\n", rc);
#if 1
printf("about to read via 4/74\n");
/* read character records */
rc = DosDevIOCtl(&cd,
&parmword,
0x74, /* function */
4, /* category - 4 = keyboard - not supported in FAPI */
hk); /* handle */
printf("rc is %d\n", rc);
&parmword,
0x74, /* function */
4, /* category - 4 = keyboard - not supported in FAPI */
hk); /* handle */
printf("rc is %d\n", rc);
printf("chchar is %x, chscan is %x\n", cd.chChar, cd.chScan);
#endif
#if 1
printf("about to set back to ASCII\n");
/* note that failure to set back to ASCII
causes subsequent DosRead to remain in
binary mode, even after this handle is closed */
bb = 0;
/* equivalent of KbdSetStatus - only setting
ASCII - echo not changed/relevant */
rc = DosDevIOCtl(NULL,
&bb,
0x51, /* function */
4, /* category - 4 = keyboard - not supported in FAPI */
hk); /* handle */
printf("rc is %d\n", rc);
#endif
4, /* category - 4 = keyboard - not supported in FAPI */
hk); /* handle */
printf("rc is %d\n", rc);
#if 1
printf("about to DosClose\n");
rc = DosClose(hk);
printf("rc is %d\n", rc);
#endif
printf("about to DosRead\n");
printf("rc %d, len %d, bytes %x %x %x\n", rc, len, data[0], data[1],
data[2]);
return 0;
}
wcl386 -bcl=os2v2 newtest.c
data[2]);
return 0;
}
#include <stdio.h>
#define INCL_DOS
#define INCL_DOSDEVICES
#define INCL_KBD
#include <os2.h>
int main(void)
{
USHORT rc;
ULONG tempRead;
USHORT parm = 1;
KBDKEYINFO cd;
ULONG datalen = 0;
unsigned char data[200];
unsigned char parmdata[200];
/* WORD */ SHORT parmword = 1;
BYTE bb = 0x80;
static KBDINFO kinfo;
static STRINGINBUF si;
HFILE hk = 0;
ULONG datalen = 0;
unsigned char data[200];
unsigned char parmdata[200];
/* WORD */ SHORT parmword = 1;
BYTE bb = 0x80;
static KBDINFO kinfo;
static STRINGINBUF si;
USHORT len = 0;
static USHORT newkeyb[2];
ULONG action;
ULONG fileAttr = 0;
ULONG openAction = 0;
ULONG openMode = 0;
ULONG newsize = 0;
ULONG datamax;
ULONG parmmax;
ULONG parmlen;
#if 1
printf("about to DosOpen\n");
openMode = OPEN_ACCESS_READONLY | OPEN_SHARE_DENYNONE;
openAction |= OPEN_ACTION_OPEN_IF_EXISTS;
/* tried KBD$ and CON */
/* replacement - not really equivalent of KbdOpen */
rc = DosOpen((PSZ)"KBD$",
&hk,
&action,
newsize,
fileAttr,
openAction,
openMode,
0);
newsize,
fileAttr,
openAction,
openMode,
printf("rc is %d, hk is %x\n", rc, (int)hk);
#endif
#if 1
printf("about to set binary mode\n");
/* set binary mode */
bb = 0x80;
/* equivalent of KbdSetStatus - only setting
binary - echo not really relevant */
rc = DosDevIOCtl(hk,
4, /* category - 4 = keyboard - not supported in FAPI */
0x51, /* function */
&bb,
1,
&parmlen,
NULL,
0,
&datalen
); /* handle */
printf("rc is %d\n", rc);
#endif
printf("rc is %d\n", rc);
#if 1
printf("about to read via 4/74\n");
/* read character records */
parmmax = sizeof parmword;
parmlen = 0;
rc = DosDevIOCtl(hk,
4, /* category - 4 = keyboard - not supported in FAPI */
0x74, /* function */
&parmword,
parmmax,
&parmlen,
&cd,
sizeof cd,
&datalen
); /* handle */
printf("rc is %d\n", rc);
printf("chchar is %x, chscan is %x\n", cd.chChar, cd.chScan);
#endif
printf("rc is %d\n", rc);
printf("chchar is %x, chscan is %x\n", cd.chChar, cd.chScan);
#if 1
printf("about to set back to ASCII\n");
/* note that failure to set back to ASCII
causes subsequent DosRead to remain in
binary mode, even after this handle is closed */
bb = 0;
datalen = 0;
/* equivalent of KbdSetStatus - only setting
ASCII - echo not changed/relevant */
rc = DosDevIOCtl(hk,
4, /* category - 4 = keyboard - not supported in FAPI */
0x51, /* function */
&bb,
1,
&parmlen,
NULL,
0,
&datalen
); /* handle */
printf("rc is %d\n", rc);
#endif
printf("rc is %d\n", rc);
#if 1
printf("about to DosClose\n");
rc = DosClose(hk);
printf("rc is %d\n", rc);
#endif
/* in a fullscreen window, this works fine.
in a normal window, dosread hangs */
printf("about to DosRead\n");
printf("rc %d, len %d, bytes %x %x %x\n", rc, tempRead, data[0],
data[1], data[2]);
return 0;
}
Any ideas?
return 0;
}
Thanks. Paul.
Paul Edwards
Dec 20, 2023, 3:24:33 AM12/20/23
to
I have some more information.
In an OS/2 window, when I get the
current input mode, it is already
set to binary!
However, I can't just leave it at
that.
I need to actually set it to binary
myself, otherwise it will give me the
old 22 error about being presentation
manager.
I'm thinking I will just make it work
in fullscreen. That should be good
enough for my purposes (running Win32
software under PDOS-generic).
BFN. Paul.
In an OS/2 window, when I get the
current input mode, it is already
set to binary!
However, I can't just leave it at
that.
I need to actually set it to binary
myself, otherwise it will give me the
old 22 error about being presentation
manager.
I'm thinking I will just make it work
in fullscreen. That should be good
enough for my purposes (running Win32
software under PDOS-generic).
BFN. Paul.
Paul Edwards
Dec 20, 2023, 7:10:55 AM12/20/23
to
I couldn't find anything further on a
web search, but using google groups
instead of google search provided some
things.
I suspect that I need to make this Win* call:
https://groups.google.com/g/comp.os.os2.programmer.misc/c/490M96gC9-8/m/5CEDiLJGC_0J
Using DosDevIOCtl functions is not sufficient if you use PM: you also
need to call WinSetKeyboardStateTable.
BYTE KeyState[257];
c = DosDevIOCtl(hf,
IOCTL_KEYBOARD,
KBD_GETSHIFTSTATE,
WinSetKeyboardStateTable(HWND_DESKTOP, KeyState, FALSE);
KeyState[VK_NUMLOCK] |= 0x01;
ss.fsState |= NUMLOCK_ON;
/* seting keyboard state */
WinSetKeyboardStateTable(HWND_DESKTOP, KeyState, TRUE);
rc = DosDevIOCtl(hf,
IOCTL_KEYBOARD,
KBD_SETSHIFTSTATE,
https://groups.google.com/g/comp.os.os2.programmer.misc/c/xb-rPCvqxfk/m/cojpJL1mEioJ
I would never have guessed that WinSetKeyboardStateTable
was needed for a VIO application. Chalk up one more thing I've
learnt today.
https://groups.google.com/g/comp.os.os2.programmer.misc/c/DNnUOfAbwG0/m/UQx_EiwbsSoJ
https://groups.google.com/g/comp.os.os2.programmer.misc/c/mihdZdxf4as/m/FVjpLDtPaXQJ
https://groups.google.com/g/comp.os.os2.programmer.misc/c/g59l-qRRrUM/m/COOAM9dtnjIJ
(and more)
I assume something similar is required for my VIO
app, but I'm changing mode rather than the keyboard
state.
Regardless - I'm reluctant to do a Win* call.
I would like this app to only be dependent on
32-bit functions in doscalls.dll.
So I'll just mark it as fullscreen for now.
BTW, I was going to post on os2world.com, but
it didn't recognize my userid and the captcha
did an infinite spin (as google groups does
when I try to post too), so I'm glad to have
a newreader to access a globally-owned service.
BTW, it looks like that "movement" already
existed, and died in the late 90s. So 20+
years later I'm just trying to do a revival!
Oh - also, the original comment about DosRead
not giving cursor keys appears to be correct
too - you use DosDevIOCtl to do the read.
That's different from both MSDOS and Unix - I
think for different reasons.
BFN. Paul.
web search, but using google groups
instead of google search provided some
things.
I suspect that I need to make this Win* call:
https://groups.google.com/g/comp.os.os2.programmer.misc/c/490M96gC9-8/m/5CEDiLJGC_0J
Using DosDevIOCtl functions is not sufficient if you use PM: you also
need to call WinSetKeyboardStateTable.
BYTE KeyState[257];
c = DosDevIOCtl(hf,
IOCTL_KEYBOARD,
KBD_GETSHIFTSTATE,
WinSetKeyboardStateTable(HWND_DESKTOP, KeyState, FALSE);
KeyState[VK_NUMLOCK] |= 0x01;
ss.fsState |= NUMLOCK_ON;
/* seting keyboard state */
WinSetKeyboardStateTable(HWND_DESKTOP, KeyState, TRUE);
rc = DosDevIOCtl(hf,
IOCTL_KEYBOARD,
KBD_SETSHIFTSTATE,
https://groups.google.com/g/comp.os.os2.programmer.misc/c/xb-rPCvqxfk/m/cojpJL1mEioJ
I would never have guessed that WinSetKeyboardStateTable
was needed for a VIO application. Chalk up one more thing I've
learnt today.
https://groups.google.com/g/comp.os.os2.programmer.misc/c/DNnUOfAbwG0/m/UQx_EiwbsSoJ
https://groups.google.com/g/comp.os.os2.programmer.misc/c/mihdZdxf4as/m/FVjpLDtPaXQJ
https://groups.google.com/g/comp.os.os2.programmer.misc/c/g59l-qRRrUM/m/COOAM9dtnjIJ
(and more)
I assume something similar is required for my VIO
app, but I'm changing mode rather than the keyboard
state.
Regardless - I'm reluctant to do a Win* call.
I would like this app to only be dependent on
32-bit functions in doscalls.dll.
So I'll just mark it as fullscreen for now.
BTW, I was going to post on os2world.com, but
it didn't recognize my userid and the captcha
did an infinite spin (as google groups does
when I try to post too), so I'm glad to have
a newreader to access a globally-owned service.
BTW, it looks like that "movement" already
existed, and died in the late 90s. So 20+
years later I'm just trying to do a revival!
Oh - also, the original comment about DosRead
not giving cursor keys appears to be correct
too - you use DosDevIOCtl to do the read.
That's different from both MSDOS and Unix - I
think for different reasons.
BFN. Paul.
0 new messages