Recent Posts

Pages: [1] 2 3 ... 10
1
Programming / Re: DosDevIOCtl disabling keyboard in VIO mode
« Last post by kerravon on March 04, 2024, 10:58:06 am »
But I also do not understand why you would be dogmatic about using 32-bit only.
Firstly from a technical cleanliness perspective. I thought that OS/2 2.0 was about upgrading to 32-bit. 30 years later and I'm still required to deal with 16-bit? Not what I want to do. Especially not for one problematic function (DosDevIOCtl) that would force me into 16-bit. I'd rather be forced into fullscreen.

Secondly, the pure 32-bit allows me to write a mini-clone of OS/2 either as an app that runs under another OS (e.g. UC386L that runs under Linux) or as a standalone OS (PDOS/386). Both available from http://pdos.org - new version that implements DosDevIOCtl uploaded a couple of minutes ago.

Note that "mini clone" means that it runs *certain* OS/2 executables - basically just the ones that were built with PDPCLIB (see makefile.wat). So anything that is C90-compliant, or uses ANSI x3.64 "extensions" and has been built with PDPCLIB or equivalent (I doubt that there is anything equivalent currently, but there is no barrier to that).

Quote
OS/2 has a strong 16-bit heritage, that's just the way it is.
And it doesn't need to be. With proper funding, OS/2 could be stripped internally of any 16-bit vestiges that affect a pure 32-bit application. As well as being a commercial competitor to Windows (note that I am similarly able to convert OS/2 into a mini Win32 clone with the use of win32os2 at pdos.org using the same technique). And yes, I know that Odin for OS/2 and Linux WINE are nominally superior (but neither are what I want).

So anyway, I want to be able to build a 32-bit OS/2 binary today, that runs on all those environments. And even if I lose the source code, the binary remains pure as better OS/2 clones come online.

And I don't consider 64-bit to be necessary either. Meaning OS/2 is perfectly viable. When I was doing some work on the mainframe, I was being chided for "my" program (a fork of gcc 3.2.3) requiring more than 16 MiB of memory, thus breaking the S/370 architectural limit). Personally I disagree that using more than 16 MiB is illegitimate and that I need to "fix" "my" "broken" program. But requiring 2 GiB or even more is beyond ridiculous. And yes, I know the mainframe has been updated (z/OS) to allow programmers to be ridiculous with 64-bit. But it's not a wagon I want to be on.

BTW, we're expecting the PDOS toolchain to be able to target OS/2 soon. It's down to just the linker (pdld) now, and it is being actively worked on. It can produce LX executables already, but not yet resolve DLL references. Likely day(s) away from working. Windows is already done. ie a self-hosting mini Win32 clone. You could potentially call it a self-hosting mini OS/2 clone already, but it's not doing that with OS/2 executables (it could though), or the ability to reproduce those OS/2 executables (that's what's missing currently).
2
Programming / Re: DosDevIOCtl disabling keyboard in VIO mode
« Last post by kerravon on March 04, 2024, 10:11:55 am »
I've never had the slightest interest in writing a true text-mode app, so I have no hand-on experience.

Whereas I am *only* interested in text mode programs - either line mode thus can conform to ANSI X3.159-1989 or fullscreen mode (need ANSI X3.64 also).

As opposed to using APIs that haven't been standardized for whatever reason.

I'm also interested in catering for what I see as the "lowest common denominator" - blind people - who can only "see" text.

I spent some effort trying to cater for deafblind too, in the third world too where Braille readers are prohibitively expensive, but there are other reasons to stop at just blind (ie 95% or something of deafblind people have other issues that made them deafblind in the first place).

Also I am mainly interested in catering to fellow programmers - including budding third world programmers who can only afford a smartphone (I have a native ARM equivalent of Bochs running MSDOS using an external keyboard for US$2).

Quote
However, perusing the 'Control Program Reference', I found KbdSetStatus(pkbdinfo, hkbd)

Isn't this what you're looking for? (I _assume_ this is a 32-bit entry point to a 16-bit function.)

No, the APIENTRY16 shows that it is 16-bit and being auto-thunked:

