pdos nominally stable

[muta...@gmail.com]

About a day ago, I fixed the last known, reproducible
integrity bug, so PDOS is now nominally stable.

And as a result, the tools, including GCC 3.2.3, can be
rebuilt under PDOS/386.

I've also included a nominally commercial product of
mine on it (capitalg).

If anyone has something they would like to sell that
they would like included on the PDOS distribution,
I might be able to add it.

BFN. Paul.

[Kerr-Mudd, John]

On Tue, 6 Dec 2022 05:40:09 -0800 (PST)
"muta...@gmail.com" <muta...@gmail.com> wrote:

> About a day ago, I fixed the last known, reproducible
> integrity bug, so PDOS is now nominally stable.
>
> And as a result, the tools, including GCC 3.2.3, can be
> rebuilt under PDOS/386.

Well at least it's not restricted by GPL

>
> I've also included a nominally commercial product of
> mine on it (capitalg).

Ah.

>
> If anyone has something they would like to sell that
> they would like included on the PDOS distribution,
> I might be able to add it.
>

--
Bah, and indeed Humbug.

[muta...@gmail.com]

On Wednesday, December 7, 2022 at 12:29:22 AM UTC+8, Kerr-Mudd, John wrote:

> > About a day ago, I fixed the last known, reproducible
> > integrity bug, so PDOS is now nominally stable.
> >
> > And as a result, the tools, including GCC 3.2.3, can be
> > rebuilt under PDOS/386.

> Well at least it's not restricted by GPL

Pardon?

> > I've also included a nominally commercial product of
> > mine on it (capitalg).

> Ah.

Ah what?

BFN. Paul.

[Joe Monk]

> > > And as a result, the tools, including GCC 3.2.3, can be
> > > rebuilt under PDOS/386.
>
> > Well at least it's not restricted by GPL
> Pardon?

GCC 3.2.3 is GPL code that you are copying/redistributing.

https://gcc.gnu.org/onlinedocs/gcc-3.2.3/gcc/Copying.html#Copying

Joe

[Kerr-Mudd, John]

Sorry, I was being sarcastic; it doesn't come across well!

I thought 'muta...@gmail.com''s quest was for totally PD code, so seeing
GCC in the mix )plus his? potentially commercial (app?) is a bit strange.

[Joe Monk]

> Sorry, I was being sarcastic; it doesn't come across well!
>
> I thought 'muta...@gmail.com''s quest was for totally PD code, so seeing
> GCC in the mix )plus his? potentially commercial (app?) is a bit strange.
> --

I know, that's why I put that GCC is copyrighted / GPL! I dont think he has 100% grasped that yet... :)

Joe

[muta...@gmail.com]

On Wednesday, December 7, 2022 at 5:00:09 AM UTC+8, Kerr-Mudd, John wrote:

> > > > > And as a result, the tools, including GCC 3.2.3, can be
> > > > > rebuilt under PDOS/386.
> > >
> > > > Well at least it's not restricted by GPL

> > > Pardon?

> I thought 'muta...@gmail.com''s quest was for totally PD code, so seeing
> GCC in the mix )plus his? potentially commercial (app?) is a bit strange.

The OS and C library are completely public domain.

Currently there aren't any good options to replace
some of the copyrighted tools like GCC.

What is wrong with including a commercial product
as part of the distribution too?

You can delete any of those things and still have a
system. In fact, the UC386 distribution does indeed
only have public domain code.

But with only public domain tools available, you can't
immediately build the OS if you wish to make a change.
You will first have a requirement to improve the
bundled C compiler that is only a subset of C90.

What alternative do you suggest? Especially to warrant
sarcasm about a product that has been under development
for nearly 30 years. You would have whipped it up over a
weekend? But the dog ate your keyboard the weekend you
were about to do that?

BTW, Jean-Marc, who used to participate here, and even
mentioned a public domain C compiler here, is working on
SubC at the moment. Hopefully, after literally 50 years, the
public will own a C90-compliant compiler soon.

BFN. Paul.

[Joe Monk]

> What alternative do you suggest? Especially to warrant
> sarcasm about a product that has been under development
> for nearly 30 years. You would have whipped it up over a
> weekend? But the dog ate your keyboard the weekend you
> were about to do that?
>

There's literally already c standard libraries that are public domain. There's public domain c compilers.

https://sourceforge.net/projects/pdclib/
https://github.com/DevSolar/pdclib

https://github.com/ncb85/SmallC-85

Joe

[muta...@gmail.com]

pdpclib both predated and inspired pdclib, so I don't
know what you mean by "already". It would be better
to put it the other way around. And why did you
even bring up the C library? I distribute a public domain
C library. It works. What's the issue?

Also I think you'll find that his doesn't support the mainframe.

> https://github.com/ncb85/SmallC-85

That's yet another subset of C90:

Small C is a public domain compiler for a subset of C. The main things
lacking are "#if", structs/unions, doubles/floats/longs and more than
one level of indirection.

SubC is more advanced than that.

So once again, I fail to see what point either of you are making.

Especially a point that involves sarcasm.

BFN. Paul.

[Joe Monk]

> So once again, I fail to see what point either of you are making.
>
> Especially a point that involves sarcasm.
>

https://www.youtube.com/watch?v=jlRAnO1GR0U

Joe

[muta...@gmail.com]

Ok, so you're making fun of the fact that I'm producing
a 32-bit OS?

I watched the whole video, and he says himself that
32-bit is still available for longer on x64.

But regardless, what's the issue? Are you saying that
people want to run PDOS, but only if it is 64-bit?

If not, what difference does it make whether PDOS is
32-bit or 64-bit?

