Groups | Search | Server Info | Login | Register

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

Re: inoperative keyboard - analysis required

Show all headers | View raw

On 03/03/24 11:04, Dave Yeo wrote:

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

Yeah - and I wish to challenge that entire concept
that you "need" anywhere near 2 GB "today".

PDOS/386 can be put on a 360k floppy (or close).

And it has a 2.5 MB memory requirement just to start.
I can work on trimming that down, but it's fairly
pointless as I wish to run a fork of gcc 3.2.3 anyway,
and that requires something like 32 MB or 64 MB when
given a reasonable task (like getting it to recompile
itself with full optimization).

It has taken me 3 decades to get here. A lot of that
time was spent on the IBM mainframe where I was trying
to get things working too. I was chided by many people
for "my" program (gcc 3.2.3) needing more than the
16 MiB limit of the (older) S/370 IBM mainframe.

I think it is unreasonable to require programs to fit
into 16 MiB (minus overhead of maybe 6 MiB), but others
disagree.

However, I do agree that going a long way above 16 MiB,
even coming close to 2 GiB (a different mainframe limit),
is ridiculous.

And that if you need that much memory, it's more likely
that you are doing something wrong. And 64-bit is
unnecessary for the same reason. Which means that OS/2
should be perfectly fine for the job. Indeed - 512 MiB
should be perfectly fine.

wlink will similarly be replaced, in this case by the
public domain and supported pdld.

Today I am going to be looking at gccwin (my fork of
gcc 3.2.3) to see if I can add the "_System" keyword
to support the OS/2 API calls. Otherwise we should be
able to work around the issue elsewhere.

I believe that will be a much more viable toolchain.

For me at least. Because that's another rationalization
I would like to do - sticking with fullscreen text.
Note that blind people can only "see" text, and that's
a "lowest common denominator" that I'd like to target.

But yeah - nearly everyone else has a different interest.
And that would nominally be fine. But it ends up with
code that is not understood and not maintainable, and
you end up with:

https://www.quora.com/Why-did-you-leave-software-engineering/answer/Jeff-Sturm-2

"The inmates are truly running the asylum, as the saying goes"

I wish to challenge that "leadership".

If I treat Linux as a glorified BIOS, a 53k executable
gives me a mini OS/2 clone, a mini Win32 clone, and it
also runs the flagship PDOS-generic apps.

It took 30 years to create something that is conceptually
simple and somewhat obvious in hindsight.

I say "somewhat" because it is not that obvious that you
can run different APIs with a single C library, and I
sometimes need to look into the code to answer "how on
earth does this work?".

And all sitting ready for anyone at all to commercially exploit.

BFN. Paul.

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