Groups | Search | Server Info | Login | Register

Groups > comp.os.os2.programmer.misc > #1807

Re: another VIO attempt

Show key headers only | View raw

On February 15, 2024 at 14:28:26 +0100 Paul Edwards wrote:

 .
 .
> BTW, you wrote one very long line in this newsgroup 
> post instead of splitting it up. I have to manually 
> split it up instead.

Well, sorry. I'm responding to these Usenet messages via Google Groups (which will stop working in one week from now :-( ). I don't have any Usenet client installed.


 .
 .
> I want to have a pure 32-bit executable.

I see. You can have that if you use a 3rd party DLL providing the translation from/to the 16-bit calls, but you'd probably need to distribute those with your application(s). There are multiple options for such a DLL, one of them being emxwrap.dll (part of the EMX runtime, already available on many OS/2 installations), but there are others (see e.g. https://hobbes.nmsu.edu/?detail=%2Fpub%2Fos2%2Fdev%2Ftools%2Ftoolkits%2FUniConAPI_1-0-3.zip).


> > Yes, you cannot treat the keyboard as a file in that 
> > case (i.e. you cannot use DosRead for retrieving the 
> > keys, etc.), but that is comparable to BIOS functions 
> > needed under plain DOS.
> You don't need to use the BIOS functions in plain DOS 
> to do the above.

Well, yes, you can access the modifiers by accessing the low part of the memory (modified by BIOS) there. ;-)


 .
 .
> > And, obviously, the KbdCalls functions work both in 
> > full-screen and in VIO windows (except for minor 
> > documented exceptions which shouldn't be necessary 
> > for your purposes as far as I understand them).
> And I believe IBM intended that the 32-bit functions 
> they provided would be sufficient to do the job 
> instead. And it just didn't happen much for other 
> reasons. 

Not really, because they clearly documented a different solution (in particular using KbdCalls) as intended for scenarios described by you. Also, the fact that the (beta) PowerPC version of OS/2 included a 32-bit version of KbdCalls kind of suggests that they didn't consider other solutions as directly replacing this DLL. Not that it matters much nowadays. ;-)


> And note that the functions they provided *do* do 
> the job in 32-bit. It's only when the program 
> terminates that I find I have an issue. 
> 
> So they come very very close to working.

OK. Even if you get it fully working, it doesn't mean that it's the most efficient solution.


> BTW, I'm not familiar with privilege levels in OS/2, 
> but I haven't done anything to attempt to get into 
> any sort of privileged mode.

Accessing the 16-bit calls requires the specific binary (e.g. a DLL) to be marked for privilege level 2 (IOPL), but you don't need to bother with that when using a translation library like one of those mentioned above (and it doesn't mean much for you otherwise except for a necessity to have the right flag in the respective executable header).


> It could be that the accessing of KBD$ is throwing 
> me into a privileged state regardless.

The device driver works at a higher privilege level, but the code accessing the logical device (e.g. KBD$) doesn't.


> But maybe the 16-bit Kbd* functions do that too. 

See above.


> Maybe there's no security in OS/2 - I've never 
> asked the question. 

If you refer to privilege levels specifically, these are for sure enforced in OS/2. Talking about OS/2 security in other contexts would go beyond the scope of this thread considerably.

Tomas

Back to comp.os.os2.programmer.misc | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

another VIO attempt Paul Edwards <mutazilah@gmail.com> - 2024-02-15 13:13 +0800
  Re: another VIO attempt xhajt03 <xhajt03@gmail.com> - 2024-02-15 04:16 -0800
    Re: another VIO attempt Paul Edwards <mutazilah@gmail.com> - 2024-02-15 21:28 +0800
      Re: another VIO attempt xhajt03 <xhajt03@gmail.com> - 2024-02-15 06:47 -0800
        Re: another VIO attempt Paul Edwards <mutazilah@gmail.com> - 2024-02-15 23:23 +0800
          Re: another VIO attempt xhajt03 <xhajt03@gmail.com> - 2024-02-15 09:07 -0800
            Re: another VIO attempt Dave Yeo <dave.r.yeo@gmail.com> - 2024-02-15 17:13 -0800
          Re: another VIO attempt Paul Edwards <mutazilah@gmail.com> - 2024-02-17 16:58 +0800
            Re: another VIO attempt Paul Edwards <mutazilah@gmail.com> - 2024-02-17 18:09 +0800
      Re: another VIO attempt Dave Yeo <dave.r.yeo@gmail.com> - 2024-02-15 17:38 -0800
        Re: another VIO attempt Paul Edwards <mutazilah@gmail.com> - 2024-02-16 16:17 +0800
          Re: another VIO attempt Dave Yeo <dave.r.yeo@gmail.com> - 2024-02-16 15:05 -0800
            Re: another VIO attempt Paul Edwards <mutazilah@gmail.com> - 2024-02-17 09:44 +0800
              Re: another VIO attempt Dave Yeo <dave.r.yeo@gmail.com> - 2024-02-17 15:47 -0800
                Re: another VIO attempt Paul Edwards <mutazilah@gmail.com> - 2024-02-18 09:48 +0800

csiph-web