D:\watcom\h\os2>grep KbdSetStatus *
bsesub.h: #define KbdSetStatus     KBD16SETSTATUS
bsesub.h: USHORT APIENTRY16 KbdSetStatus(PKBDINFO,HKBD);

D:\watcom\h\os2>
3
Applications / Re: XWP v1.0.16
« Last post by Roderick Klein on March 04, 2024, 09:52:38 am »
Hello

What do you think it is needed for lSwitcher to also respect the XWP font sizes too?

I opened a ticket in case Gregg Young wants to take a look at it.
- http://trac.netlabs.org/lswitcher/ticket/81

Regards

Gregg is on vacation right now.  He is aware of this ISwitcher issue. He mentioned this issue at Warpstock.

Roderick
4
Programming / Re: DosDevIOCtl disabling keyboard in VIO mode
« Last post by Lars on March 04, 2024, 08:56:24 am »
The "Kbd", "Mou" and "Vio" functions have no 32-bit thunking function, the compiler will need to provide the thunk (as the VAC compiler and Watcom compilers will do if the 16-bit function is properly declared as such).
But I also do not understand why you would be dogmatic about using 32-bit only. OS/2 has a strong 16-bit heritage, that's just the way it is.
5
Programming / Re: DosDevIOCtl disabling keyboard in VIO mode
« Last post by Rich Walsh on March 04, 2024, 06:46:11 am »
Quote
What are you trying to do?
I am trying to switch off echo and line buffering so that I can write a fullscreen text application, like microemacs 3.6. As a pure 32-bit app (no thunking within my executable). As such - OS/2 should not do keyboard character echoing. The application will deal with that.

I've never had the slightest interest in writing a true text-mode app, so I have no hand-on experience. However, perusing the 'Control Program Reference', I found KbdSetStatus(pkbdinfo, hkbd). The description of the KBDINFO structure's "fsMask" member lists these flags:

Code: [Select]
fsMask (USHORT)
State mask.

  Bits 15-9 Reserved.
  Bit 8 Shift return is on.
  Bit 7 Length of the turn-around character (meaningful only if bit 6 is on).
  Bit 6 Turn-around character is modified.
  Bit 5 Interim character flags are modified.
  Bit 4 Shift state is modified.
  Bit 3 ASCII mode is on.
  Bit 2 Binary mode is on.
  Bit 1 Echo off.
  Bit 0 Echo on.

Isn't this what you're looking for? (I _assume_ this is a 32-bit entry point to a 16-bit function.)
6
Applications / Re: XWP v1.0.16
« Last post by Rich Walsh on March 04, 2024, 05:30:04 am »
Query os2.ini->PM_SystemFonts->WindowText to get the font name & size, then use it.

Which specific lswitch282.ini key are we talking about here?

I have no idea. I was simply identifying how you get the current general-purpose font from os2.ini. How lswitcher uses it is up to Gregg...
7
Applications / Re: General Software Testing
« Last post by Martin Iturbide on March 03, 2024, 11:03:11 pm »
Thanks Dave
8
Applications / Re: XWP v1.0.16
« Last post by Dariusz Piatkowski on March 03, 2024, 08:23:02 pm »
Rich & Martin,

Query os2.ini->PM_SystemFonts->WindowText to get the font name & size, then use it.

Which specific lswitch282.ini key are we talking about here?

I see the following:

1) TitleFont
2) ButtonFont (which I suspect is the TaskBar button)
3) HintsFont

...haven't tried any of them yet as none seem to imply the PopUp font control, which is what I'm interested in changing (b/c the TaskBar seems to be just fine).
9
Applications / Re: XWP v1.0.16
« Last post by Rich Walsh on March 03, 2024, 07:26:08 pm »
What do you think it is needed for lSwitcher to also respect the XWP font sizes too?

Query os2.ini->PM_SystemFonts->WindowText to get the font name & size, then use it.
10
Applications / Re: XWP v1.0.16
« Last post by Martin Iturbide on March 03, 2024, 03:50:38 pm »
Hello

What do you think it is needed for lSwitcher to also respect the XWP font sizes too?

I opened a ticket in case Gregg Young wants to take a look at it.
- http://trac.netlabs.org/lswitcher/ticket/81

Regards
Pages: [1] 2 3 ... 10