I have created a purely public domain hard disk image
which allows you to build programs in a subset of C90
(SubC). All the necessary supporting components (OS,
linker etc) are available.

The hard disk image is 40 MB but only 9 MB is used.

See "University Challenge" at http://pdos.org

BFN. Paul.

"muta...@gmail.com" <mutazilah@gmail.com> writes:
>I have created a purely public domain hard disk image
>which allows you to build programs in a subset of C90
>(SubC). All the necessary supporting components (OS,
>linker etc) are available.
>
>The hard disk image is 40 MB but only 9 MB is used.
>
>See "University Challenge" at http://pdos.org
>

What he doesn't tell you is that it is a very crippled
version of MS-DOS.

"muta...@gmail.com" <mutazilah@gmail.com> writes:

> I have created a purely public domain hard disk image
> which allows you to build programs in a subset of C90
> (SubC). All the necessary supporting components (OS,
> linker etc) are available.

Why?

--
Ben.

On Monday, March 21, 2022 at 5:09:03 AM UTC+11, Scott Lurndal wrote:

> What he doesn't tell you is that it is a very crippled
> version of MS-DOS.

Which is the limits of what the public actually owns.
Previously the public had to either zap machine code
one byte at a time, or use someone else's copyrighted
code.

BFN. Paul.

On Monday, March 21, 2022 at 6:22:43 AM UTC+11, Ben Bacarisse wrote:

> > I have created a purely public domain hard disk image
> > which allows you to build programs in a subset of C90
> > (SubC). All the necessary supporting components (OS,
> > linker etc) are available.

> Why?

I'd rather ask why everyone else is determined to keep all
code related to development copyrighted. Very few people
are willing to release their code to the public domain. Even
today we still don't have C90 compliance. SubC is close
enough to be useful, but still not C90-compliant.

BFN. Paul.

muta...@gmail.com <mutazilah@gmail.com> wrote:
> On Monday, March 21, 2022 at 6:22:43 AM UTC+11, Ben Bacarisse wrote:

>> > I have created a purely public domain hard disk image
>> > which allows you to build programs in a subset of C90
>> > (SubC). All the necessary supporting components (OS,
>> > linker etc) are available.

>> Why?

> I'd rather ask why everyone else is determined to keep all
> code related to development copyrighted. Very few people
> are willing to release their code to the public domain. Even
> today we still don't have C90 compliance. SubC is close
> enough to be useful, but still not C90-compliant.

I can answer part of that question. Free software is copyright so that
it can remain free. Public domain code can be incorporated into
anybody's copyright-restricted product at will, not a good thing from
the point of view of those who promote free software. Of course, the
same is true of some "free" licenses, too. Things are complicated.

Now it's your turn! Given the previous paragraph, why do you want to
create a public domain C?

> BFN. Paul.

--
Alan Mackenzie (Nuremberg, Germany).

"muta...@gmail.com" <mutazilah@gmail.com> writes:

> On Monday, March 21, 2022 at 6:22:43 AM UTC+11, Ben Bacarisse wrote:
>
>> > I have created a purely public domain hard disk image
>> > which allows you to build programs in a subset of C90
>> > (SubC). All the necessary supporting components (OS,
>> > linker etc) are available.
>
>> Why?
>
> I'd rather ask why everyone else is determined to keep all
> code related to development copyrighted. Very few people
> are willing to release their code to the public domain. Even
> today we still don't have C90 compliance. SubC is close
> enough to be useful, but still not C90-compliant.

Just thought I'd ask. You don't owe me an explanation.

--
Ben.

On Monday, March 21, 2022 at 8:35:57 AM UTC+11, Alan Mackenzie wrote:

> >> > I have created a purely public domain hard disk image
> >> > which allows you to build programs in a subset of C90
> >> > (SubC). All the necessary supporting components (OS,
> >> > linker etc) are available.
>
> >> Why?
>
> > I'd rather ask why everyone else is determined to keep all
> > code related to development copyrighted. Very few people
> > are willing to release their code to the public domain. Even
> > today we still don't have C90 compliance. SubC is close
> > enough to be useful, but still not C90-compliant.

> I can answer part of that question. Free software is copyright so that
> it can remain free. Public domain code can be incorporated into
> anybody's copyright-restricted product at will, not a good thing from
> the point of view of those who promote free software. Of course, the
> same is true of some "free" licenses, too. Things are complicated.
>
> Now it's your turn! Given the previous paragraph, why do you want to
> create a public domain C?

From doc\virus.txt on the distribution:

