X-Forwarded-Encrypted: i=1; AJvYcCVziZrJuup10Gzm7KVBd3UsAG1A+aonNBiXBuaLu/hZZOH/UCv0GnxRjyIe/NEa65cMSx6y95kiL2Qrk5yrB41l7EGlZ6wGJ9b5vZjHihHiMSHQonwDNnzDaibrC/kj/Q== X-Received: by 2002:a05:6214:27e2:b0:68e:fadb:b18c with SMTP id jt2-20020a05621427e200b0068efadbb18cmr117963qvb.11.1708008439245; Thu, 15 Feb 2024 06:47:19 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCV7exoArb4c2pvvI9zKIQd5w7wQ9ZaGIiRkhumJnndQOTT0Z0MBhaZHLP4UIn2nIuw7a0SYAOCLKxinxTDFjr2dyLTg5Bb0inhnVra3NMwzycX8HAi5f1qzHMYcE4E= X-Received: by 2002:a05:6830:4409:b0:6e4:323c:129 with SMTP id q9-20020a056830440900b006e4323c0129mr1679otv.6.1708008438975; Thu, 15 Feb 2024 06:47:18 -0800 (PST) Path: csiph.com!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.os.os2.programmer.misc Date: Thu, 15 Feb 2024 06:47:18 -0800 (PST) In-Reply-To: Injection-Info: google-groups.googlegroups.com; posting-host=147.161.254.174; posting-account=M0HM6QoAAADN6I0fdAn6f6_AFrdXmFjO NNTP-Posting-Host: 147.161.254.174 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <0f00a22e-65eb-4587-a626-be2f62f1b1a7n@googlegroups.com> Subject: Re: another VIO attempt From: xhajt03 Injection-Date: Thu, 15 Feb 2024 14:47:19 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 5056 Xref: csiph.com comp.os.os2.programmer.misc:1807 On February 15, 2024 at 14:28:26 +0100 Paul Edwards wrote: . . > BTW, you wrote one very long line in this newsgroup=20 > post instead of splitting it up. I have to manually=20 > split it up instead. Well, sorry. I'm responding to these Usenet messages via Google Groups (whi= ch will stop working in one week from now :-( ). I don't have any Usenet cl= ient 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 translati= on from/to the 16-bit calls, but you'd probably need to distribute those wi= th your application(s). There are multiple options for such a DLL, one of t= hem being emxwrap.dll (part of the EMX runtime, already available on many O= S/2 installations), but there are others (see e.g. https://hobbes.nmsu.edu/= ?detail=3D%2Fpub%2Fos2%2Fdev%2Ftools%2Ftoolkits%2FUniConAPI_1-0-3.zip). > > Yes, you cannot treat the keyboard as a file in that=20 > > case (i.e. you cannot use DosRead for retrieving the=20 > > keys, etc.), but that is comparable to BIOS functions=20 > > needed under plain DOS. > You don't need to use the BIOS functions in plain DOS=20 > to do the above. Well, yes, you can access the modifiers by accessing the low part of the me= mory (modified by BIOS) there. ;-) . . > > And, obviously, the KbdCalls functions work both in=20 > > full-screen and in VIO windows (except for minor=20 > > documented exceptions which shouldn't be necessary=20 > > for your purposes as far as I understand them). > And I believe IBM intended that the 32-bit functions=20 > they provided would be sufficient to do the job=20 > instead. And it just didn't happen much for other=20 > reasons.=20 Not really, because they clearly documented a different solution (in partic= ular 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 K= bdCalls kind of suggests that they didn't consider other solutions as direc= tly replacing this DLL. Not that it matters much nowadays. ;-) > And note that the functions they provided *do* do=20 > the job in 32-bit. It's only when the program=20 > terminates that I find I have an issue.=20 >=20 > 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 ef= ficient solution. > BTW, I'm not familiar with privilege levels in OS/2,=20 > but I haven't done anything to attempt to get into=20 > 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 rig= ht flag in the respective executable header). > It could be that the accessing of KBD$ is throwing=20 > 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.=20 See above. > Maybe there's no security in OS/2 - I've never=20 > asked the question.=20 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