Re: encapsulating directory operations

"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.