> 2) got some kind of console interface

Yes, it has an MSDOS prompt.

> 3) is able to see and read files in common disk formats

Yes, it supports FAT-12, FAT-16 and FAT-32
including long file name support.

> 4) got at least one compiler ported

Yes, GCC 3.2.3 has been ported.

> 5) youre able to code what you need inside
> it (like file viewers and editors, cosket
> connections etc)

editors yes. socket connections no. It is
still basically competing with MSDOS, and
doesn't have networking or device drivers
currently. It reads disks by dropping down
to 16-bit real mode and doing a BIOS call.
You can call it a "BIOS extender" as
contrasted with a "DOS extender".

Having said that, with PDOS/386 self-hosting,
PDOS/386 can be used to add networking etc
if that is the desired direction. But I was
more thinking of writing a BBS that uses
the COM port, which Bochs will emulate as a
socket connection. But I would basically be
writing to a 1990-era computer, with the
C90 standard. ie at the time the C90 standard
was approved, what OS should have been written
for the 80386, which was around then?

> what of this you got?

Most of it.

BFN. Paul.

Philipp Klaus Krause

unread,

May 2, 2020, 5:05:25 AM5/2/20

to

I can see the elegance of using pure standard C.
But why did you choose C90 instead of a later C standard?

Philipp

Paul Edwards

unread,

May 2, 2020, 5:07:07 AM5/2/20

to

On Saturday, 2 May 2020 18:56:49 UTC+10, Paul Edwards wrote:

> > 3) is able to see and read files in common disk formats
>
> Yes, it supports FAT-12, FAT-16 and FAT-32
> including long file name support.

Actually, one of the things I was thinking
of doing was having an EBCDIC FAT disk, and
if a file is fopen()ed in text mode, when it
does the OS call to open the file, it would
specify OPEN_TEXT versus OPEN_BINARY and the
OS would take care of translating to/from
EBCDIC.

Basically I'm thinking of cool things to do
with a C90-focused operating system.

BFN. Paul.

fir

unread,

May 2, 2020, 5:07:14 AM5/2/20

to

imo:
get it 64 bit
do irc client working on it

