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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

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
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).

Crikey. I thought that OS/2 2.0 had done a total switch to 32-bit.

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, July 15, 2023 at 7:02:14 UTC+2, Paul Edwards wrote:
.
.

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.

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. ;-----;;;;;;;

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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".


.
.

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...

Then I had the idea that maybe I'm not supposed to be using
the Physical Device Driver Reference and I should instead be

Indeed. ;-)

using either the Virtual Device or Presentation.

Not PM if you intend to use it in a console program (rather than changing your application to a GUI)...

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.

Yes.

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).

Tomas

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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:

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)

commands valid for the OS/2 and DOS/4G Systems executable formats only:

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.

This is not necessarily simple though. It's intended to be part
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 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);
printf("about to do dosread of %d\n", (int)stream->hfile);
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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, July 16, 2023 at 2:17:12 PM UTC+8, Paul Edwards wrote:

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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:

.
.

http://www.edm2.com/index.php/CPGuide_-_Control_Program_Functions

Yes, edm2.com is a reasonable source.

.
.

Sounds like windows(VIO) = "PMCompatible".

Yes.

And regardless, "fullscreen" is surely the opposite of "PM session".

Indeed.

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 console drivers (i.e. keyboard, console video and mouse) _are_ 16-bit and the same applies to the API for working with
them as you already found yourself. And yes, this is what all other OS/2 console applications do unless they use some wrapper DLL (which just wrap around the same 16-bit API functions with 32-bit versions). Just FYI, I'm a maintainer of the OS/2 version
of the Free Pascal compiler (FPC) and the same functions (rather than some device drivers controlling API) are used for the FPC run-time library (actually, we still use the emxwrap.dll wrapper, but that makes no difference as already mentioned above).

Tomas

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.
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?

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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...

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?

Sure, regular applications should be able to use DosDevIOCtl for controling I/O aspects. Not for performing I/O though, which is what you try to do.

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.

Yes, but none of these systems expect developers to use IOCTL for reading keys pressed on the keyboard.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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
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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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
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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

That works under OS/2?

Is it allowed to be installed on OS/2? Or is it native?

To be exact, Winos2, basically Windows 3.1. Up till Win32s 1.25, it
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).

It may well work on WinOS2, and depending on your VGA BIOS, may run in a
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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Win32s 1.25 is here, https://hobbes.nmsu.edu/?path=%2Fpub%2Fwindows%2Fsystem%2Fwin32s
Hobbes has a lot of OS/2 software.
Dave

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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
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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, July 17, 2023 at 2:11:30 PM UTC+8, Dave Yeo wrote:

Win32s 1.25 is here, https://hobbes.nmsu.edu/?path=%2Fpub%2Fwindows%2Fsystem%2Fwin32s
Hobbes has a lot of OS/2 software.

Thanks for that!

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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
to run "pe" for any program being executed.

BFN. Paul.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)