And is there a reason why these non-existent people
can't run PDOS under something like Virtualbox under
Windows or Linux?

What are either of you trying to achieve?

Also, z/PDOS can run on 64-bit hardware in 64-bit mode.
It doesn't need a special 32-bit mode. Even if Intel and
AMD deliberately kill off all 32-bit possibilities, I can just
switch to running on a mainframe.

Quite apart from the fact that PDOS is written in C, and
with a 64-bit C compiler, most of the work of switching
to 64-bit will be done automatically.

But I see no reason to bother with 64-bit at the moment.
I still haven't done everything I want to do on 32-bit. And
the biggest task I do on PDOS/386 - getting GCC to
recompile itself - only requires 39 MB, which is less than
the 64 MB max that PDOS/386 currently provides apps
with.

So, the point of the sarcasm is what?

BFN. Paul.

[Joe Monk]

> Also, z/PDOS can run on 64-bit hardware in 64-bit mode.

Prove it. On real hardware, not Hercules.

Joe

[muta...@gmail.com]

On Wednesday, December 7, 2022 at 10:29:43 PM UTC+8, Joe Monk wrote:

> > Also, z/PDOS can run on 64-bit hardware in 64-bit mode.

> Prove it. On real hardware, not Hercules.

I don't have access to real hardware, and even on real
hardware it would still need to run under z/VM because
I do CCWs to terminals that are unlikely to exist on bare
metal.

BFN. Paul.

[muta...@gmail.com]

On Wednesday, December 7, 2022 at 10:50:31 PM UTC+8, muta...@gmail.com wrote:

> I don't have access to real hardware, and even on real
> hardware it would still need to run under z/VM because
> I do CCWs to terminals that are unlikely to exist on bare
> metal.

Also, the difficulty of getting access to read hardware
is the advantage of using Hercules in the first place.

What's wrong with Hercules?

BFN. Paul.

[Joe Monk]

> What's wrong with Hercules?
>

Hercules is an architecture emulator, not a hardware emulator. The way hercules behaves and the way the real hardware behaves can be two different things.

Example: Hercules cannot IPL any OS that requires CZAM, because hercules cannot currently do CZAM.

Joe

[Joe Monk]

> because
> I do CCWs to terminals that are unlikely to exist on bare
> metal.

On z/ARCH, you dont run on bare metal. You always run LPAR.

Joe

[muta...@gmail.com]

On Thursday, December 8, 2022 at 5:29:05 AM UTC+8, Joe Monk wrote:

> Hercules is an architecture emulator, not a hardware emulator.
> The way hercules behaves and the way the real hardware
> behaves can be two different things.

So? If it works, what's the issue?

> Example: Hercules cannot IPL any OS that requires CZAM,
> because hercules cannot currently do CZAM.

So? The problem in question was whether z/PDOS could
run on real hardware. If it only runs under z/VM on real
hardware, and that can't even be tested because I don't
have access to real z/VM on real hardware, who cares?

It can be demonstrated working on Hercules, and Hercules
is what is needed because of the exact problem above.

Ok, you can replace it with whatever wording differentiates
being run on non-z/VM and running under z/VM, and neither
of them actually being proven because of the difficulty of
accessing mainframe hardware.

BTW, I'm not sure if this conversation triggered it, but I
realized that circumstances have changed, and I now
have the ability to create a 32-bit EFI 386 executable,
and I'm curious about 64-bit EFI x64 executable, to
create the start of a BIOS, so I'm going to reinstall
Zorin on my Chromebook so that hopefully I get a 64-bit
gcc back, and then I'm going to see what it does with my
gcc and binutils, which both mention x64 despite their age.

BFN. Paul.

[anti...@math.uni.wroc.pl]

For your use gcc-3.2.3 is probably good enough (IIRC for some
time it was system compiler of some 64-bit Linux distributions).
But it was one of first versions supporting x86_64 and there
were considerable fixes and improvements in 3.3 and 3.4.
I have 3.4.6 on my machine and it works well. I think it
would make sense for you to move to 3.4.6. 4.0 introduce
large changes and in general as you move towards current
versions gcc gets bigger and needs more memory, so you
may decide that this is too much for you.

--
Waldek Hebisch

[muta...@gmail.com]

On Thursday, December 8, 2022 at 8:46:43 AM UTC+8, anti...@math.uni.wroc.pl wrote:

> For your use gcc-3.2.3 is probably good enough (IIRC for some
> time it was system compiler of some 64-bit Linux distributions).
> But it was one of first versions supporting x86_64 and there
> were considerable fixes and improvements in 3.3 and 3.4.
> I have 3.4.6 on my machine and it works well. I think it
> would make sense for you to move to 3.4.6. 4.0 introduce
> large changes and in general as you move towards current
> versions gcc gets bigger and needs more memory, so you
> may decide that this is too much for you.

Ok, thanks for reminding me that I have 3.4.6 available too.

I abandoned 3.4.6 when it had i370 bugs that couldn't be
resolved, and also because it was larger and defeated a
kludge I had in place for z/PDOS.

But it may well work fine for x86_64.

However, in another "this wouldn't have happened on PDOS"
moment, my x64 Chromebook, which boots PDOS fine, has
failed to boot Zorin. I got a error message about some sort
of interrupt not working, switching to polling, and that's all.

So now I still don't have a 64-bit compiler available. I was
wondering whether I should download mingw64 instead.

Actually, I wonder what happens if I try to build x86_64
using my 32-bit gccwin? Is it technically possible to build
a 64-bit compiler using a 32-bit compiler? I'll see what happens.

BFN. Paul.