Groups | Search | Server Info | Login | Register

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

Re: inoperative keyboard - analysis required

Show all headers | View raw

Paul Edwards wrote:
>
>>> Not being high memory safe doesn't make it a 16-bit
>>> function. That would make DosOpen 16-bit by the same
>>> logic. After all that effort IBM made to provide a
>>> 32-bit version of DosOpen (noting that the 16-bit
>>> version still exists too).
>>>
>>> Am I using the wrong terminology?
>>
>> I thought the 32 bit version was basically a wrapper around the 16 bit
>> version.
>
> Oh - I don't care what happens beyond my
> executable. And if the price is that I can't
> use high memory - I don't particularly care
> about that either.
>
> So it may be a terminology issue.
>
> So what is the correct terminology to say that
> I am linking with pure 32-bit DLL exports, no
> thunking involved, and I don't care what OS/2
> does internally as it is none of my business,
> nor do I care, and I don't have any direct insight
> into OS/2 internals anyway.
>

Good question. I think of the 16 bit API where you have to thunk and 
consider segment size etc, while you don't with the 32 bit API.
Strictly speaking some of the DLL's, including the kernel which presents 
as a DLL, doscalls, are internally 16 bit while having a 32 bit API.

>>> which appears to reject my userid, and when I ask
>>> for my userid to be sent to my email, it hangs on
>>> the captcha verification (possibly because I am
>>> in the Philippines), after I click to say I am
>>> not a robot.
>>
>> Using Firefox 45?
>
> No. "Edge" that comes with Windows 10.
>
> Even using mainstream things, everything is broken.

Apparently so.

>
> That's why I am interested in supported software
> (ArcaOS), and, if you want open source, then I have
> a simple system instead (PDOS/386 is pretty simple),
> that can actually be understood and maintained.

Problem is software has gotten big. The browsers for example push the 
limits on our 32 bit system. I've seen g++ use 2 GB's to compile one C++ 
file and then the linker (wlink) fail without the full address range 
available
VIRTUALADDRESSLIMIT=3072 in config.sys. Only works on some systems as 
PCI space may conflict. IBM didn't seem to finish the high memory support.
Dave

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

Thread

inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-02 03:06 +0800
  Re: inoperative keyboard - analysis required Dave Yeo <dave.r.yeo@gmail.com> - 2024-03-01 15:57 -0800
    Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-02 09:17 +0800
      Re: inoperative keyboard - analysis required Dave Yeo <dave.r.yeo@gmail.com> - 2024-03-01 22:37 -0800
        Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-02 15:08 +0800
          Re: inoperative keyboard - analysis required Dave Yeo <dave.r.yeo@gmail.com> - 2024-03-02 19:04 -0800
            Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-03 12:34 +0800
              Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-03 13:42 +0800
                Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-04 18:47 +0800
    Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-02 10:48 +0800
      Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-02 10:54 +0800
        Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-02 11:43 +0800
          Re: inoperative keyboard - analysis required Dave Yeo <dave.r.yeo@gmail.com> - 2024-03-01 23:22 -0800
            Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-02 16:05 +0800
              Re: inoperative keyboard - analysis required Dave Yeo <dave.r.yeo@gmail.com> - 2024-03-02 19:07 -0800
      Re: inoperative keyboard - analysis required Dave Yeo <dave.r.yeo@gmail.com> - 2024-03-01 22:42 -0800

csiph-web