Post by ***@yahoo.com.au [hercules-os380]Again, not relevant. You're asking about making something
unix-compatible, not making it into a generic C platform.
No, that is not correct. I am just leery
about deviating from Unix when I have
been explicitly told that those who
deviate from Unix will always end up
with something worse (like Chavez
But you did say "reimplementing unix".
Only in the subject line, and only as a
summary of *someone else's* line:
"those who do not understand Unix
are condemned to reimplement it
badly".
I don't want to be one of those people
who didn't understand Unix so went off
on some half-cocked alternative only
to find out after many years that
absolutely everything I could possibly
want was already in Unix, and has
been for many decades.
The *potentially* half-cocked alternative
I am currently pursuing is PDOS/370
and z/Paulix, where everything switches
to the MVS API and EBCDIC.
You didn't say "a ground up
review of all design decisions".
Well maybe I should have.
I am simultaneously exploring PDOS/386
and PDOS/370 and wondering where Unix
slots into the above. Do I need a
PDOS-UNIX/370 or should it just be
UNIX/370? Or should it be as it is now,
just PDOS/370?
I am basically somewhat confused about
operating systems, but what I do know is
that I am starting with C90 and trying to
get C90 applications to work on "all the
above operating systems, even though
I don't actually know their names yet".
The bottom line is that unix, C, POSIX etc. (and their equivalents on
the Windows side) comprise a useful set of approximately layered
standards, which have allowed communities like the contributors to
Sourceforge, Github and so on to thrive. Move away from the standards
and you'll need to get everybody there to check their code and build
processes for compatibility, and my suspicion is that 50% of projects
would need work.
I suspect the figure is more like 98% of
projects, given that one of the target
environments I expect to be covered
is MVS 3.8j.
Every open source project should provide
*at least* 2 executables - Windows and
MVS. I don't particularly expect to see a
"Unix" executable because there is
more-or-less no such thing because of
all the different CPUs that could mean.
And that's something I'm exploring in
itself - why isn't Windows, or at least
MSDOS, running on S/370 and why
isn't MVS running on 80386? Why does
Unix run on so many different CPUs,
but Windows and MVS are unable to
match that? Did someone make a
decision at some point that tied MVS
and Windows down to their respective
CPUs? What was that specific decision?
Can that decision be reversed? If not,
what specific line of code cannot be
reversed out for eternity?
I think you said a day or so ago that one of your criticisms of fork()
is that it has to copy the memory state of the parent to make it
available as the starting state of the child.
My criticism is that it doesn't exist on
MVS or MSDOS already, and I don't
believe that MVS or MSDOS are the
ones who are deficient because they
didn't, and possibly even can't, implement
that concept.
Then, this concept is extremely low-level,
an application telling the operating system
that it wants to do an extremely complicated
operation of duplicating a load module and
all its data.
This is far, far removed from any legitimate
business application. GCC is a text
processing program that reads in a bunch
of text files and outputs a single text file.
At absolutely no point in this text processing
logic should a programmer have decided
"right, now what I really need is not the
next line of text from a text file, but instead
to have the underlying executable cloned,
plus the data copied too".
When the actual business logic that was
required at this point was "call a function
or load module or whatever that takes the
now-preprocessed file and convert it into
assembler code. (ie invoke cc1 now that
cpp has finished - or similar).
Whether you do cc1() or system("cc1")
or spawn("cc1") can be debated, and I
think by default it should be cc1() with
non-default options available so that on
*some systems* you can create separate
load modules. Note that it is beyond C90
to ensure that system("cc1") will be useful,
so cc1() is required by default to be
C90-compliant.
If you really don't like the unix design philosophy then why are you
using it as a groundplan at all?
At least nominally, I neither like nor
dislike Unix. Especially a Unix flavor
that says you must never call fork(),
but spawn() is available. I'm still
trying to understand things.
And from a C90 perspective (which
is where I still am, I haven't yet
reached directory traversal algorithms
in PDPCLIB - and nor will I, because
it is not in C90 - but maybe I will at
some point create a new library which
will have functions like opendir() which
work on *all* of MVS, Windows and
Unix.
And it's not just Unix that I have issues
with. I don't like Windows requiring DLLs.
I want stand-alone executables in
PDOS/386 which means I will probably
be sticking with MSDOS-like executables
rather than Windows-like executables.
This will complicate plans to provide a
competitor to Windows.
Similarly I don't want any of my MVS
programs to call LE or other random
load modules, e.g. a reentrant
PDPCLIB module that all of my C
programs can share. I instead want
static linking.
And as Peppe reported in his experience
of Linux, the changes to shared libraries
etc cause Linux to be incompatible with
itself after a few months.
Basically DLLs suck, and that's why "DLL
hell" exists and is even documented:
https://en.wikipedia.org/wiki/DLL_Hell
So basically you can say that so far I
have penciled in two design decisions
already:
1. Standalone modules, no DLLs
2. fork() is not available.
Those design decisions are going to
be applied to:
1. PDOS/386
2. PDOS/370
3. z/Paulix or maybe even just Paulix if
it can run on a 386 processor too. This is
still unclear to me. I haven't seen anyone
say Linux/SPARC or Linux/386 so I'm
not sure why people say z/Linux.
Note that my design decisions above,
to not use shared libraries, and not
provide or use fork(), mean that I am
in fact deviating from proper Unix, so
that is why I am a bit nervous when I
have been told "those who do not
understand Unix are condemened
to reimplement it badly". ie I guess
there is an implication there that I
don't understand shared libraries,
so I have condemned myself.
Instead I am happy for MVS-style
SVCs and also MVS-style executing
functions linked from the CVT. If
MVS internally converts those
functions into something resembling
DLLs I don't care. But I don't want to
be exposed to the concept of DLLs
myself - anywhere in my executable.
No DLL-processing crap linked in.
CVT is fine though.
I hope this makes some sort of sense,
I'm only vaguely aware of what I am
really trying to achieve. Such as the
recent plan to create a Telix 3.12
clone. That is not something that I
started planning 10 years ago as part
of some elaborate plan. It's just
haphazardly seeing (what I consider
to be) holes and trying to fix them.
BFN. Paul.