if you wana make somethng new you should put ome of my idea of new kind of disk files ogganisation to work (the idea is that files should be not organized in directory tree but rather as multidimensional trees ('based on tags') also eeach file should have its author not only title (just like books) and automatic versioning info and hard checks for integrity

then you can go ointo something new further

Paul Edwards

unread,

May 2, 2020, 5:14:31 AM5/2/20

to

On Saturday, 2 May 2020 19:05:25 UTC+10, Philipp Klaus Krause wrote:

> I can see the elegance of using pure standard C.

Can you elaborate on that? Do you have a
vision?

> But why did you choose C90 instead of a later C standard?

The project started in 1994. And the goal
I had was to replace everything I was using,
e.g. using BBSes, with public domain C code.

It's a very long road just to implement C90,
nevermind chasing a moving target. Once C90
has been done to my satisfaction, I'll
consider updating to a newer standard.

But that also means writing a public domain
C compiler for the 80386. I'm not particularly
expecting to accomplish that in my lifetime.

Basically the public does not yet own the
technology to build and maintain a system
from the early 1990s.

BFN. Paul.

Paul Edwards

unread,

May 2, 2020, 5:23:41 AM5/2/20

to

On Saturday, 2 May 2020 19:07:14 UTC+10, fir wrote:

> get it 64 bit

Ok. PDOS actually has a 16-bit flavor,
PDOS/86, from the same source base. There
is nothing wrong with creating a 64-bit
flavor too. But most applications will
run perfectly happily in 4 GiB of memory.

> do irc client working on it

Ok. And what do you think if this is done
via a COM port? Bochs has the ability to
make a COM port link to a socket. I was
thinking that I could have a "modem"
application on my PC for Bochs to link to,
so that my PDOS/386 comms program could
do an ATDirc.freenode.net:xx

> if you wana make somethng new you should
> put ome of my idea of new kind of disk
> files ogganisation to work (the idea is
> that files should be not organized in
> directory tree but rather as multidimensional
> trees ('based on tags') also eeach file
> should have its author not only title (just
> like books) and automatic versioning info
> and hard checks for integrity
>
> then you can go ointo something new further

Ok, it could be used to experiment with new
ideas like that. Thanks for your suggestions.

BFN. Paul.

Bonita Montero

unread,

May 2, 2020, 6:11:59 AM5/2/20

to

> I can see the elegance of using pure standard C.

C has never been elegant.
Even C++, which is _more_ elegant, isn't absolutely elegant.

Bart

unread,

May 2, 2020, 6:13:55 AM5/2/20

to

On 02/05/2020 06:19, Paul Edwards wrote:
> For decades I have been working on creating a
> public domain operating system called PDOS/386.
> You can see the project here:
>
> http://pdos.sourceforge.net/

I assume this is open source software. If so, I'm having trouble
locating the source code (ie. .c and .h files). Is this it here:

https://sourceforge.net/p/pdos/gitcode/ci/pdos-stage1/tree/

?

But looking at it further, that's just one of many directories.

Could someone with, say, a Windows PC and a number of C compilers (but
not Turbo C which I saw mentioned), build any of this stuff and run it,
or do you need vintage hardware?

Is the 'int' size in those sources 16-bit or 32-bit?

If the result of building is some special binary format suitable for
bootstrapping an OS on actual hardware, how do you get a C compiler to
do that; will they need to support those formats?

Bart

unread,

May 2, 2020, 6:26:38 AM5/2/20

to

C++ can never look elegant. I think even ASM beats it for looks.

But the elegance here is in writing code that works on any compiler and
not relying on special features of specific implementations.

Paul Edwards

unread,

May 2, 2020, 6:53:19 AM5/2/20

to

On Saturday, 2 May 2020 20:13:55 UTC+10, Bart wrote:
> On 02/05/2020 06:19, Paul Edwards wrote:
> > For decades I have been working on creating a
> > public domain operating system called PDOS/386.
> > You can see the project here:
> >
> > http://pdos.sourceforge.net/
>
> I assume this is open source software. If so, I'm having trouble

Yes it is.

> locating the source code (ie. .c and .h files). Is this it here:
>
> https://sourceforge.net/p/pdos/gitcode/ci/pdos-stage1/tree/
>
> ?

The latest released software and binaries is
available here:

https://sourceforge.net/projects/pdos/files/pdos/pdos%200.90/pdos090.zip/download

The development source tree is available here:

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

Go into "src" and look at pdos.c for the main code.

> But looking at it further, that's just one of many directories.
>
> Could someone with, say, a Windows PC and a number of C compilers (but
> not Turbo C which I saw mentioned), build any of this stuff and run it,
> or do you need vintage hardware?

I use Windows 10 and GCC 3.2.3 to build
PDOS/386. You need GCC 3.2.3 built as a
cross-compiler though, because the OS
needs to be in a.out format, not Windows
PE format. Because that's what the boot
loader is expecting. I do have plans to
switch to Windows PE format though.

It is designed to be booted on modern
hardware, but it needs "legacy boot", as
the boot loader is still written to boot
on 1990 hardware.

Note that when I actually tried booting as
a USB stick directly on hardware, PDOS/386
did not boot correctly, so needs to be
debugged. PDOS/86 booted as a floppy image
though. I do all my development and testing
using Bochs under Windows 10. That will become
a more critical factor when I start relying
on COM ports to be emulated, something I don't
have on real hardware anymore.

> Is the 'int' size in those sources 16-bit or 32-bit?

If you compile with GCC 3.2.3 it will be
32-bits. If you compile with Watcom C wcl
it will be 16-bits.

> If the result of building is some special binary format suitable for
> bootstrapping an OS on actual hardware, how do you get a C compiler to
> do that; will they need to support those formats?

There is a 16-bit boot loader that loads
the 32-bit a.out executable, applies the
relocations, initializes BSS and switches
to protected mode, and handles the return
for when a BIOS call needs to be made.

BFN. Paul.

Bonita Montero

unread,

May 2, 2020, 7:06:41 AM5/2/20

to

> C++ can never look elegant. I think even ASM beats it for looks.

It largely depends on the expressiveness how elegant a language is.
And C is more expressive than ASM, but C++ is by fare more expressive
than C.

Malcolm McLean

unread,

May 2, 2020, 7:26:20 AM5/2/20

to

How expressive and how simple.
C++ is very expressive, but hardly simple.
Fortran is simple, but not very expressive.

C hits a sweet spot, simple enough to learn quickly and to implement as
a one man job, but expressive enough for structured programming. It's
not expressive enough for object-oriented programming or functional
programming.

fir

unread,

May 2, 2020, 7:53:37 AM5/2/20

to

c is quite expressive if some use good libraries and good names

and bonita opinions on c dont matter (same level of importance and value as imbecile dik opinions)

Paul Edwards

unread,

May 2, 2020, 8:15:01 AM5/2/20

to

On Saturday, 2 May 2020 20:53:19 UTC+10, Paul Edwards wrote:

> The development source tree is available here:
>
> https://sourceforge.net/p/pdos/gitcode/ci/master/tree/
>
> Go into "src" and look at pdos.c for the main code.

And if you want to run Bochs and do actual
development, practical instructions are here:

http://www.mutazilah.org/pdwin.txt

BFN. Paul.

Paul Edwards

unread,

May 2, 2020, 9:30:33 AM5/2/20

to

On Saturday, 2 May 2020 20:53:19 UTC+10, Paul Edwards wrote:

> using Bochs under Windows 10. That will become
> a more critical factor when I start relying
> on COM ports to be emulated, something I don't
> have on real hardware anymore.

Basically my current plan is to distribute
PDOS/386 as a floppy disk image that includes
a serial comms program with zmodem (which I
already have C90 source for), and I will tell
people to format a hard disk and then dial a
BBS to download the extra stuff like the rest
of the DOS commands plus utilities like gcc,
as separate downloads.

BFN. Paul.

Bonita Montero

unread,

May 2, 2020, 10:20:52 AM5/2/20

to

> How expressive and how simple.

Simplicity mostly contraticts expressiveness.

> C hits a sweet spot, simple enough to learn quickly and to implement
> as a one man job, but expressive enough for structured programming.

It's harder to learn C++ than C, but it you've managed it is easier to
challenge large program development than in C. It has the better means
to structure your work and the code is massively shorter.

Bonita Montero

unread,

May 2, 2020, 10:21:22 AM5/2/20

to

> c is quite expressive if some use good libraries and good names
> and bonita opinions on c dont matter (same level of importance and value as imbecile dik opinions)

Your opinion doesn't count as you're a bloody beginner.

Malcolm McLean

unread,

May 2, 2020, 10:33:25 AM5/2/20

to

On Saturday, 2 May 2020 15:20:52 UTC+1, Bonita Montero wrote:
> > How expressive and how simple.
>
> Simplicity mostly contraticts expressiveness.
>

Exactly. It's easy to write a simple language which is not very expressive,
and it's easy to design, though not to implement, a complicated language
whch is quite expressive. But it is hard to design a simple language
which is also expressive. We reserve the term 'elegant" for that feat.

Bonita Montero

unread,

May 2, 2020, 10:35:37 AM5/2/20

to

> Exactly. It's easy to write a simple language which is not very expressive,
> and it's easy to design, though not to implement, a complicated language
> whch is quite expressive. But it is hard to design a simple language
> which is also expressive. We reserve the term 'elegant" for that feat.

You can see it that way, ...
but C certainly didn't win the competition in that sense.

Bart

unread,

May 2, 2020, 12:30:27 PM5/2/20

to

[Off the topic of pure C90]

On 02/05/2020 15:20, Bonita Montero wrote:
>> How expressive and how simple.
>
> Simplicity mostly contraticts expressiveness.

Remember the strrepl thread? My scripting solution can be expressed like
this:

function strrepl(s, old, new)=
t := ""
while n:=old in s do
t +:= s[1..n-1] + new
s := s[n+old.len..$]
od
return t+s
end

Far more elegant than any of your C++ versions, with fewer dependencies,
/and/ it was faster. Plus build time is essentially zero.

Elegant, expressive, simple. Even if C++ can emulate these types and
operations, the declaration syntax, and the general clutter of the
language, kills it.

Bonita Montero

unread,

May 2, 2020, 12:37:46 PM5/2/20

to

Am 02.05.2020 um 18:30 schrieb Bart:
> [Off the topic of pure C90]
>
> On 02/05/2020 15:20, Bonita Montero wrote:
>>> How expressive and how simple.
>>
>> Simplicity mostly contraticts expressiveness.
>
> Remember the strrepl thread? My scripting solution can be expressed like
> this:
>
>     function strrepl(s, old, new)=
>         t := ""
>         while n:=old in s do
>             t +:= s[1..n-1] + new
>             s := s[n+old.len..$]
>         od
>         return t+s
>     end
>
> Far more elegant than any of your C++ versions, with fewer dependencies,
> /and/ it was faster. Plus build time is essentially zero.

The performance largely depends on the operations in your language
runtime and not in the language itself. Your language is built wich
a lowlevel-language like C or a mixed language like C++ for sure,
so there's no cause to assume it could be faster than any C / C++
-solutiuon.
I've just got across an algorithm called "optimal mismatch", which
is in fact the fastest string-search-algorithm. With this nothting
from your language-runtime would help you to implement an as fast
version. Scripting languages are slow when their code doesn't depend
on the runtime-functions.

unread,

May 2, 2020, 2:21:06 PM5/2/20

to

in your low-mind word, im sorry but i think we will not talk and yopu will be treated like dik hodgin by me

people who degrade group mentally by trials of enforcing bulshit on this group sre special kind who share syupidity and i dont plan tu support such depressive mental degraders here

Paul Edwards

unread,

May 2, 2020, 3:49:22 PM5/2/20

to

I was thinking that I could have a setting
in CONFIG.SYS of WIPE=YES which would cause
a delete operation to wipe out (to x'00')
the disk sectors of deleted files for both
security and so that a disk image compresses
well.

BFN. Paul.

Ben Bacarisse

unread,

May 2, 2020, 5:46:04 PM5/2/20

to

Bart <b...@freeuk.com> writes:

> [Off the topic of pure C90]
>
> On 02/05/2020 15:20, Bonita Montero wrote:
>>> How expressive and how simple.
>>
>> Simplicity mostly contraticts expressiveness.
>
> Remember the strrepl thread? My scripting solution can be expressed like this:
>
> function strrepl(s, old, new)=
> t := ""
> while n:=old in s do
> t +:= s[1..n-1] + new
> s := s[n+old.len..$]
> od
> return t+s
> end

This can be written in C++ like this:

using std::string;

string replace(const string &str, const string &pat, const string &rep)
{
string result;
string::size_type pos = 0, start;
while ((start = str.find(pat, pos)) != string::npos) {
result += str.substr(pos, start - pos) + rep;
pos = start + pat.length();
}
return result + str.substr(pos);
}

It need not be as complicated as some of the posted code.

--
Ben.

Bart

unread,

May 2, 2020, 6:29:40 PM5/2/20

to

That's not too bad. Certainly it is smaller and simpler than anything I
remember Bonita posting.

Yet, it's not quite as clean as the dynamic code, and I had some fun
trying to figure out how to pass such a string to fwrite.

(Also, on a machine which doesn't support the SSE ops needed for fast
string search, it was still 25% slower than my interpreter running that
script.)

Ben Bacarisse

unread,

May 2, 2020, 10:55:24 PM5/2/20

to

Your code appears to have some string operations built-in. It's even
simpler written in a language that has lots of string operations
built-in. In Perl it's just

s/$old/$new/g

> and I had some fun trying to figure out how to pass such a string to
> fwrite.

Well, it's an odd thing to do, so I am not surprised by that.

> (Also, on a machine which doesn't support the SSE ops needed for fast
> string search, it was still 25% slower than my interpreter running
> that script.)

All the "simple" versions posted are little more then drivers for the
underlying operations of string searching and copying. On my system,
your code is slow simply because the "in" operator is not implemented as
well as it could be for that target. And my C version is slow on your
system because strstr is not well implemented in the C implementation
you use. On my machine, the C++ code is slower than the C code but
faster than yours. All that does is reflect the implementation of the
underlying operations.

--
Ben.

Malcolm McLean

unread,

May 3, 2020, 5:16:55 AM5/3/20

to

I suspect it works well in a test environment, not so well in deployment.

The reason is that the buffer needs to grow on every match. If the program
has made only one allocation, the string will be before an empty region
of memory. So realloc() can just adjust the block length.
In deployment, it is more likely to be give a small free region on the
initial request from a fragmented memory pool. So reallocations will involve copying.

It is however a reasonable way to write strepl. Let the built-in allocation
and string functions take the strain.

Bart

unread,

May 3, 2020, 8:07:55 AM5/3/20

to

On 03/05/2020 03:55, Ben Bacarisse wrote:
> Bart <b...@freeuk.com> writes:

>> Yet, it's not quite as clean as the dynamic code,
>
> Your code appears to have some string operations built-in.

This one of my gripes against C++, because it provides a complex toolkit
for adding such operations instead of just providing them. The result is
a very difficult language, and 'built-in' features that are very
cumbersome to use.

It's even
> simpler written in a language that has lots of string operations
> built-in. In Perl it's just
>
> s/$old/$new/g

It's not quite that simple. 12,000 files and 500MB later, I found I
needed to do this:

$newtext = $text;
$newtext =~ s/lived/LIVEDFOREVER/g;

Like that, it was still somewhat slower than my interpreter

(Fastest times this morning for 100 iterations of the test input were
2.48 seconds Perl, 2.15 seconds for my interpreter, where it is /not/
built-in, requiring more bytecode to be executed.)

>> and I had some fun trying to figure out how to pass such a string to
>> fwrite.
>
> Well, it's an odd thing to do, so I am not surprised by that.

Part of the task is the write the result to a file (and not by the crude
way of writing to a console and capturing the output, mixed up with any
messages such as timing results). The original used fwrite. Maybe there
is a way of directly writing a 'string' object to a file, but I didn't
know what that was either.

fir

unread,

May 3, 2020, 8:24:39 AM5/3/20

to

W dniu niedziela, 3 maja 2020 14:07:55 UTC+2 użytkownik Bart napisał:
> On 03/05/2020 03:55, Ben Bacarisse wrote:
> > Bart <b...@freeuk.com> writes:
>
> >> Yet, it's not quite as clean as the dynamic code,
> >
> > Your code appears to have some string operations built-in.
>
> This one of my gripes against C++, because it provides a complex toolkit
> for adding such operations instead of just providing them. The result is
> a very difficult language, and 'built-in' features that are very
> cumbersome to use.
>

kinda funny this 'feature' of c++ of abilioty to 'selfdefine' a language inside of it is probably the main and only good point in it

hovever it was obviously done bad but generally its interesting kind of feature (once i already was writing this, maybe in some future i will write more)

Malcolm McLean

unread,

May 3, 2020, 8:26:32 AM5/3/20

to

On Sunday, 3 May 2020 13:07:55 UTC+1, Bart wrote:
>
> Part of the task is the write the result to a file (and not by the crude
> way of writing to a console and capturing the output, mixed up with any
> messages such as timing results). The original used fwrite. Maybe there
> is a way of directly writing a 'string' object to a file, but I didn't
> know what that was either.

std::string str = strrepl( ... )
std::ofstream ofs;
ofs.open ("test.txt", std::ofstream::out);

ofs << str;

ofs.close();

Bart

unread,

May 3, 2020, 9:28:07 AM5/3/20

to

You want this to be a built-in one-liner. That's easy to add as a
regular function in any language, but it should be part of the library.

Eg, I use:

writestrfile("test.txt", str)
writefile("test.txt", str, strlen(str)) # adapts to C too

Perl:

write_file("test.txt", $str)

Some make it harder than others:

http://rosettacode.org/wiki/Write_entire_file

Having it as one function allows chaining:

writestrfile("out",reverse(readstrfile("bible.txt")))

->
.nemA .lla uoy htiw eb tsirhC suseJ droL ruo fo ecarg ehT 12:22 veR

Or, reading/writing lists of lines rather than one string:

writetextfile("out",reverse(readtextfile("bible.txt")))

These two are a bit harder in C because you have intermediate results to
manage. It /ought/ to be possible in C++, but the prospect of figuring
how to do it (after searching innumerable libraries for see it's already
there), or dealing with :: and <> and declaration syntax, or having to
write an entire app in such a clunky language, is really not attractive.

Ben Bacarisse

unread,

May 3, 2020, 5:06:59 PM5/3/20

to

Bart <b...@freeuk.com> writes:

> On 03/05/2020 03:55, Ben Bacarisse wrote:
>> Bart <b...@freeuk.com> writes:
>
>>> Yet, it's not quite as clean as the dynamic code,
>>
>> Your code appears to have some string operations built-in.
>
> This one of my gripes against C++, because it provides a complex
> toolkit for adding such operations instead of just providing them.

The language does provide them. The code I posted uses them alone and
no user-defined operations.

> The
> result is a very difficult language, and 'built-in' features that are
> very cumbersome to use.

I posted the code because I think it shows that C++'s strings are not

"very cumbersome" to use.

>> It's even
>> simpler written in a language that has lots of string operations
>> built-in. In Perl it's just
>>
>> s/$old/$new/g
>
> It's not quite that simple.

The test is rigged (unintentionally, I am sure). I can rig the test the
other way: how does your language do the substitution for every line of
any number of input files?

> 12,000 files and 500MB later,

I can recommend a good book, but that might be too last century for you.

> I found I needed to do this:
>
> $newtext = $text;
> $newtext =~ s/lived/LIVEDFOREVER/g;
>
> Like that, it was still somewhat slower than my interpreter

On your system, using whatever Perl you found and using whatever
libraries that happens to use.

On my system, with a recent Linux 64-bit version of Perl it's about
twice the speed of your interpreter.

Neither statement says anything of any importance.

>>> and I had some fun trying to figure out how to pass such a string to
>>> fwrite.
>>
>> Well, it's an odd thing to do, so I am not surprised by that.
>
> Part of the task is the write the result to a file (and not by the
> crude way of writing to a console and capturing the output, mixed up
> with any messages such as timing results).

Why would anyone do that? Much better to write to std::cout and, if
your system software is half decent, the timing text can be kept
separate. (Of course, for the purposes of comparison, my C++ driver
copies the "named file in, named file out" method from when I started
programming in the 70s.)

> The original used
> fwrite. Maybe there is a way of directly writing a 'string' object to
> a file, but I didn't know what that was either.

The original was in C. No one expects you to know C++, but your
experience of twisting the language's arm to write a std::string using
fwrite does not add anything technical to the discussion.

--
Ben.

Ben Bacarisse

unread,

May 3, 2020, 5:39:07 PM5/3/20

to

Bart <b...@freeuk.com> writes:

> On 03/05/2020 13:26, Malcolm McLean wrote:
>> On Sunday, 3 May 2020 13:07:55 UTC+1, Bart wrote:
>>>
>>> Part of the task is the write the result to a file (and not by the crude
>>> way of writing to a console and capturing the output, mixed up with any
>>> messages such as timing results). The original used fwrite. Maybe there
>>> is a way of directly writing a 'string' object to a file, but I didn't
>>> know what that was either.
>>
>> std::string str = strrepl( ... )
>> std::ofstream ofs;
>> ofs.open ("test.txt", std::ofstream::out);
>>
>> ofs << str;
>>
>> ofs.close();
>>
>
> You want this to be a built-in one-liner.

My driver for these tests used

std::ofstream(argv[4]) << str;

You don't need MM's four lines, but this thread has got to the point
where it needs to be seen by real C++ experts.

--
Ben.

anti...@math.uni.wroc.pl

unread,

May 3, 2020, 6:33:40 PM5/3/20

to

Paul Edwards <muta...@gmail.com> wrote:
> On Saturday, 2 May 2020 19:05:25 UTC+10, Philipp Klaus Krause wrote:
>
> > I can see the elegance of using pure standard C.
>
> Can you elaborate on that? Do you have a
> vision?
>
> > But why did you choose C90 instead of a later C standard?
>
> The project started in 1994. And the goal
> I had was to replace everything I was using,
> e.g. using BBSes, with public domain C code.
>
> It's a very long road just to implement C90,
> nevermind chasing a moving target. Once C90
> has been done to my satisfaction, I'll
> consider updating to a newer standard.
>
> But that also means writing a public domain
> C compiler for the 80386. I'm not particularly
> expecting to accomplish that in my lifetime.
>
> Basically the public does not yet own the
> technology to build and maintain a system
> from the early 1990s.

It is rather unclear what you really want. There are
several freely available C compilers. There
are several freely available compiler books.
So implementations and knowledge is there.
Writing a "bastard C" compiler could be done
in less than one month. Few more months and
it would be better than many C compilers from
1990.

Concerning systems from early 1990s, at that
time I switched to 386BSD and then Linux.
Both are available (trough reqular archives
offer you successors...). Concerning software
for micros from that time and earlier IMHO
utalitarian value of most this is close to
zero: there are better systems and programs
now. I understand and respect that you may
want to work with old systems. But various
otherwise nasty restrictions like "no
commercial use" do not bother me so much
for old software since it does not have
commercial value anyway.

And combination of "system from the early 1990s"
and "pure C90" looks odd: old software for micros
were habitualy nonstandard, used nonportable
low-level tricks etc...

--
Waldek Hebisch

Paul Edwards

unread,

May 3, 2020, 7:18:46 PM5/3/20

to

On Monday, 4 May 2020 08:33:40 UTC+10, anti...@math.uni.wroc.pl wrote:

> It is rather unclear what you really want.

To establish a public domain baseline, armed
with the C90 standard. That was the point at
which we had a standardized language for
writing systems software.

> want to work with old systems. But various
> otherwise nasty restrictions like "no
> commercial use" do not bother me so much

They bother me. I'm looking for pure public
domain software with no caveats.

> And combination of "system from the early 1990s"
> and "pure C90" looks odd: old software for micros
> were habitualy nonstandard, used nonportable
> low-level tricks etc...

GCC, AS and LD can all be written as pure C90
applications.

It's true I need some non-C90 code in order
to operate a modem so that I can download
more C90 software. And it's true that I need
some non-C90 software to have a fullscreen
editor. But apart from that I think I can do
what I want, e.g. having a BBS in the
Vietnamese language using VISCII, using C90
locales.

BFN. Paul.

Öö Tiib

unread,

May 3, 2020, 7:23:31 PM5/3/20

to

It is unlikely (but not forbidden by standard) that string is reallocating
its buffer on every append. It is unlikely because in typical library
implementations the containers tend to grow their capacity exponentially
when running out of space.

To reduce even those reallocations we can result.reserve(good_prediction)
right at start.

>
> It is however a reasonable way to write strepl. Let the built-in allocation
> and string functions take the strain.

Leaving the built-in algorithms to work can be fine. I have seen
how clumsy maintenance did add reserve() that did actually damage
performance and caused noticeable slow-down.

I myself would most likely just use boost ...

#include <boost/algorithm/string.hpp>

... and then ...

boost::replace_all(str, pat, rep);

... as first thing. It is likely good enough.

If it is like vast majority of code then it does alter overall
performance of whatever I'm writing by very little and it
disappears into rest of the thousands of lines of code.

If it however matters ... then it will swim up one day as
potential performance improvement.

Bart

unread,

May 3, 2020, 7:28:36 PM5/3/20

to

On 03/05/2020 22:06, Ben Bacarisse wrote:
> Bart <b...@freeuk.com> writes:
>
>> On 03/05/2020 03:55, Ben Bacarisse wrote:
>>> Bart <b...@freeuk.com> writes:
>>
>>>> Yet, it's not quite as clean as the dynamic code,
>>>
>>> Your code appears to have some string operations built-in.
>>
>> This one of my gripes against C++, because it provides a complex
>> toolkit for adding such operations instead of just providing them.
>
> The language does provide them. The code I posted uses them alone and
> no user-defined operations.

From what I can find out the 'string' type used is an instantiation of
a 'basic_string' template, where it seems it is implemented using the
C++ templates, classes, methods and overloads.

It's 'built-in' in that the library is (I guess) expected to be included
in a C++ installation. But those operations are not an intrinsic part of
C++.

There's no particularly problem in a language being partly implemented
in itself, but here it is not that transparent.

Eg. C++ uses 'std::cout' to print stuff, I use a 'print' statement. To
see the difference in approach, try writing 'std::cout >> "hello";'
instead of "std::cout << "hello";'.

>> The
>> result is a very difficult language, and 'built-in' features that are
>> very cumbersome to use.
>
> I posted the code because I think it shows that C++'s strings are not
> "very cumbersome" to use.

I was trying to be kind. A lot of C++ is spectacularly bad, this bit was
much better than what I usually see.

(Although you could probably have replaced 'string::size_type' with just
'int'? Or some 64-bit version.

This is something I can't see the point of, taking what is just an
integer type, a size/count/offset, and using a dedicated type do the job.

In my code, I just use 'int' or 'word' (i64/u64). C and C++ would have
to use [u]int64_t to cover most bases.

C++ didn't stop me copying those string::size_type variables to ordinary
ints, so if doesn't provide the safeguards of a more strongly typed
language, then why bother.)

>> It's not quite that simple.
>
> The test is rigged (unintentionally, I am sure). I can rig the test the
> other way: how does your language do the substitution for every line of
> any number of input files?

Does s///g do that too?

As I said I don't have built-in string replace let alone file replace;
I'd have to code it in the language. (Which is routine, not very
exciting code; see below.)

>> 12,000 files and 500MB later,
>
> I can recommend a good book, but that might be too last century for you.

That was the installation size needed to try out your code (which, for
some reason also included a full version of gcc). I still don't get what
s///* is, or how it works, but I managed to get it to do the job.

------------------------------------------
import sys
import files
import oslib

const inpath="./files/"
const outpath="./files2/"

proc start=

if ncmdparams<>4 then
fprintln "Usage: qq # <filespec> <old> <new>",
extractbasefile(cmdparams[1])
stop 1
fi

(filespec, oldstr, newstr) := cmdparams[2..4]
files := dirlist(inpath+filespec)

if not files then
println "No files found"
stop 1
fi

forall file in files do
println "Converting",inpath+file,,":"
filerepl(inpath+file, oldstr, newstr, outpath+file)
od

println "Done"
end

proc filerepl(filename, oldstr, newstr, newfile="")=
if newfile = "" then newfile := filename fi
writestrfile(newfile, strrepl(readstrfile(filename), oldstr, newstr))
end

function strrepl(s, old, newstr)=
t := ""
while n := old in s do
t +:= s[1..n-1]+newstr

anti...@math.uni.wroc.pl

unread,

May 3, 2020, 8:35:50 PM5/3/20

to

Paul Edwards <muta...@gmail.com> wrote:
> On Monday, 4 May 2020 08:33:40 UTC+10, anti...@math.uni.wroc.pl wrote:
>
> > It is rather unclear what you really want.
>
> To establish a public domain baseline, armed
> with the C90 standard. That was the point at
> which we had a standardized language for
> writing systems software.
>
> > want to work with old systems. But various
> > otherwise nasty restrictions like "no
> > commercial use" do not bother me so much
>
> They bother me. I'm looking for pure public
> domain software with no caveats.

So you find MIT licence too problematic? Note
that "public domain" has caveats too: there
are examples of things taken out of "public domain"...

Or do you realy mean that you want software that
you wrote yourself and can give away to others?

> > And combination of "system from the early 1990s"
> > and "pure C90" looks odd: old software for micros
> > were habitualy nonstandard, used nonportable
> > low-level tricks etc...
>
> GCC, AS and LD can all be written as pure C90
> applications.
>
> It's true I need some non-C90 code in order
> to operate a modem so that I can download
> more C90 software. And it's true that I need
> some non-C90 software to have a fullscreen
> editor. But apart from that I think I can do
> what I want, e.g. having a BBS in the
> Vietnamese language using VISCII, using C90
> locales.

You can write nontrivial things in pure C90.
My points are:
- if you drop requirement of compatiblity ("recreating")
old systems your task would be much easier
- if this is intended to be more than intelectuctal
excercise, then you probably want something that
works natively or semi-natively on modern
hardware
- if you want do things that people want you
need to handle hardware

Also, nontrivial sofware uses libraries. Library
may be pure C90, but code that uses it is only
conditonaly C90 -- it depends on presence of the
library.

--
Waldek Hebisch

Paul Edwards

unread,

May 3, 2020, 8:55:03 PM5/3/20

to

On Monday, 4 May 2020 10:35:50 UTC+10, anti...@math.uni.wroc.pl wrote:

> > They bother me. I'm looking for pure public
> > domain software with no caveats.
>
> So you find MIT licence too problematic? Note

Yes I do. I don't want to see "copyright"
anywhere at all. I want to instead see an
explicit "released to the public domain"
with no caveats. For whatever reason people
are unwilling to write that on their code,
I am unwilling to accept anything less.

> that "public domain" has caveats too: there
> are examples of things taken out of "public domain"...

I'm after things that are of the same
status as Shakespeare's "Hamlet" -
unambiguously released to the public domain.

> Or do you realy mean that you want software that
> you wrote yourself and can give away to others?

No, I don't care who writes it so long as
they unambiguously place it in the public domain.

> You can write nontrivial things in pure C90.
> My points are:
> - if you drop requirement of compatiblity ("recreating")
> old systems your task would be much easier

I want to traverse the computer industry
in both directions - forward and back.

I want to be able to recreate the computer
industry from scratch. ie if there was some
sort of disaster, I want to be able to outline
what hardware and software needs to be
created.

> - if this is intended to be more than intelectuctal
> excercise, then you probably want something that
> works natively or semi-natively on modern
> hardware

Pure C90 applications will work on modern
hardware too. I expect "long" to be 64 bits
and "void *" to be 64 bits.

> - if you want do things that people want you
> need to handle hardware

I would like to see how far I can go with
C90. E.g. I only need to diverge slightly
from C90 in order to run a BBS.

> Also, nontrivial sofware uses libraries. Library
> may be pure C90, but code that uses it is only
> conditonaly C90 -- it depends on presence of the
> library.

I am happy to start building up libraries
of C90 functionality, e.g. recreating CXL,
a text windowing system for MSDOS. I want
a 32-bit version of it so that BBS messages
can be read easily.

Thankyou for your messages. I am trying to
clarify what I am trying to achieve.
Basically in 1990 when I was using BBSes
and writing C90 code, I wondered if it was
possible to replace everything I was using
with public domain code. After achieving
that I might like to write a cross-compiler
to target the 6502 or some other 8-bit
processor. ie I want to go backwards, not
just forwards. I don't want to use kludges
like overlays, I want to do cross-compilation
instead.

BFN. Paul.

Keith Thompson

unread,

May 3, 2020, 9:38:57 PM5/3/20

to

Paul Edwards <muta...@gmail.com> writes:
> On Monday, 4 May 2020 10:35:50 UTC+10, anti...@math.uni.wroc.pl wrote:
>> > They bother me. I'm looking for pure public
>> > domain software with no caveats.
>>
>> So you find MIT licence too problematic? Note
>
> Yes I do. I don't want to see "copyright"
> anywhere at all. I want to instead see an
> explicit "released to the public domain"
> with no caveats. For whatever reason people
> are unwilling to write that on their code,
> I am unwilling to accept anything less.

Not many software projects use public domain. SQLite is perhaps the
most prominent one that does. If you want to do the same, you might
want to take a look at how they deal with it.

https://sqlite.org/copyright.html

I presume you're aware that means I could grab a copy of your code,
remove your name from it, and include it in a commercial product.
(Disclaimer: I am not a lawyer. I am not offering advice or
suggesting that using public domain is a good or bad idea.)

Licensing issues are at best marginally topical in clc, so I suggest
not carrying on a long discussion about them here.

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

Paul Edwards

unread,

May 3, 2020, 9:51:31 PM5/3/20

to

On Monday, 4 May 2020 11:38:57 UTC+10, Keith Thompson wrote:

> Not many software projects use public domain.

Yes, which is why PDOS/386 has little competition,
and why I have to do so much of the work myself,
so that the public owns an operating system.

> I presume you're aware that means I could grab a copy of your code,
> remove your name from it, and include it in a commercial product.

They are welcome to do that. I'm glad that
they find the code useful.

BFN. Paul.

David Brown

unread,

May 4, 2020, 3:36:26 AM5/4/20

to

On 04/05/2020 02:54, Paul Edwards wrote:
> On Monday, 4 May 2020 10:35:50 UTC+10, anti...@math.uni.wroc.pl wrote:
>
>>> They bother me. I'm looking for pure public
>>> domain software with no caveats.
>>
>> So you find MIT licence too problematic? Note
>
> Yes I do. I don't want to see "copyright"
> anywhere at all. I want to instead see an
> explicit "released to the public domain"
> with no caveats. For whatever reason people
> are unwilling to write that on their code,
> I am unwilling to accept anything less.
>

Are you limiting all this to your particular country (I'm guessing that
is the USA - it usually is when people don't appear to appreciate that
there is a world outside their borders)?

The concept of "Public domain", and what it means, varies hugely from
country to country. AFAIK, Germany does not have the concept at all -
the software will be automatically copyright the author, and while you
can transfer the copyrights you cannot remove them. (I hope someone
more familiar with German rules can correct me if I'm wrong.) In some
countries, I could take your "Public domain" software, put my own
copyright notice on it, and then sue you for copyright infringement if
you don't pay me a license.

Maybe you know all about this sort of stuff - but usually when people
say "we'll release this as public domain", they mean "I want it to be as
free as possible, so people can use it as they want", without giving the
matter appropriate thought and research.

This group is probably not the best place to get the information you
require - I am merely encouraging you to ask the right questions and
think about things a bit more, rather than trying to give you the answers.

>> that "public domain" has caveats too: there
>> are examples of things taken out of "public domain"...
>
> I'm after things that are of the same
> status as Shakespeare's "Hamlet" -
> unambiguously released to the public domain.
>

You have to die, and then wait for between 50 and 100 years (depending
on the country). (For some countries, "expired copyright" is very
different from "never had copyright" or "copyrights explicitly revoked".)

>> Or do you realy mean that you want software that
>> you wrote yourself and can give away to others?
>
> No, I don't care who writes it so long as
> they unambiguously place it in the public domain.
>
>> You can write nontrivial things in pure C90.
>> My points are:
>> - if you drop requirement of compatiblity ("recreating")
>> old systems your task would be much easier
>
> I want to traverse the computer industry
> in both directions - forward and back.
>
> I want to be able to recreate the computer
> industry from scratch. ie if there was some
> sort of disaster, I want to be able to outline
> what hardware and software needs to be
> created.

That is perhaps a /little/ ambitious. You are not the first person to
want something like this. You'll have the same trouble they all do -
it's a project that would take tens of thousands of dedicated people,
without hope of getting any kind of financial backing, and every
volunteer would have different opinions on how to do it. Concentrate on
/one/ thing, and don't reveal your plans for world domination until you
have built up a substantial following.

I can't honestly say I understand what you are trying to do here, much
less /why/, but I wish you luck anyway. As long as you have fun working
on it!

James Harris

unread,

May 4, 2020, 3:48:13 AM5/4/20

to

On 04/05/2020 08:36, David Brown wrote:

...

> In some
> countries, I could take your "Public domain" software, put my own
> copyright notice on it, and then sue you for copyright infringement if
> you don't pay me a license.

Which countries are those?

AIUI the problem with copyright is not putatively having it but
defending it. PD ought to be one of the best ways of avoiding legal
action either as plaintiff or defendant ... but it may not be.

--
James Harris

Paul Edwards

unread,

May 4, 2020, 4:12:47 AM5/4/20

to

On Monday, 4 May 2020 17:36:26 UTC+10, David Brown wrote:

> Are you limiting all this to your particular country (I'm guessing that
> is the USA - it usually is when people don't appear to appreciate that
> there is a world outside their borders)?

I'm Australian, and I provide CC0 as an
alternative for anyone who finds "public
domain" problematic.

> The concept of "Public domain", and what it means, varies hugely from
> country to country. AFAIK, Germany does not have the concept at all -
> the software will be automatically copyright the author, and while you
> can transfer the copyrights you cannot remove them. (I hope someone
> more familiar with German rules can correct me if I'm wrong.) In some
> countries, I could take your "Public domain" software, put my own
> copyright notice on it, and then sue you for copyright infringement if
> you don't pay me a license.

You can't sue me (and win) if it is
established that I was the one who wrote
the software.

Establishing who actually wrote it is a
problem that is common to all code, not
just public domain code.

> > I'm after things that are of the same
> > status as Shakespeare's "Hamlet" -
> > unambiguously released to the public domain.
> >
>
> You have to die, and then wait for between 50 and 100 years (depending
> on the country).

Or I can release it to the public domain now.

> > I want to be able to recreate the computer
> > industry from scratch. ie if there was some
> > sort of disaster, I want to be able to outline
> > what hardware and software needs to be
> > created.
>
> That is perhaps a /little/ ambitious. You are not the first person to
> want something like this. You'll have the same trouble they all do -
> it's a project that would take tens of thousands of dedicated people,
> without hope of getting any kind of financial backing, and every
> volunteer would have different opinions on how to do it.

I don't see why understanding computers
sufficiently to be able to OUTLINE a path
to recreating computers as they were in 1991
would require tens of thousands of people.

BFN. Paul.

Bart

unread,

May 4, 2020, 6:49:33 AM5/4/20

to

On 04/05/2020 01:54, Paul Edwards wrote:
> On Monday, 4 May 2020 10:35:50 UTC+10, anti...@math.uni.wroc.pl wrote:

>> - if this is intended to be more than intelectuctal
>> excercise, then you probably want something that
>> works natively or semi-natively on modern
>> hardware
>
> Pure C90 applications will work on modern
> hardware too. I expect "long" to be 64 bits
> and "void *" to be 64 bits.

unread,

May 4, 2020, 9:40:38 AM5/4/20

to

As I said before, I still don't really understand your aims here or what
you mean by a "C90 environment". For my own coding, I really dislike
having to go back to C90 instead of C99, and can't understand why anyone
would /choose/ to use C90, but you are doing all this for your own
reasons, not for my use.

Bart

unread,

May 4, 2020, 9:47:17 AM5/4/20

to

Recreate all the software, or all the hardware too?

The latter I think would be a little harder, if you had to reinvent
integrated circuits from scratch, and work your way up to the
state-of-the-art in 1991 (which was, what, the 80486 processor with a
million transistors?).

For the software, you are relying on certain sets of tools to already
exist, such as compilers. Those compilers generally need to work on an
existing machine with at least a simple OS, providing a file system,
keyboard entry and a display.

So it sounds like whatever it is you want to recreate, will already need
to exist. Otherwise it will be a long process.

(I've done something like that, but on a tiny scale. The start point was
a bare Z80 (the actual chip; I had to create the circuit for it) with no
existing software, and to end up with sofware including a crude editor,
assembler, compiler and programs that could work with 3D vector graphics
and imaging, all out of nothing. (No OS though.)

I couldn't however do it today. Apart from having lost the knack, many
parts would be difficult to source.)

Paul Edwards

unread,

May 4, 2020, 10:09:06 AM5/4/20

to

On Monday, 4 May 2020 23:47:17 UTC+10, Bart wrote:

> > I don't see why understanding computers
> > sufficiently to be able to OUTLINE a path
> > to recreating computers as they were in 1991
> > would require tens of thousands of people.
>
> Recreate all the software, or all the hardware too?

The hardware too. I'd like to be able to
recommend a processor/instruction set to use.
Perhaps multiple processors if required.

> The latter I think would be a little harder, if you had to reinvent
> integrated circuits from scratch,

unread,

May 4, 2020, 1:18:56 PM5/4/20

to

On Tuesday, 5 May 2020 02:58:56 UTC+10, Bart wrote:

> So it picks and chooses its compilers. (I assume size_t is not part of C90?)

C90 requires size_t to be defined in those
header files you saw.

> Some compilers don't define __WIN32__, but do define at least one of
> __WIN32, WIN32 or _WIN32. So size_t stays undefined.

You should be providing __32BIT__

> Apart from size_t, pdos.c doesn't see these names:
>
> pdos.c:334: warning: implicit declaration of function 'getEFLAGSAndDisable'
> pdos.c:336: warning: implicit declaration of function 'setEFLAGS'
> pdos.c:476: warning: implicit declaration of function 'loadPageDirectory'
> pdos.c:486: warning: implicit declaration of function 'switchFromToThread'
> pdos.c:767: warning: implicit declaration of function 'enablePaging'
> pdos.c:2241: warning: implicit declaration of function 'readCR2'
> pdos.c:3049: warning: implicit declaration of function 'call32'
> pdos.c:3728: warning: implicit declaration of function '__start'
> pdos.c:4714: warning: implicit declaration of function 'inp'
> pdos.c:4720: warning: implicit declaration of function 'outp'

Those are only warnings, and the code
is assembler, so you will get link
errors for them.

> It's a while since I glimpsed this side of C, and I think I'm going to
> bail out again now ...

I think the code did pretty well, all things
considered. :-)

BFN. Paul.

Öö Tiib

unread,

May 4, 2020, 2:02:02 PM5/4/20

to

Interesting. What I meant with exponential was that in most
implementations the containers increase the previous capacity
two-fold when running out of it. So if I modify your program
a bit ...:

#include <iostream>
#include <string>
#include <cstring>

using namespace std;

int main()
{
string str;

string appendStr = "hello world";
size_t cap = -1;
for( size_t i = 0; i < 1000; ++i )
{
if (str.capacity() != cap)
{
cap = str.capacity();
cout << "(" << i << ") " << cap << ", ";
}

str += appendStr;
}
}

... then I typically get something like that:

(0) 15, (2) 30, (3) 60, (6) 120, (11) 240, (22) 480, (44) 960,
(88) 1920, (175) 3840, (350) 7680, (699) 15360,

The "more coarse" was likely result of the initial capacity
being different between different compilers?

Other thing that standard says nothing but is quite common is
that the std::unordered_ containers tend also to grow about
two-fold but keep the bucket count prime.

Keith Thompson

unread,

May 4, 2020, 4:57:35 PM5/4/20

to

Bart <b...@freeuk.com> writes:
[...]

> So it picks and chooses its compilers. (I assume size_t is not part of C90?)

size_t is defined in C90. It's declared in <stddef.h> and several other
headers, including <string.h>, <stdlib.h>, etc. (The implementations of
those headers have to play some tricks to avoid multiple definitions.)

BGB

unread,

May 5, 2020, 12:38:07 PM5/5/20

to

On 5/4/2020 8:47 AM, Bart wrote:
> On 04/05/2020 09:12, Paul Edwards wrote:
>> On Monday, 4 May 2020 17:36:26 UTC+10, David Brown wrote:
>
>>> That is perhaps a /little/ ambitious. You are not the first person to
>>> want something like this. You'll have the same trouble they all do -
>>> it's a project that would take tens of thousands of dedicated people,
>>> without hope of getting any kind of financial backing, and every
>>> volunteer would have different opinions on how to do it.
>>
>> I don't see why understanding computers
>> sufficiently to be able to OUTLINE a path
>> to recreating computers as they were in 1991
>> would require tens of thousands of people.
>
> Recreate all the software, or all the hardware too?
>
> The latter I think would be a little harder, if you had to reinvent
> integrated circuits from scratch, and work your way up to the
> state-of-the-art in 1991 (which was, what, the 80486 processor with a
> million transistors?).
>

In order to be successful, you need a niche. Linux is already a freeware
operating system for desktop and larger embedded systems. There is
no point trying to compete with it head on. However, whilst Linux is
acceptable for virtual machines, a typical Linux installation is
still rather greedy. You'd have to look at what people actually use
virtual machines for, and whether your operating system can either
help them do that better, or enable them to do something which is currently
unrealistic with a virtual machine running Linux. Then that could be your
niche.
4 MB of memory is pretty much nothing for an applications program these days.
However you might consider going to 640k or even 64k if you want to target
the embedded market, which is another potential niche for you, but one
I know less about.

David Brown

unread,

May 17, 2020, 4:47:52 PM5/17/20

to

On 17/05/2020 22:02, Malcolm McLean wrote:
> On Sunday, 17 May 2020 13:41:30 UTC+1, Paul Edwards wrote:
>> On Wednesday, 13 May 2020 20:02:09 UTC+10, Malcolm McLean wrote:
>>
>>> I'm reviving this. I think yur niche might be virtual machines. A
>>> virtual machine needs to be able to run with constrained
>>> resources and an OS that keeps out of the way. We know it is
>>> possible to do serious work with only a few MB of RAM and and few
>>> tens of MB hard drive space, because for many years PCs had that
>>> specification.
>>>
>>> That's nothing for a modern PC. A virutal machine could be a
>>> faitly lightweight application in the host environment.
>>
>> Can you elaborate on this please? Which OS needs to keep out of the
>> way? Would that be PDOS/386? Which currently allows applications to
>> directly manipulate I/O ports.
>>
> Virtual machines are usually hosted on a fully-featured, modern OS
> like Windows or Apple;s OSX, running on a desktop machine with
> several gigabytes of memory and several hundred gigabytes of backing
> store. The virtual machine itself is just an ordinary application,
> running under the host OS. However there's a real need for virtual
> machines to be light on resources. Their memory and disk space is
> memory and disk space that cannot be used by the host machine. So the
> OS on the virtual machine needs to keep out of the way. It can't be
> hogging huge tracts of memory or hard disk space.
>

Almost all the virtual machines I run are full Linux systems, and I
often have dozens on a small server - precisely because the memory and
disk space /can/ be used by the host machine or other virtual machines.
And they are not hosted on desktops at all. There are lots of
different types of virtual machines for different purposes.

I am not at all sure why you would want a virtual machine OS to "keep
out of the way" any more than you would want a desktop OS to keep out of
the way - you often want the OS out of the way whether you are using VMs
or a "normal" OS. You want your OS to support access to your hardware,
and to support the software you want to use - anything less is not good
enough, and anything more is a waste.

>>
> In order to be successful, you need a niche. Linux is already a
> freeware operating system for desktop and larger embedded systems.

Linux is not a "freeware" operating system.

> There is no point trying to compete with it head on. However, whilst
> Linux is acceptable for virtual machines, a typical Linux
> installation is still rather greedy.

What is "typical" ? I run Linux on desktops with 32GB memory and 3D
graphics cards, and on routers with 8 MB flash and 32 MB ram. Until
about five years ago, I had a perfectly functional file server with a
Pentium 90 cpu and 64 MB ram.

If you want a modern Linux desktop with powerful applications, it will
make use of whatever hardware you give it - but you'll be hard pushed to
buy a current x86 PC that isn't powerful enough. And if you don't want
that, don't install it - put on what you need. (The same goes for FreeBSD.)

Linux is not Windows - you get what you want, not what a corporation
decides you should have.

> You'd have to look at what
> people actually use virtual machines for, and whether your operating
> system can either help them do that better, or enable them to do
> something which is currently unrealistic with a virtual machine
> running Linux. Then that could be your niche. 4 MB of memory is
> pretty much nothing for an applications program these days. However
> you might consider going to 640k or even 64k if you want to target
> the embedded market, which is another potential niche for you, but
> one I know less about.
>

The OP would not be targeting embedded systems (assuming he knows
anything about them).

The only niche for the OP is for people who think adding otherwise
meaningless restrictions and limitations makes a problem more of a
challenge, and therefore more fun. And if he or others enjoy it, then
that is absolutely great. The world is full of people making things
more difficult for themselves as a challenge, and enjoying doing it.
But there is no /practical/ niche or use of it - no more than there is a
practical use for climbing Mt. Everest without oxygen, or rowing across
the Atlantic in a bathtub.

Paul Edwards

unread,

May 17, 2020, 4:54:13 PM5/17/20

to

On Monday, 18 May 2020 06:02:12 UTC+10, Malcolm McLean wrote:

> The virtual machine itself is just an ordinary application, running
> under the host OS.

PDOS/386 requires an emulator like Bochs
or qemu to run under. Are you saying that
a virtual machine doesn't need an emulator?
When the application under PDOS/386 does
an INT 21H to request a service, something
needs to handle that instruction and pass
it on to PDOS/386 to interpret.

> In order to be successful, you need a niche. Linux is already a freeware
> operating system for desktop and larger embedded systems. There is
> no point trying to compete with it head on.

PDOS is public domain, not just freeware.
So the niche I had in mind was commercial
vendors who wanted to build an operating
system for some reason, but didn't want to
be bound by any license.

> However you might consider going to 640k or even 64k if you want to target
> the embedded market, which is another potential niche for you, but one
> I know less about.

My OS is more than 64k already. The FAT
handling code is 19k, including LFN support.
I think a different OS would be required
for embedded systems, but I don't know much
about that either.

I'm also thinking of just spending my time
replacing the copyrighted freeware components,
including the compiler, with public domain
versions.

BFN. Paul.

Paul Edwards

unread,

May 17, 2020, 5:03:59 PM5/17/20

to

On Monday, 18 May 2020 06:47:52 UTC+10, David Brown wrote:

> But there is no /practical/ niche or use of it - no more than there is a
> practical use for climbing Mt. Everest without oxygen, or rowing across
> the Atlantic in a bathtub.

If that is the conclusion, ie PDOS/386
serves no practical use, then so be it.
That's what I get to find out now.

But I just find it disturbing that after
decades of computing, the public does not
own much, e.g. there's not many other
self-hosting public domain operating
systems written in C90. And no public
domain compiler that can handle C90
code and generate 80386 code either.

BFN. Paul.

Malcolm McLean

unread,

May 17, 2020, 7:45:10 PM5/17/20

to

On Sunday, 17 May 2020 21:54:13 UTC+1, Paul Edwards wrote:
> On Monday, 18 May 2020 06:02:12 UTC+10, Malcolm McLean wrote:
>
> > The virtual machine itself is just an ordinary application, running
> > under the host OS.
>
> PDOS/386 requires an emulator like Bochs
> or qemu to run under. Are you saying that
> a virtual machine doesn't need an emulator?
> When the application under PDOS/386 does
> an INT 21H to request a service, something
> needs to handle that instruction and pass
> it on to PDOS/386 to interpret.
>

In the x86 world, a virtual machine usually runs
another x86 OS as guest. So it doesn't need to do
emulation in the normal sense of the word. Whilst
I'm not sure how all the details work, essentially
the VM lets the host applications run native machine
code.

>
> > In order to be successful, you need a niche. Linux is already a freeware
> > operating system for desktop and larger embedded systems. There is
> > no point trying to compete with it head on.
>
> PDOS is public domain, not just freeware.
> So the niche I had in mind was commercial
> vendors who wanted to build an operating
> system for some reason, but didn't want to
> be bound by any license.
>

If a PC is only running one program, plus maybe
a few utilities, someone might want to package
your OS with their user oode and ship the whole
lot as a unit which they control. That could be
another niche for you. But you'd have to persuade
commercial decision makers that this was a viable
route to take.

>
> > However you might consider going to 640k or even 64k if you want to target
> > the embedded market, which is another potential niche for you, but one
> > I know less about.
>
> My OS is more than 64k already. The FAT
> handling code is 19k, including LFN support.
> I think a different OS would be required
> for embedded systems, but I don't know much
> about that either.
>

If you want to support computers with 64K of
address space, you'd have to radically simplify
the file system code. Which would mean dropping
support for most standard formats. However
embedded devices don't normally have to support
mounting or arbitrary backing store. Whilst they
might have a file system, it's very constrained.

>
> I'm also thinking of just spending my time
> replacing the copyrighted freeware components,
> including the compiler, with public domain
> versions.
>

I think writing your own C compiler would be a
separate project, with only an incidental connection
to the operating system. Several people here have
written their own compilers. You could maybe look
at adapting something that already exists to your
needs.

Paul Edwards

unread,

May 17, 2020, 8:28:02 PM5/17/20

to

On Monday, 18 May 2020 09:45:10 UTC+10, Malcolm McLean wrote:

> I think writing your own C compiler would be a
> separate project, with only an incidental connection
> to the operating system.

Well the original goal is that I wondered
if I could replace everything I was doing
(e.g. dialing BBSes) with public domain
software. This was around 1994. I wrote a
BBS mailprocessor and started work on a
C library, and then the OS.

I made a decision to focus first on what
someone would actually want to ship, to
make sure they could have a pure public
domain distribution. ie the boot sector,
the OS. Then they could add their own
proprietary programs to the mix.

The compiler was not so important, because
you don't generally need to give an end
user a compiler to use your software.

But now that the OS has become self-hosting
I am becoming more interested in the
compiler. I am missing an assembler and a
linker for PDOS/3X0 (mainframe) so I will
probably look at that instead of the C
compiler for now. Note that I ported
GCC 3.2.3 to the mainframe, and use the
same version for PDOS/386. I made the
compiler C90-compliant in order to do that.

Anyway, interesting times! I'll probably
start by making PDOS/386 more bullet-proof
before moving on to making PDOS/3X0
self-hosting too, with assembler and linker.
In fact, I think I will make it a design
goal for the mainframe assembler and linker
to be able to run on an ASCII machine, not
just the native EBCDIC, while still producing
an executable that works on EBCDIC.

BFN. Paul.

Ian Collins

unread,

May 17, 2020, 9:25:22 PM5/17/20

to

On 18/05/2020 13:23, Ian Collins wrote:

> On 18/05/2020 08:02, Malcolm McLean wrote:
>> On Sunday, 17 May 2020 13:41:30 UTC+1, Paul Edwards wrote:
>>> On Wednesday, 13 May 2020 20:02:09 UTC+10, Malcolm McLean wrote:
>>>
>>>> I'm reviving this. I think yur niche might be virtual machines.
>>>> A virtual machine needs to be able to run with constrained resources
>>>> and an OS that keeps out of the way. We know it is possible to do
>>>> serious work with only a few MB of RAM and and few tens of MB hard drive
>>>> space, because for many years PCs had that specification.
>>>>
>>>> That's nothing for a modern PC. A virutal machine could be a faitly
>>>> lightweight application in the host environment.
>>>
>>> Can you elaborate on this please? Which OS
>>> needs to keep out of the way? Would that be
>>> PDOS/386? Which currently allows applications
>>> to directly manipulate I/O ports.
>>>
>> Virtual machines are usually hosted on a fully-featured, modern OS like
>> Windows or Apple;s OSX, running on a desktop machine with several
>> gigabytes of memory and several hundred gigabytes of backing store.
>> The virtual machine itself is just an ordinary application, running
>> under the host OS.
>

> One class of VM meets that description but not all.

>
>> However there's a real need for virtual machines to be light on resources.
>

> The need is already met. Solaris derived platforms have has lightweight
> zones since the early 2000s. Linux now has containers.

>
>> Their memory and disk space is memory and disk space that cannot be used
>> by the host machine. So the OS on the virtual machine needs to keep out of
>> the way. It can't be hogging huge tracts of memory or hard disk space.
>

> Zones and containers share resources with the host OS.

>
>> However, whilst Linux is
>> acceptable for virtual machines, a typical Linux installation is
>> still rather greedy.
>

> BusyBox
>

David Brown

unread,

May 18, 2020, 2:54:12 AM5/18/20

to

On 17/05/2020 23:03, Paul Edwards wrote:
> On Monday, 18 May 2020 06:47:52 UTC+10, David Brown wrote:
>
>> But there is no /practical/ niche or use of it - no more than there is a
>> practical use for climbing Mt. Everest without oxygen, or rowing across
>> the Atlantic in a bathtub.
>
> If that is the conclusion, ie PDOS/386
> serves no practical use, then so be it.

That is my opinion, yes. But as I said, that doesn't necessarily mean
you shouldn't work on it - do it if you are enjoying it. But don't do
it if you think there is going to be some practical use of it, or you
want it to be popular, or you think it will a useful end result.

> That's what I get to find out now.
>
> But I just find it disturbing that after
> decades of computing, the public does not
> own much, e.g. there's not many other
> self-hosting public domain operating
> systems written in C90. And no public
> domain compiler that can handle C90
> code and generate 80386 code either.
>
> BFN. Paul.
>

The public does not "own" any public domain software. And the public
does not /want/ public domain C90 compilers. Anyone who wants quality
C compiler for zero cost can get one under the two main free license
types - BSD (for clang/llvm/ and GPL (for gcc). There would be almost
no advantage for anyone in having a public domain compiler (and maybe
some direct disadvantages).

> I would
> have expected an organization like the CSIRO to be tasked with
> remedying that situation, but no government has felt it desirable
> that the public owns the means to program. If ever there is a reason
> we need to fall back to public domain software, the cupboard is
> mostly bare.
>

What reasons are you imagining here? What do you think people can do
with a public domain compiler that the could not do with a BSD or GPL
licensed tool?

> The fact that most people aren't willing to release their software to
> the public domain means that they see something that is possible if
> they do so, and they don't want that possibility to exist. I want to
> see that possibility - whatever it may be - to exist!
>

The main that is possible with public domain software is for others to
take it, slap their own copyright notice on it, and sue the original
author if they try to use, distribute or sell the code they wrote. Lots
of people (and companies) are happy to give away their work for free
with the condition that it stays free - and some are willing to do so
with just the condition that others don't claim they own it.

> Furthermore, I like the idea that there is just one language you need
> to learn, and you will be able to maintain an entire platform. C90 is
> the ticket. An enormous amount of effort was spent standardizing the
> language, and a truly beautiful job has been done if you read the
> standard. And an enormous amount of effort has been spent making C
> work nicely on MVS, so that truly beautiful executables can be
> created, that work as desired in both TSO and batch and on any
> RECFM.

You are using a lot of acronyms here that all appear to be specific to
IBM mainframes. That is an important, but very niche and mostly
outdated world.

>
> At the time that C90 was created, the 32-bit processor that mattered
> was the 80386.

Plus a dozen other 32-bit architectures, and with some 64-bit processors
coming along. And there were dozens of 8-bit and 16-bit architectures
that were important at the time.

> I don't think we should be coding for the 8086. I
> think that was the wrong solution for addressing memory greater than
> 64k. I think what was required was 32-bit address registers.
>
> I would like to be able to "lock in" the technology we had in 1990.
> We had the 80386SX processor, and we had an internationally-agreed
> language. What we should now be doing is adding: setlocale(LC_ALL,
> ""); to our programs and implementing international locales, to make
> C90 be as good as it can be.

Yes, C90 was an important step in programming history - but the world
has moved on since then. It is ridiculous (other than for historical
reasons, or fun) to limit anything to computing technology that is over
30 years old.

>
> I don't think we should be straying far from assembler. I think we
> should be writing code that in C that is close to what would be
> written in assembler, and to reduce the energy requirements of our
> code.

If you want that, then C (C90 or otherwise) is not the language for you.
It is a high level language, and is far from assembler.

>
> I think that we should have a clear roadmap for recreating
> civilization after a natural disaster, or if we find that we've been
> teleported to somewhere around Alpha Centauri.

If you want that, you should be working with valve computers. That is
about the last generation of technology where things are physical enough
to be worked on directly. If our society breaks down to the point where
we lose the ability to make the latest i7 or Ryzen processors, we will
also be incapable of making 80386SX processors.

> We should work to get
> a C compiler up and running as quickly as possible. The other
> programming languages that you think are superior to C should be
> written in terms of C. What we need is for Earth to transmit the most
> basic C compiler possible to us. Or for a team to memorize it like
> some people memorize the Koran. It should be written down on paper
> waiting for the day that computers are finally created.
>
> We don't actually know how the universe has been created. I want to
> see if the universe will collapse after a public domain C compiler
> has been implemented, which enables the third world, or North Korea,
> to support their own programming platform, instead of ripping off
> someone else's copyrighted work like the Soviets did. Maybe you can
> say that I am trying to implement communism properly, because the
> actual communists are so inept.

Please don't bring politics into the discussion here.

>
> Regardless, there is a voice in my head telling me that C90 is the
> key to the universe, and that I should focus on that before moving on
> and endlessly chasing the latest fad.
>
> How many lines of C90 code would be required to write a C90 compiler
> that outputs 80386 assembler? I think we should be holding
> international competitions to try to get that number down to a
> minimum. Maybe. I'm not sure what is required, but I'm trying to see
> if I can collapse the universe, to see what happens next.
>

As always, if you think this if fun - go for it. You might find other
people who think such a competition would be fun. But don't imagine you
are doing anything useful beyond the fun.

You are not the first person to want to re-invent computing, or write
everything from scratch, based on voices in your head. Some people want
to go back to their imagined "golden age", some people think that they
alone know the best way to make a programming language, or OS, or
computer. My advice is the same:

Don't take yourself or your project too seriously.
Don't expect anyone else to take it seriously.
Don't get too ambitious - do one thing at a time, or you will not finish
anything.
Don't rely on building a community to work together - expect to be on
your own with this.
Don't neglect the rest of your life, work, and people around you.
Enjoy yourself!

anti...@math.uni.wroc.pl

unread,

May 18, 2020, 11:12:32 AM5/18/20

to

Paul Edwards <muta...@gmail.com> wrote:
>
> But this is an example of where I see
> that C90 hasn't quite been implemented
> properly. Another example is that we
> have multiple C90 compilers, but no-one
> has ever been willing to release one to
> the public domain. So the public does
> not yet own a C90 compiler.

<snip>

> How many lines of C90 code would be required
> to write a C90 compiler that outputs 80386
> assembler? I think we should be holding
> international competitions to try to get
> that number down to a minimum.

Look at:

https://bellard.org/otcc/

This is public domain C-compiler generating i386 code.
Not exactly what you ask for, as it generates machine
code in memory (no assembler involved) and has significant
gaps to full C90 converage. But it is hard to beat
size: 446 lines, 3301 characters. If you pass is trough
gcc -E to expand macros and then re-indent it the code
is actually reasonably readible.

I am not sure if you find it useful, but it is useful at
least in one aspect: it shows that compiler can be quite
small and that most lines in simple compiler go not into
compiling, but to ensure readablity, usablity and
robustness.

--
Waldek Hebisch

David Brown

unread,

May 18, 2020, 11:16:04 AM5/18/20

to

On 18/05/2020 15:52, Manfred wrote:
> On 5/18/2020 8:54 AM, David Brown wrote:
>> And the 386 architecture is a dead-end. It exists now for historic
>> reasons, and on old long-running systems. It is useful that software
>> (such as compilers) continue to support it so that old working systems
>> can continue to work, but it is pointless writing anything /new/ for it.
>
> Extrapolating from the discussion, I don't think this is accurate.
> Granted, the 80386 processor and friends (486, Pentium etc.) are
> definitely out of market, but if you talk about architecture then it is
> a more general topic than just commercial processors.
>
> In fact the x64 architecture is substantially the 386 architecture
> wherein bus size, register size and number have been expanded, but if
> you look at the instruction set, which is the driving factor for
> software architecture, it is pretty much mapped onto the 386.

Of course the x86_64 architecture is a descendant of x86_32, and has
lots in common. But the 32-bit only x86 world is now obsolete.

>
> The main architectural progress in newer processors is about caching,
> pipelines, multiprocessing and, to a lesser extent, virtualization,
> however these features are mostly transparent to the instruction set.
>
> Now, it might be argued that the x64 architecture is not optimal, it
> might have less potential than others, however at least from the point
> of view of PC market share it is still leading.

Not optimal? The x86 world is the archetypical case showing that you
/can/ polish a turd. The architecture was build badly on outdated ideas
when the 8086 first appeared, and has been extended in an uncontrolled
and unplanned patchwork ever since (AMD did a slightly less bad job when
making the 64-bit extensions). But current devices are extraordinary
feats of engineering, and work amazingly despite the architecture.

Paul Edwards

unread,

May 18, 2020, 11:17:54 AM5/18/20

to

On Tuesday, 19 May 2020 00:44:41 UTC+10, anti...@math.uni.wroc.pl wrote:

> Still, I find your technical choices rather odd. In 1994
> it was well known that BIOS+DOS combo was highly
> suboptimal. This combo made sense in 1982 when
> there was problem of fiting everthing into available
> RAM and preformace loss was inevitable tradeoff for
> limiting RAM use, but was obsolete in 1994. You
> could argue that DOS is simple and this siplicity
> has some merit.

Well another driver is that (decades ago)
I saw someone write "until DOS itself is
made 32-bit, DOS extenders are just a kludge",
and I always wondered when DOS was going to
be made 32-bit. It never happened, but I
think it should have happened, so I made
it happen myself. Proof of concept.

> Well, some but not much: there
> are simpler designs. In 1982 there was UCSD p-system,
> which at least at conceptual level was simpler,
> but UCSD set high price for it so it lost to much
> cheaper DOS. But if you strive for simplicity
> p-system is better thing to duplicate. There

I am not necessarily striving for simplicity.
I have a hard time describing what I am
striving for, it's more a case of "just what
comes naturally". I wish I had a better grasp
of what I want.

I looked up p-system and it seems to be Pascal
and interpreted, but I don't want either of
those things.

> You also intend your PDOS to run on mainframe. That

Note that PDOS/3X0 already exists, it's not
just an intention.

> is strange because mainframe design was specificaly
> optimized to allow parallel operation on I/O subsystem
> with running programs. OTOH DOS/BIOS blocks programs
> for I/O.

I block (wait for interrupt) on the mainframe
too. My goal is not to have a perfect system
in version 1.0. My goal is to have it
self-hosting in version 1.0 so that someone
can take a mainframe onto a desert island
and spent the next 50 years making PDOS/3X0
the best multitasking operating system ever.

After I have made it self-hosting I may
stop development and find a new platform,
like ARM, to make self-hosting, so that
an ARM computer can be taken to a different
desert island (or planetary system) to be
worked on.

> due to emulation. But proportions would change drasticaly
> if you attempt to run on real hardware. Hardware now
> is faster so PDOS probably will run faster on modern harware
> than DOS running on 1994 hardware, but probably slower
> than good OS on hardware from 1994 and definitly slower
> than what is possible on modern hardware.

I'm not that worried about performance.
That can be improved in time, and it is
good enough that it was written in C,
so there is a good base.

> Another strange thing is your s380 target. You apparently
> are willing to throw out compatibility to real mainframes
> as it has no equivalent in real word.

Applications written for S/380 will also
run on z/OS and MVS 3.8J. All it does is
provide lots of memory (4 GiB with AMODE
32 in fact) to those using emulation anyway.

BFN. Paul.

Manfred

unread,

May 18, 2020, 11:32:48 AM5/18/20

to

On 5/18/2020 4:41 PM, Paul Edwards wrote:
> On Tuesday, 19 May 2020 00:26:03 UTC+10, Manfred wrote:
>
>> popular (without offending the Tiobe index), however it looks like the
>> OP is looking for a self-sustained solution rather than a popular one.
>
> Hi Manfred. Thankyou for helping to clarify
> my goal. I only have a vague sense.
>
> Could you elaborate on what "self-sustained"
> means to you? It sounds like what I want, but
> I'm not sure.

I basically mean that it can run on its own, free of dependencies.
Obviously not in absolute terms, but rather relative to the technology
level - for example, at the level of source code, a language that does
not need another language for the executable to run.

In other words:
From the perspective of the end user: executables that can be fed to a
hardware processor with no other dependency than the target OS (and
underlying hardware).
From the perspective of the programmer: a language and compiler that
can generate such executables. Such an executable can be the compiler
itself, which closes the loop of code generation.
From the perspective of the systems designer: a language and compiler
that can build an OS.

>
> You are right that I'm not aiming for
> popularity.

But popularity shouldn't be underestimated either.
Apart from fashion, popularity is also a measure of usefulness.

For example, you seem to value such a project as part of a "clear
roadmap for recreating civilization", I don't - I don't think that
civilization is (nor should be) based on computers.

Or you seem to consider the chance that "we find that we've been
teleported to somewhere around Alpha Centauri" - I consider that science
fiction, which is fun, but like any form of art is actually interesting
only as long as it stimulates some insight into real life.

>
> Thanks. Paul.
>

Paul Edwards

unread,

May 18, 2020, 11:52:39 AM5/18/20

to

On Tuesday, 19 May 2020 01:10:11 UTC+10, David Brown wrote:

> don't take this as an insult) uninformed and inexperienced. There were
> portable languages before C90, and portable languages afterwards, and

I am not aware of any portable languages
that were standardized by ISO at the time
that C90 was published, and are superior
to C90. An enormous amount of effort has
gone into C90, allowing high performance
I/O to be done on both mainframe and PC
with the same source code.

> be a much poorer world with just one "standard" system. Amongst other
> things, C is not a good choice of language for learning to program.

I agree with that, but it's still the fact
that you need to learn C90 to get your
ticket to the world.

> And I can't see any benefits in C90 over C99 - C99 is a significantly
> better language in many ways. (C11 is better again, though the
> differences are smaller except in support for multi-threading and
> atomics. C18 has even fewer differences.) I can't imagine why anyone
> would /choose/ C90 over C99 as a language.

Because C90 hasn't been done to my satisfaction yet.

> > Now there is no commercially-used programming platform that doesn't
> > have a free or standard C compiler available to it. So you can write
> > your tools in C90 and be confident that they will work wherever you
> > go.
>
> You can write them in C99 too, in almost every case. But no, you most
> certainly can't be confident that your C code will run everywhere -
> unless you rely on pure standard C, which is rarely sufficient for any
> purpose.

GCC 3.2.3 is 400,000 lines of C code. It reads
in a bunch of text files, and outputs a text
file. It can be, and is now, written in C90.

> have no guarantees about any library support. But the other viewpoint
> here is that SDCC and other such embedded compilers are utterly
> irrelevant to a general-purpose PC operating system.

It's not irrelevant to me. It's all part of
implementing C90. The standard was written,
but decades on, still hasn't been implemented
fully, properly, yet.

> > I would
> > have expected an organization like the CSIRO to be tasked with
> > remedying that situation, but no government has felt it desirable
> > that the public owns the means to program. If ever there is a reason
> > we need to fall back to public domain software, the cupboard is
> > mostly bare.
> >
>
> What reasons are you imagining here? What do you think people can do
> with a public domain compiler that the could not do with a BSD or GPL
> licensed tool?

Ask the BSD/GPL people - they're the ones who
think public domain will allow people to do
something they don't want them to do.

> > The fact that most people aren't willing to release their software to
> > the public domain means that they see something that is possible if
> > they do so, and they don't want that possibility to exist. I want to
> > see that possibility - whatever it may be - to exist!
>
> The main that is possible with public domain software is for others to
> take it, slap their own copyright notice on it, and sue the original
> author if they try to use, distribute or sell the code they wrote.

No, that's just scaremongering. The problem
of establishing original authorship exists
whether it is public domain or copyrighted
code. And no-one can stop me from distributing
etc my original code. I am happy for people
to maintain their own copyrighted derivative
of my code.

> > At the time that C90 was created, the 32-bit processor that mattered
> > was the 80386.
>
> Plus a dozen other 32-bit architectures, and with some 64-bit processors
> coming along. And there were dozens of 8-bit and 16-bit architectures
> that were important at the time.

GCC 3.2.3 is a 3 MB executable. I expect this
to be able to run, instead of having kludges
to squeeze a sub-standard compiler on to
inappropriate hardware. So to me, the world
begins with 32-bit processors.

> Yes, C90 was an important step in programming history - but the world
> has moved on since then. It is ridiculous (other than for historical
> reasons, or fun) to limit anything to computing technology that is over
> 30 years old.

The world has moved on with fads, without first
securing C90, in my opinion.

> > I don't think we should be straying far from assembler. I think we
> > should be writing code that in C that is close to what would be
> > written in assembler, and to reduce the energy requirements of our
> > code.
>
> If you want that, then C (C90 or otherwise) is not the language for you.
> It is a high level language, and is far from assembler.

Sorry for my poor English. What I meant was
you can generate the assembler from the C
code, and the generated assembler is similar
to what an assembler programmer would write.

I think we should be aiming for efficiency.

unread,

May 18, 2020, 3:48:22 PM5/18/20

to

Moreover, both DOS and MVS (upon which PDOS/386 appears to be based)
are far from state of the art in operating systems.

Scott Lurndal

unread,

May 18, 2020, 3:51:54 PM5/18/20

to

GCC has been available for Z-series (MVS) for decades (s390 target);
why did you feel a need to port it?

>
>Regardless, there is a voice in my head
>telling me that C90 is the key to the
>universe, and that I should focus on that
>before moving on and endlessly chasing the
>latest fad.

Ah, never mind.

Scott Lurndal

unread,

May 18, 2020, 3:55:59 PM5/18/20

to

Paul Edwards <muta...@gmail.com> writes:
>On Tuesday, 19 May 2020 01:10:11 UTC+10, David Brown wrote:
>
>> don't take this as an insult) uninformed and inexperienced. There were
>> portable languages before C90, and portable languages afterwards, and
>
>I am not aware of any portable languages
>that were standardized by ISO at the time
>that C90 was published, and are superior
>to C90. An enormous amount of effort has
>gone into C90, allowing high performance
>I/O to be done on both mainframe and PC
>with the same source code.
>

For some value of high performance that doesn't
include either 'high' or 'performance'..

The C90 I/O interfaces (stdio) suck rocks for performance, mainly
because of the double (and triple given the OS also buffers
in the page cache) buffering and unnecssary data movement
between the buffers.

They're good for introductary programming classes, and simple
utilities where performance isn't necessary (e.g. filters), but
seriously I/O bound applications will use host-based interfaces
like direct-io and asynchronous I/O lists (but that's the 'unix crap'
you hate so much).

Scott Lurndal

unread,

May 18, 2020, 4:02:07 PM5/18/20

to

Paul Edwards <muta...@gmail.com> writes:
>On Monday, 18 May 2020 06:02:12 UTC+10, Malcolm McLean wrote:
>

>> The virtual machine itself is just an ordinary application, running
>> under the host OS.
>

>PDOS/386 requires an emulator like Bochs
>or qemu to run under. Are you saying that
>a virtual machine doesn't need an emulator?
>When the application under PDOS/386 does
>an INT 21H to request a service, something
>needs to handle that instruction and pass
>it on to PDOS/386 to interpret.

Most virtual machines leverage hardware acceleration features
like AMD's SVM, Intel's VT-X or Arm64s virtualization mode. These
significantly accelerate performance (primarily due to the hardware
handling the guest page table translations, as well as the ability
to intercept privileged operations) without needing to dynamicallt
rewrite the guest operating system (as the original VMware and Xen did
before paravirtualization of block devices and network devices).

KVM is a popular kernel virtual machine on linux, which leverages some
of QEMU to handle emulation of certain low-bandwidth hardware devices
(e.g. serial ports) and leverages the hardware capabilities to support
paging, and leverages PCIExpress Single-Root I/O Virtualization (SRIOV)
to provide the guest OS direct access to the hardware (without the
hypervisor needing to emulate or intercept memory mapped register accesses
and inbound/outbound DMA).

Paul Edwards

unread,

May 18, 2020, 4:03:05 PM5/18/20

to

On Tuesday, 19 May 2020 05:51:54 UTC+10, Scott Lurndal wrote:

> GCC has been available for Z-series (MVS) for decades (s390 target);
> why did you feel a need to port it?

That S/390 target is for Linux, not MVS.

Dave Pitts got the i370 target to work on
USS under z/OS, but I was the one who ported
it to native MVS, including MVS 3.8J.

BFN. Paul.

anti...@math.uni.wroc.pl

unread,

May 18, 2020, 4:10:38 PM5/18/20

to

Manfred <non...@add.invalid> wrote:
> On 5/18/2020 8:54 AM, David Brown wrote:

> > And the 386 architecture is a dead-end.? It exists now for historic
> > reasons, and on old long-running systems.? It is useful that software

> > (such as compilers) continue to support it so that old working systems
> > can continue to work, but it is pointless writing anything /new/ for it.
>
> Extrapolating from the discussion, I don't think this is accurate.
> Granted, the 80386 processor and friends (486, Pentium etc.) are
> definitely out of market, but if you talk about architecture then it is
> a more general topic than just commercial processors.
>
> In fact the x64 architecture is substantially the 386 architecture
> wherein bus size, register size and number have been expanded, but if
> you look at the instruction set, which is the driving factor for
> software architecture, it is pretty much mapped onto the 386.

Well, from point of view of C programmer, i386 and ARM are almost
the same: both are little-endian 32-bit machines. And modern ARM
handles unaligned loads so some unportable i386 tricks work also
on ARM. OTOH x86_64 is 64-bit architecture and C programmer must
take it into account. Lousy use of traditional types which works
on 32-bit machines may fail on 64-bit machines. As a litte
sampler, in 'limits.h' Paul unconditinaly has:

#define LONG_MAX 2147483647L

That alone will break a lot of code...

BTW. I wrote compiler backends for x86_64 and ARM complementing
existing i386 backend. While x86_64 backend is definitely more
similar to i386 backend than each of them to ARM backend,
differences between x86_64 and i386 are not small, in particular
it was more convenient to have separate backends for i386 and x86_64,
than to try to support them with one backend using conditional
compilation.

Also, x86_64 needs its own assembler support routines. While
parts could be almost mechanicaly translated replacing 'l' by
'q' and 'e' by 'r' so that say

popl %ecx

is replace by

popq %rcx

some parts are quite different due to different calling convention
and differences in FPU.

--
Waldek Hebisch