The following describes the virus-licensed (aka "copyleft" which is
actually "copyright" or "free" (in a similar manner to how communist
dictators defined "freedom" to mean "being a slave under a communist
dictator")) software included in the full PDOS/386 distribution.

Note that I haven't got my lawyer to go through the 2573 license
conditions to find out if I (or you) are in violation of any of them,
and even if I did, I wouldn't trust him because in the end it comes
down to the whim of some judge, with a temporary judgement (until
overruled by another court), and this takes place worldwide. You can
read the licenses yourself by unzipping custom.zip to decide whether
you would feel safer exclusively using the University Challenge disk
which contains no such crap. Note that virus-licensing is discussed
more in \devel\pdos\pdpgoal.txt

And that last bit is a reference to:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpgoal.txt

BFN. Paul.

On Sunday, 20 March 2022 at 21:23:21 UTC, muta...@gmail.com wrote:
> On Monday, March 21, 2022 at 6:22:43 AM UTC+11, Ben Bacarisse wrote:
>
> > > I have created a purely public domain hard disk image
> > > which allows you to build programs in a subset of C90
> > > (SubC). All the necessary supporting components (OS,
> > > linker etc) are available.
>
> > Why?
> I'd rather ask why everyone else is determined to keep all
> code related to development copyrighted. Very few people
> are willing to release their code to the public domain. Even
> today we still don't have C90 compliance.

“We”? To whom do you reference?

> SubC is close enough to be useful, but still not C90-compliant.

and so has no place in c.l.c - please take it elsewhere.

On Monday, March 21, 2022 at 9:30:19 AM UTC+11, Tony Oliver wrote:

> > I'd rather ask why everyone else is determined to keep all
> > code related to development copyrighted. Very few people
> > are willing to release their code to the public domain. Even
> > today we still don't have C90 compliance.

> “We”? To whom do you reference?

The worldwide public. Earth.

> > SubC is close enough to be useful, but still not C90-compliant.

> and so has no place in c.l.c - please take it elsewhere.

It's a subset of C90, the goal is to get it to C90, and the
compiler itself can be compiled with a C90 compiler.

What's off-topic about that?

Or are you just peddling a virus-license agenda and don't
want any challenge to your horrible worldview?

BFN. Paul.

On 20/03/2022 23:54, muta...@gmail.com wrote:
> On Monday, March 21, 2022 at 9:30:19 AM UTC+11, Tony Oliver wrote:
>
>>> I'd rather ask why everyone else is determined to keep all
>>> code related to development copyrighted. Very few people
>>> are willing to release their code to the public domain. Even
>>> today we still don't have C90 compliance.
>
>> “We”? To whom do you reference?
>
> The worldwide public. Earth.
>
>>> SubC is close enough to be useful, but still not C90-compliant.
>
>> and so has no place in c.l.c - please take it elsewhere.
>
> It's a subset of C90, the goal is to get it to C90, and the
> compiler itself can be compiled with a C90 compiler.
>
> What's off-topic about that?
>
> Or are you just peddling a virus-license agenda and don't
> want any challenge to your horrible worldview?
>

Discussions about C - including subsets of C90, and threads about what
might be needed to make the compiler more compliant, are on-topic.

Highly unusual opinions about licensing or copyright is not. You
clearly have your strong opinions, which is fine. But you don't get to
attack others for not agreeing. If you want to pick fights with
licenses or copyrights, or people who use them, find some other forum
for it. (I'd recommend you find some Usenet group, Reddit group,
discussion forum, etc., where there are license and copyright experts
and lawyers present, especially from many different countries - that way
you can learn some of the facts involved. It may or may not change your
opinions, but they will be informed choices - always a good thing.)

On Monday, March 21, 2022 at 6:53:51 PM UTC+11, David Brown wrote:

> Discussions about C - including subsets of C90, and threads about what
> might be needed to make the compiler more compliant, are on-topic.

So perhaps you should have chided the other guy instead
of replying to me.

> Highly unusual opinions about licensing or copyright is not. You
> clearly have your strong opinions, which is fine. But you don't get to
> attack others for not agreeing.

I was attacking someone who attacked me by telling
me to piss off because I only had a subset of C90
instead of the full thing.

You should have chided the other guy, again.

> If you want to pick fights with

Give that advice to the other guy, not me.

> licenses or copyrights, or people who use them, find some other forum
> for it.

I was asked for my opinion in this group. Chide all the
other guys for asking for it.

> (I'd recommend you find some Usenet group, Reddit group,
> discussion forum, etc., where there are license and copyright experts
> and lawyers present, especially from many different countries - that way
> you can learn some of the facts involved. It may or may not change your
> opinions, but they will be informed choices - always a good thing.)

Your recommendations are better addressed to the others.
Or maybe take your own advice while you're at it.

BFN. Paul.

On 21/03/2022 09:16, muta...@gmail.com wrote:
> On Monday, March 21, 2022 at 6:53:51 PM UTC+11, David Brown wrote:
>
>> Discussions about C - including subsets of C90, and threads about what
>> might be needed to make the compiler more compliant, are on-topic.
>
> So perhaps you should have chided the other guy instead
> of replying to me.
>

My preference is not to chide anyone. But my comments about topicality
apply to all.

>> Highly unusual opinions about licensing or copyright is not. You
>> clearly have your strong opinions, which is fine. But you don't get to
>> attack others for not agreeing.
>
> I was attacking someone who attacked me by telling
> me to piss off because I only had a subset of C90
> instead of the full thing.
>

He was wrong too, IMHO - a subset of C90 may be topical here. You can
even talk about K&R C. (But be prepared to face a lot of people telling
you how badly out of date you are, and how modern C is better in many ways.)

But two wrongs don't make a right, and emotively arguing your license
preferences is not helping anyone.

Leave the licensing discussions and by all means (as far as I am
concerned) talk about C90 as much as you like.

Let's now get back to the C. When you say you have implemented a subset
of C90, what is missing, and why?

David Brown <david.brown@hesbynett.no> writes:
>On 20/03/2022 23:54, muta...@gmail.com wrote:

>>
>> Or are you just peddling a virus-license agenda and don't
>> want any challenge to your horrible worldview?
>>
>
>Discussions about C - including subsets of C90, and threads about what
>might be needed to make the compiler more compliant, are on-topic.
>
>Highly unusual opinions about licensing or copyright is not. You
>clearly have your strong opinions, which is fine. But you don't get to
>attack others for not agreeing. If you want to pick fights with
>licenses or copyrights, or people who use them, find some other forum
>for it. (I'd recommend you find some Usenet group, Reddit group,
>discussion forum, etc., where there are license and copyright experts
>and lawyers present, especially from many different countries - that way
>you can learn some of the facts involved. It may or may not change your
>opinions, but they will be informed choices - always a good thing.)

FWIW, he's inhabited alt.os.development for some time now.

On 2022-03-20, muta...@gmail.com <mutazilah@gmail.com> wrote:
> I have created a purely public domain hard disk image
> which allows you to build programs in a subset of C90
> (SubC). All the necessary supporting components (OS,
> linker etc) are available.
>
> The hard disk image is 40 MB but only 9 MB is used.
>
> See "University Challenge" at http://pdos.org

LOL, ... DOS.

Why not also ship an 80 column punched card containing your entire
perspective?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

Kaz Kylheku <480-992-1380@kylheku.com> writes:
>On 2022-03-20, muta...@gmail.com <mutazilah@gmail.com> wrote:
>> I have created a purely public domain hard disk image
>> which allows you to build programs in a subset of C90
>> (SubC). All the necessary supporting components (OS,
>> linker etc) are available.
>>
>> The hard disk image is 40 MB but only 9 MB is used.
>>
>> See "University Challenge" at http://pdos.org
>
>LOL, ... DOS.
>
>Why not also ship an 80 column punched card containing your entire
>perspective?

His code generator targets the IBM 360.

On Monday, March 21, 2022 at 11:51:47 PM UTC+11, David Brown wrote:

> Let's now get back to the C. When you say you have implemented a subset
> of C90, what is missing, and why?

It isn't me who wrote SubC. I don't have the required skills
to write a compiler. I'm not good with complex algorithms.

The things missing are listed here:

https://www.t3x.org/subc/README-current.html

search for "full c89".

Almost all of those things don't actually affect me. The
preprocessor shortcomings are overcome by using pdcc,
a public domain prepreprocessor. I'm only interested in
the 80386 at the moment so I just get the preprocessor
to define long=int and short=int. I have my own C library.

Although my coding style normally puts all the variables
at the top of a function, occasionally I am "lazy" and just
declare a variable inside a block. I do have some such
code. So if I can't change SubC I would need to change
that coding style.

Another thing I do is initialize local variables, even though
it is something that happens at run-time, and that doesn't
work. Maybe because it is difficult to parse or something.

If things are difficult to parse, I'm willing to change my coding
style to SubC, rather than wait for someone to release a public
domain fully-C90-compliant compiler - something no-one has
been willing to do for 50 years.

Note that a public domain 80386 assembler capable of
handling the output from SubC was only recently written
(by someone from Slovakia). And an a.out linker by someone
from Italy. These were the final things that allowed the
"University Challenge" disk to be produced.

BFN. Paul.

On Tuesday, March 22, 2022 at 2:02:24 AM UTC+11, Kaz Kylheku wrote:

> > See "University Challenge" at http://pdos.org

> LOL, ... DOS.

Laugh all you want. That's what the public actually owns.
Previously they had to zap machine code one byte at a time.
> Why not also ship an 80 column punched card containing your entire
> perspective?

Actually I don't trust storage media that I can't read without
equipment, so I am indeed thinking of getting all of this source
code, and the corresponding executables, put on punched cards,
perhaps plastic ones that will hopefully last forever, and have
multiple copies of that distributed around the world.

BFN. Paul.

2022-03-21 at 14:02 -0700, muta...@gmail.com wrote:
> Actually I don't trust storage media that I can't read without
> equipment, so I am indeed thinking of getting all of this source
> code, and the corresponding executables, put on punched cards,
> perhaps plastic ones that will hopefully last forever, and have
> multiple copies of that distributed around the world.

Have you thought about paper-based storage? It might achieve a higher
density than punch cards, and is probably easier to process.

Some time ago I briefly wrote about it on my gopher blog ("Using paper
as apocalyptic-resilient backup storage"):

gopher://gopher.viste.fr/1/notes/?a111f16d0

Mateusz

On Tuesday, March 22, 2022 at 8:24:40 AM UTC+11, Mateusz Viste wrote:

> 2022-03-21 at 14:02 -0700, muta...@gmail.com wrote:
> > Actually I don't trust storage media that I can't read without
> > equipment, so I am indeed thinking of getting all of this source
> > code, and the corresponding executables, put on punched cards,
> > perhaps plastic ones that will hopefully last forever, and have
> > multiple copies of that distributed around the world.
> Have you thought about paper-based storage? It might achieve a higher
> density than punch cards, and is probably easier to process.
>
> Some time ago I briefly wrote about it on my gopher blog ("Using paper
> as apocalyptic-resilient backup storage"):
>
> gopher://gopher.viste.fr/1/notes/?a111f16d0

I managed to read your link here:

https://gopherproxy.meulie.net/gopher.viste.fr/1/myinfobase/%3Fa111f16d0

You suggested using OCR software to read the paper, but
if we're in a post-apocalyptic world, aren't punched cards
easier to be machine-read than attempting to OCR characters?

PDOS is going to be first-to-market after the apocalypse.

BFN. Paul.

On Tuesday, March 22, 2022 at 7:50:34 AM UTC+11, muta...@gmail.com wrote:

> Another thing I do is initialize local variables, even though
> it is something that happens at run-time, and that doesn't
> work. Maybe because it is difficult to parse or something.

Correction. I can initialize local variables, but I can't do:

char *x = "hello";

either as a global or local.

I have to do:

char *x;

and then:

x = "hello";

at runtime.

I don't know what the issue is.

BFN. Paul.

On 21/03/2022 23:16, muta...@gmail.com wrote:
> On Tuesday, March 22, 2022 at 7:50:34 AM UTC+11, muta...@gmail.com wrote:
>
>> Another thing I do is initialize local variables, even though
>> it is something that happens at run-time, and that doesn't
>> work. Maybe because it is difficult to parse or something.
>
> Correction. I can initialize local variables, but I can't do:
>
> char *x = "hello";
>
> either as a global or local.
>
> I have to do:
>
> char *x;
>
> and then:
>
> x = "hello";
>
> at runtime.
>
> I don't know what the issue is.

Probably this:

"Note that SubC is a teaching vehicle rather than a production compiler."

(https://www.t3x.org/subc/)

> BFN. Paul.

On 21/03/2022 23:21, Bart wrote:
> On 21/03/2022 23:16, muta...@gmail.com wrote:
>> On Tuesday, March 22, 2022 at 7:50:34 AM UTC+11, muta...@gmail.com wrote:
>>
>>> Another thing I do is initialize local variables, even though
>>> it is something that happens at run-time, and that doesn't
>>> work. Maybe because it is difficult to parse or something.
>>
>> Correction. I can initialize local variables, but I can't do:
>>
>> char *x = "hello";
>>
>> either as a global or local.
>>
>> I have to do:
>>
>> char *x;
>>
>> and then:
>>
>> x = "hello";
>>
>> at runtime.
>>
>> I don't know what the issue is.
>
> Probably this:
>
> "Note that SubC is a teaching vehicle rather than a production compiler."
>
> (https://www.t3x.org/subc/)

I just downloaded this, but it really isn't very Windows-friendly. It
also purports to build itself, but you'd have a job getting to a working
compiler to try that out, unless you're running on Unix.

The first obstacle is that the sources used .tgz format (not known on
Windows; you need to download 7-Zip, and do the expansion in two parts,
first to .tar then to individual files).

Then these are the instructions for Windows:

"The Windows version of SubC requires the MinGW infrastructure,
but does not use the GNU libc. To build the compiler, the MSYS
environment of MinGW is needed."

"* DO NOT use "make". It will probably not work. Use the
WINBUILD.BAT script instead."

Too right! And WINBUILD still needs that MSYS stuff.

All the docs including for DOS have long lists of things imported from
Unix, and in fact you have to cross-compile from Unix.

These aren't the dependency problems you need in your post-apocalyptic
scenario!

This is for a project that is 20 .h/.c files, some 6000 lines in total;
not a big project, and the self-hosting comment gives the impression
that it will build with pretty much any compiler as most support a
bigger subset.

(I understand that when built, it will run but may not support a Windows
target; I just wanted to see it in action even if I can't run its output.)

On Tuesday, March 22, 2022 at 10:50:09 AM UTC+11, Bart wrote:

> (I understand that when built, it will run but may not support a Windows
> target; I just wanted to see it in action even if I can't run its output.)

If you download "University Challenge" from http://pdos.org
and then mount that disk, you will find sccwin.exe in the
"dos" subdirectory, which runs under Windows.

I'll reply to other stuff a bit later.

BFN. Paul.

On Tuesday, March 22, 2022 at 10:50:09 AM UTC+11, Bart wrote:

> Probably this:

> "Note that SubC is a teaching vehicle rather than a production compiler."

The whole of the University Challenge disk is a teaching
vehicle rather than production, but that's no reason why
we shouldn't aim for C90-compliance.

Actually I wouldn't even say that UC is a teaching vehicle.
It's more like a starter system so that you can WRITE a
teaching vehicle.

And then you can use the teaching vehicle to write
production tools and then a proper multitasking production
system.

> I just downloaded this, but it really isn't very Windows-friendly. It
> also purports to build itself, but you'd have a job getting to a working
> compiler to try that out, unless you're running on Unix.

PDOS/386, including UC, is Windows-friendly. It is in
fact a mini Win32 clone. That's why it comes with its
own msvcrt.dll.

> The first obstacle is that the sources used .tgz format (not known on
> Windows; you need to download 7-Zip, and do the expansion in two parts,
> first to .tar then to individual files).

On the UC disk, and indeed the full PDOS/386 distribution,
the source can be found in \devel\subc\src

UC doesn't have an unzip so everything needs to be
decompressed.

> Then these are the instructions for Windows:

I have different instructions for Windows, but I haven''t
written them down.

Add \dos (which contains only Windows executables,
almost all dependent on just msvcrt.dll but some depend
on kernel32.dll instead) to your path and then go:

cd \devel\world
pdmake -f worldw2.mak

> "The Windows version of SubC requires the MinGW infrastructure,
> but does not use the GNU libc. To build the compiler, the MSYS
> environment of MinGW is needed."

I have replacement instructions, also not written down:

Go:

cd \devel\subc\src
pdmake -f makefile.p32

> "* DO NOT use "make". It will probably not work. Use the
> WINBUILD.BAT script instead."

This is not required.

> Too right! And WINBUILD still needs that MSYS stuff.

This is not required.

> All the docs including for DOS have long lists of things imported from
> Unix, and in fact you have to cross-compile from Unix.

To compile for DOS run sccdos.exe instead.

> These aren't the dependency problems you need in your post-apocalyptic
> scenario!

If you just boot the UC disk and go through the readme
files, none of those dependencies arise.

> This is for a project that is 20 .h/.c files, some 6000 lines in total;
> not a big project, and the self-hosting comment gives the impression
> that it will build with pretty much any compiler as most support a
> bigger subset.

Yes, if you do:

pdmake -f makefile.w32
in \devel\subc\src
it will build with gccwin (included in the full PDOS/386 distribution) instead.

> (I understand that when built, it will run but may not support a Windows
> target; I just wanted to see it in action even if I can't run its output.)

It does support a Windows target when built, but you will
need to statically link the (supplied) C library because it can't
deal with msvcrt.dll (dllexport is used) and you will need to
use the (supplied) aswin/ldwin derived from binutils because
we don't have a public domain COFF/PE assembler/linker.

Let me know of any other issues.

BFN. Paul.