Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: "Paul Edwards" <mutazilah@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: encapsulating directory operations
Date: Fri, 23 May 2025 08:44:01 +1000
Organization: A noiseless patient Spider
Lines: 91
Message-ID: <100o9bl$3msfh$1@dont-email.me>
References: <100h650$23r5l$1@dont-email.me> <20250520065158.709@kylheku.com><100i2la$292le$1@dont-email.me><87a5770xjw.fsf@nosuchdomain.example.com><100j09o$2f04b$1@dont-email.me><87tt5ezx9y.fsf@nosuchdomain.example.com><100j4t3$2foah$1@dont-email.me><87ldqqzfj0.fsf@nosuchdomain.example.com><100kak8$2q0s6$1@dont-email.me> <87a575zvmb.fsf@nosuchdomain.example.com> <100o3sc$3ll6t$1@dont-email.me>
Injection-Date: Fri, 23 May 2025 00:44:06 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="9b6e527ae96f39b01313061b79abe237";
	logging-data="3895793"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX192nPO7UMSwuKdupnFKIUkuJZ161fMWDeM="
Cancel-Lock: sha1:3O6RGAppVsOFlCtOzTfY2DAu4Go=
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-MSMail-Priority: Normal
X-Priority: 3

"Paul Edwards" <mutazilah@gmail.com> wrote in message
news:100o3sc$3ll6t$1@dont-email.me...
> "Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message
> news:87a575zvmb.fsf@nosuchdomain.example.com...
>
> I can't practically change Visual Studio, but even then,
> I would be open to negotiation, if someone were to
> say "look, all the extant compilers support xyz, and
> if you zap offset 156383 of cl.exe in Visual Studio,
> it will be brought into line with all the other compilers,
> and xyz is the way forward", then I would indeed
> consider compiler changes.
>
> But I seriously doubt that xyz even exists, much less
> that it could be "fixed" with a 1-byte zap.
>
> So while I don't want to say "I refuse to change
> existing compilers", in practice, that is the case.

Actually, that language is too strong.

If a conclusion is reached that there is very strong
evidence that "the way forward" is that the compiler
itself needs to change, and I need to give up
Microsoft C - so be it.

I don't have any hard position on anything that I am
aware of.

Even the old mainframes - I may give them up as a
relic. But before I do, I want to make sure they are
graced with C90.

It took decades before I created a 64-bit flavor of
PDPCLIB. And I went to a lot of effort to try to keep
the IBM PC BIOS alive.

But one day there was a factor that made me decide
to support 64-bit. I can't remember exactly, but I think
it might have been the PDOS-generic concept, and I
wasn't sure I could support 16-bit with it, and so instead
I decided to do 64-bit first, as an abstraction, so that I
could gain some experience, before heading back to
16-bit.

Note that when I produced S/380 so that we could "push
forward the mainframe technology", it was only then that
I found that this "wasn't a thing that others were trying to do".
I had seen others writing software for MVS 3.8J - lots of
time spent on this - but that fitted into their sense of
"nostalgia" somehow (even if it was new software), rather
than "how close can we get to z/OS so that we can be a
viable competitor?".

I was running under an unstated assumption, and had
incorrectly assumed that other people were operating
a similar way, based on the fact that I could see MVS 3.8J
becoming more and more viable every day.

I don't have a fixed goal. I could be persuaded to become
a Tibetan monk.

Or in more realistic terms - I could be persuaded to just
stick with gcc 3.2.3 and forget about Microsoft products,
because "some of these features that will make a real
difference need to go into the compiler, and you can't
be dictated to by Microsoft".

But just like the IBM PC BIOS, and 32-bit, I will cling
to Microsoft etc C90-compliant compilers to the bitter end.
Only when I see with my own eyes that I need to abandon
Microsoft C 6.0 will I abandon Microsoft C 6.0.

The compiler. Not the library. The library was abandoned
a long time ago.

Someone has updated gcc to include an IA-16 target.
I have never expressed much interest in that. But under
the right circumstances, I might find myself getting that
code and back-porting it to gcc 3.2.3.

As an example. Of a somewhat meandering goal.

Perhaps you could say my goal is "to fix the issues that
Jeff outlined in that original link I posted". But I don't
want to tie myself down to that either. "grace hardware
with C90 or close" might be a concrete goal too.

BFN. Paul.