On 04/02/2024 15:01, bart wrote:
> On 04/02/2024 12:53, David Brown wrote:
>> On 03/02/2024 15:16, bart wrote:
>>
>>> MSDOS and Windows were intended for direct use by ordinary consumers.
>>> Unix was intended for developers.
>>>
>>
>> There is a bit of truth in that - though Unix was also targeted at
>> serious computer users, workstation users (such as for CAD,
>
> (My company specialised in low-end CAD products, one of them running on
> an 8-bit computer using CP/M. I think at one CAD/CAM trade show, we had
> the cheapest product by far.)
>

OK. There's always been a market for low-end, low-price products on
low-price hardware. (That's not a criticism in any way.) At the
high-end, it was all Unix at least until Windows NT came out. And since
then, it's still primarily *nix for the top end stuff - mostly running
on Linux, of course. (Number two choice would be Macs, especially in
some areas.)

>> (Given your statement here, why do you find it so hard to accept that
>> people find Linux a much better platform for developers than Windows?)
>
> I didn't quite say that. I meant that Unix with its abstruse interface
> was more suited to technical people such as developers, but also those
> in academia or industry. Who could also afford such a machine (because
> somebody else was paying).
>

That used to be the case, yes.

> Some aspects of it, such as case-sensitive commands and file system,
> would have caused difficulties.

I know that's a hobby-horse of yours, but it is completely irrelevant to
most people. People who use gui's don't care about case sensitivity.

> Real-life is not usually case-sensitive.
> Even now, ordinary people's exposure to it seems to be mainly with
> passwords.
>

I've only ever heard of it being an issue when someone has left their
caps lock on by mistake.

> (I did a lot of telephone support walking people through dialogs on a
> terminal. A case-sensitive OS would have made things considerably harder.)
>

Ordinary users don't use terminals.

> But it does seem as though Unix was a breeding ground for multitudinous
> developer tools. Plus there was little demarcation between user
> commands, C development tools, C libraries and OS.
>
> Somebody who's used to that environment is surely going to have trouble
> on an OS like MSDOS or Windows where they have to start from nothing.
> Even if most of the tools are now free.
>

I am very used to both environments. I would consider myself as a
"power user" of Linux /and/ a "power user" of Windows. (I admit that my
advanced usage on Windows is getting a bit out of date. I've tried to
avoid anything after Windows 7.) This is why I can give a qualified
opinion comparing the OS'es - though it is still obviously an opinion.

On 03/02/2024 20:35, bart wrote:
> On 03/02/2024 17:59, Kaz Kylheku wrote:
>> On 2024-02-03, bart <bc@freeuk.com> wrote:
>>> On 03/02/2024 01:31, Lawrence D'Oliveiro wrote:
>>>> On Fri, 2 Feb 2024 21:51:43 +0000, bart wrote:
>>>>
>>>>> What option is that, to have one command 'cc' that can deal with N
>>>>> different languages?
>>>>
>>>> Hint: it uses the filename extension to determine which language, and
>>>> which flavour of the language even, it is dealing with.
>>>
>>> This is the filename extension which Linux famously ignores, because you
>>> can use any extension you like?
>>>
>>> Hint: my tools KNOW which language they are dealing with:
>>
>> You're arguing for a user-unfriendly system where you have to memorize
>> a separate command for processing each language.
>
> You have to impart that information to the tool in any case. It can
> either be by file extension, or the name of the command.
>
> So, 'cc' is some tool that looks at a file extension and selects a
> suitable program based on that extension; well done.
>

"cc" is not a tool in itself - it's just a standard name for the
system's C compiler. It might be a pure C compiler. On most Linux
systems, it is a symbolic link to a version of gcc. And the "gcc"
binary is a front-end, and will handle C, C++, assembly, linking, and -
if you have installed the compilers - FORTRAN, Ada, and possibly other
languages.

> But what is the point? Do you routinely invoke cc with multiple files of
> mixed languages?

I certainly invoke it with C, C++ and the occasional assembly file.
(Though I do so explicitly as gcc rather than cc.)

> Suppose you wanted a different C compiler on each .c
> file? Oh, you then invoke it separately for each file. So you do that
> anyway in that rare event.

Yes.

>
>
>
>> Recognizing files by suffix is obviously superior.
>>
>>>     root@XXX:/mnt/c/c# cp hello.c hello.x
>>>     root@XXX:/mnt/c/c# gcc hello.x
>>>     hello.x: file not recognized: file format not recognized
>>
>> This is good; it's one more little piece of resistance
>> against people using the wrong suffix.
>
>> It's not the only one.  Editors won't bring up the correct syntax
>> formatting and coloring if the file suffix is wrong.

Usually the suffix is used for the initial language type selection, and
you can override it if you want.

>>
>> Tools for cross-referencing identifiers in source code may also get
>> things wrong due to the wrong suffix, or ignore the file entirely.
>
> This completely contradicts what people have been saying about Linux
> where file extensions are optional and only serve as a convenience.
>

No, it fits it perfectly.

File extensions are a convenience. You can override them if you want.

> For example, executables can have no extension, or .exe, or even .c.

Yes. It is common, for example, to have ".py" as the extension for
Python source files - /and/ for executable Python files. But sometimes
it is also convenient to have no extension for executable Python files
intended to be used as convenient command-line programs.

>
> It is Windows that places more store by file extensions, which Linux
> people say is a bad thing.
>

Windows is too dependent on them, and too trusting.

> But above you say that is the advantage of Linux.

Yes, it's a hands-down win for Linux (and other *nix) in this aspect.

>
>> Your argument of "I can rename my C to any suffix and my compiler
>> still recognizes it" is completely childish.
>
> It only seems to be childish when one of my programs handles this better
> than one of yours!

But it /doesn't/ handle it better. It does worse. gcc acts the way
users expect, based on sensible choices of file extensions. Yours can't
cope with any other kind of file and instead acts contrary to user
expectation.

>
> There is only thing my mcc program can't do, which is to compile a C
> file named 'filename.'; that is, 'filename' followed by an actual '.',
> not 'filename' with no extension.
>
> And that's only when I run it under Linux. That's because under Linux,
> 'filename' and 'filename.' are distinct files; the "." is part of the
> file name, not a notional separator.
>

Of course it is. It's simple and consistent.

In Windows, it is sometimes part of a file name (when it is not the last
period in the name), sometimes a magical character that appears or
disappears (when the file ends in a period), and sometimes it delimits a
file extension.

On 2024-02-03, bart <bc@freeuk.com> wrote:
> On 03/02/2024 18:17, Kaz Kylheku wrote:
>> On 2024-02-03, bart <bc@freeuk.com> wrote:
>
>>> Don't you see that using only Unix-like systems is also a bubble?
>>
>> Don't you see that living on Earth is literally being in bubble?
>>
>> Your bubble contains only one person.
>>
>> The Unix-like bubble is pertty huge, full of economic opportunities,
>> spanning from embedded to server.
>
> You're missing my point. Unix imposes a certain mindset, mainly that
> there is only ONE way to things, and that is the Unix way.

In the world of Unix-like systems, there are many, many ways of working.
There isn't one way.

Can you name a software system which doesn't impose a mindset?

For instance, doesn't a spreadsheet impose the mindset that data are
visually represented by entries in tables, linked by formulas?

> That is pretty obvious from the passionate posts people make about it.

Mostly, what people are passionate about here is pointing out the
mistakes which make others wrong. That's it.

In the world of Unix and Linux, there is a lot of criticism from the
inside. Improvements are made.

The free environments we have now are collectively a huge improvement
over the original proprietary Unix, or even BSD. As a GNU/Linux user,
when you step inside a proprietary Unix with no free software installed
in it, it's like taking a time machine to the dark ages.

> And it is obvious that they struggle outside it, which is why they hate
> Windows - it just isn't Unix!

Many users of GNU/Linux who are critics of Windows have previous
experience with Windows. Users with no Windows exposure, whose first
system was some kind of Linux

>> While you were dismissing Linux in 1995, it was actually going strong,
>> marching forward. Only fools ignored it.
>>
>> A year before that, in 1994, I was doing contract work for Linux
>> already. My client used it for serving up pay-per-click web pages to
>> paying customers. I was working on the log processing and billing side
>> of it, and also created a text-UI (curses) admin tool.
>
> Meanwhile, a decade before that, the question of OS in my first
> commercial product was utterly irrelevant. It provided a file system and
> it was used to launch my app.

Many applications critically depend on application programming
interfaces (APIs) in the operating system.

> What was it again? I can barely remember. I JUST DO NOT CARE.

If you talk about it, you care.

> Of all those OSes I have used, Windows might rank near the bottom, but
> not for the reasons you think. That's because it operated in protected
> mode so that lots of things which had been easy, became hard.

Sure, easy things like trashing another application, or using
hardware rudely while something else is accessing it!

It's harder to be polite and request things, than to just barge
in and take what you need.

In a protected system, you have to use an operating system API to do
some of those things. Want to put pixels directly into a frame buffer?
Because there is a windowing system you have to arrange that with the OS
and follow certain rules. You can't keep putting pixels there if your
program loses focus and another window is put over your screen area.

Tough luck!

> How would Unix have helped with that? It wouldn't.)

The question how Unix would have helped on an 8 bit CP/M machine forty
years go isn't very interesting today. At that time, Unix probably ran
best on machines with at least perhaps five to ten times the resources
of that, or thereabouts.

>> An OS that provides more or less the same semantics as POSIX, but using
>> interfaces that are gratuitously different, and incompatible, is
>> worthless in this day and age.
>
> Because .... you say so?

The economic marketplace says so, mainly.

> I mean, are core OSes really so hard to write that everyone in the world
> has to use the same one? There seems to plenty of amateur OS development
> still.

Yes, developing a production OS is very, very hard.

Writing and debugging just one damned driver for an OS (e.g. USB host
controller) can be very hard and take a lot of time.

>> Something that doesn't conform to compatibility standards, and isn't
>> demonstrably better for it, is a dud.
>>
>> There is good different and bad different. More or less same, but
>> incompatible, is bad different.
>
> I build a box where you feed in data in the form of byte-stream, and it
> gives results in the form of a byte-stream. Or replace one of those by
> something physical; say the box is a printer or scanner.
>
> There is no OS specified, you've no idea whether it uses POSIX, or even
> if there's a computer inside.

If that byte stream is incompatible from the one used by every other
such a box in the commercial marketplace, it's a dud. More so if it is
undocumented and changes monthly.

> But if it performs a useful task, then what is the problem?

Vendor lock-in.

> Same thing if you are working on a self-contained function, library or
> app. It may have inputs or outputs. Do you need to care what OS is
> running? No, only on the job it has to do.

An app can hide the system from the user, but the app itself
certainly cares about what OS it's running on.

> Really you make too much of it. The main thing I don't like is when I
> have some software that is hard to build on Windows when there is no
> reason for it.

There is a reason; mainly, some of the program depends on a different OS
which is not compatible with Windows.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 04/02/2024 17:48, David Brown wrote:
> On 03/02/2024 20:35, bart wrote:

>> It is Windows that places more store by file extensions, which Linux
>> people say is a bad thing.
>>
>
> Windows is too dependent on them, and too trusting.

>> But above you say that is the advantage of Linux.
>
> Yes, it's a hands-down win for Linux (and other *nix) in this aspect.

Yet it is Linux (manifested via gcc) where it ASSUMES .x is a linker
script, and ASSUMES that .s is an assembly source file; INCORRECT
assumptions.

I think I'm starting to understand the rules: whatever Windows does is
always wrong, and whatever Linux does is always right!

To be clear, this is the behaviour of /my/ applications, which work the
same way on Windows /or/ Linux, that work primarily work on one type of
file, that assume that file type no matter what the extension.

BOTH methods can be problematic if you deliberately or accidentally mix
up file types and extensions.

>> And that's only when I run it under Linux. That's because under Linux,
>> 'filename' and 'filename.' are distinct files; the "." is part of the
>> file name, not a notional separator.
>>
>
> Of course it is.  It's simple and consistent.
>
> In Windows, it is sometimes part of a file name (when it is not the last
> period in the name), sometimes a magical character that appears or
> disappears (when the file ends in a period), and sometimes it delimits a
> file extension.

It probably still needs to be a notional dot for backwards compatibility
over decades.

The first two DEC systems I used had 6.3 filenames, storing 'sixbit'
characters in 1.5 words for 36 bits, or using 'radix-50' in 3 words for
16 bits. You can see there is nowhere to put the dot.

That was carried over to DOS's 8.3 filename.

This dot then was really a virtual separator that did not need storing,
any more than you need to store the dot in the ieee754 representation of
73.945.

It has given very little trouble, and has the huge advantage that you
can have default extensions on input files with no ambiguity.

Let me guess: Unix allows you to have numbers like 73.945.112, while 73.
is a different value from 73? Cool.

bart <bc@freeuk.com> writes:
>On 04/02/2024 17:48, David Brown wrote:
>> On 03/02/2024 20:35, bart wrote:
>
>>> It is Windows that places more store by file extensions, which Linux
>>> people say is a bad thing.
>>>
>>
>> Windows is too dependent on them, and too trusting.
>
>>> But above you say that is the advantage of Linux.
>>
>> Yes, it's a hands-down win for Linux (and other *nix) in this aspect.
>
>Yet it is Linux (manifested via gcc) where it ASSUMES .x is a linker

I've never seen a '.x ' suffix. Ever. And I use linker scripts
regularly.

>script, and ASSUMES that .s is an assembly source file;

The command is well documented. It assumes nothing.
It (cc, the compiler driver command) will simply pass files with a .s suffix to the
assembler, and the assembler will, correctly, treat it as
assembler source. If it's not, that is the problem of RTFM
by the user.

It is definitely not the problem of the toolset (cc) or the
assembler (which doesn't care what suffix is used).

On 2/4/24 19:22, Kaz Kylheku wrote:

>> How would Unix have helped with that? It wouldn't.)
> The question how Unix would have helped on an 8 bit CP/M machine forty
> years go isn't very interesting today. At that time, Unix probably ran
> best on machines with at least perhaps five to ten times the resources
> of that, or thereabouts.

https://www.fuzix.org/

--
+---------------------------------------------------------------------+
| https://tube.interhacker.space/a/tth/video-channels |
+---------------------------------------------------------------------+

On 04/02/2024 21:18, bart wrote:
> On 04/02/2024 17:48, David Brown wrote:
>> On 03/02/2024 20:35, bart wrote:
>
>>> It is Windows that places more store by file extensions, which Linux
>>> people say is a bad thing.
>>>
>>
>> Windows is too dependent on them, and too trusting.
>
>>> But above you say that is the advantage of Linux.
>>
>> Yes, it's a hands-down win for Linux (and other *nix) in this aspect.
>
> Yet it is Linux (manifested via gcc) where it ASSUMES .x is a linker
> script, and ASSUMES that .s is an assembly source file; INCORRECT
> assumptions.
>

No, they are almost always /correct/ assumptions. If you want to use .s
for a C file, that is allowed - but it is so unusual that you have to
tell gcc about it ("gcc -x c cfile.s" will work).

Would you prefer a system where the compiler just guesses and makes up
the rules as it goes along? (Here's a hint - a file can be valid C and
also valid C++, but compiling it in the different languages will give
different results.)

What works for little hobby tools does not always work at scale for
serious tools.

> I think I'm starting to understand the rules: whatever Windows does is
> always wrong, and whatever Linux does is always right!
>

You've claimed that many times over the years. If you were to stop
merely /starting/ to think that, and take it as the basic assumption,
then you would not always be correct - but you'd be wrong at lot less often!

> To be clear, this is the behaviour of /my/ applications, which work the
> same way on Windows /or/ Linux, that work primarily work on one type of
> file, that assume that file type no matter what the extension.
>

Exactly. For your little program that can't deal with more than one
type of file, you can do this. And since it is for your own little tool
that no one else uses, you can do it exactly as you like.

> BOTH methods can be problematic if you deliberately or accidentally mix
> up file types and extensions.

So stop deliberately being a screw-up. You'll find life vastly easier.
Accidents can happen on occasion, but you're a lot less likely to shoot
yourself in the foot if you stop aiming at your foot and squeezing the
trigger.

>
>>> And that's only when I run it under Linux. That's because under
>>> Linux, 'filename' and 'filename.' are distinct files; the "." is part
>>> of the file name, not a notional separator.
>>>
>>
>> Of course it is.  It's simple and consistent.
>>
>> In Windows, it is sometimes part of a file name (when it is not the
>> last period in the name), sometimes a magical character that appears
>> or disappears (when the file ends in a period), and sometimes it
>> delimits a file extension.
>
> It probably still needs to be a notional dot for backwards compatibility
> over decades.
>
> The first two DEC systems I used had 6.3 filenames, storing 'sixbit'
> characters in 1.5 words for 36 bits, or using 'radix-50' in 3 words for
> 16 bits. You can see there is nowhere to put the dot.
>
> That was carried over to DOS's 8.3 filename.

At a time when real OS's had moved beyond that. What a stupid decision
- it's what you expect when you remember that MS DOS was written as a
quick hack on a system called "quick and dirty OS" as a way for MS to
con its customers.

>
> This dot then was really a virtual separator that did not need storing,
> any more than you need to store the dot in the ieee754 representation of
> 73.945.
>
> It has given very little trouble, and has the huge advantage that you
> can have default extensions on input files with no ambiguity.
>
> Let me guess: Unix allows you to have numbers like 73.945.112, while 73.
> is a different value from 73? Cool.
>

Um, you remember this is comp.lang.c ? "73" is an integer constant,
"73." is a double.

On 2/4/2024 9:48 AM, David Brown wrote:
[...]
> In Windows, it is sometimes part of a file name (when it is not the last
> period in the name), sometimes a magical character that appears or
> disappears (when the file ends in a period), and sometimes it delimits a
> file extension.

picture_of_a_cow____________________this_is_not_a_virus_really.jpeg.gif.exe

lol.

On 2/4/2024 8:13 AM, Jim Jackson wrote:
> On 2024-02-03, bart <bc@freeuk.com> wrote:
>> On 03/02/2024 18:17, Kaz Kylheku wrote:
>>> On 2024-02-03, bart <bc@freeuk.com> wrote:
>>
>>>> Don't you see that using only Unix-like systems is also a bubble?
>>>
>>> Don't you see that living on Earth is literally being in bubble?
>>>
>>> Your bubble contains only one person.
>>>
>>> The Unix-like bubble is pertty huge, full of economic opportunities,
>>> spanning from embedded to server.
>>
>> You're missing my point. Unix imposes a certain mindset, mainly that
>> there is only ONE way to things, and that is the Unix way.
> ^^^
>
> I had to laugh. Others criticise the linux/unix world for having TOO
> many ways of doing things, which makes things difficult :-)
>

:^D

On Sun, 4 Feb 2024 20:18:20 +0000, bart wrote:

> I think I'm starting to understand the rules: whatever Windows does is
> always wrong, and whatever Linux does is always right!

You said it, we didn’t.

Remember that *nix systems were being used for “real” programming before
Windows was even a gleam in Bill Gates’ eye.

On Sun, 4 Feb 2024 14:01:08 +0000, bart wrote:

> But it does seem as though Unix was a breeding ground for multitudinous
> developer tools. Plus there was little demarcation between user
> commands, C development tools, C libraries and OS.
>
> Somebody who's used to that environment is surely going to have trouble
> on an OS like MSDOS or Windows where they have to start from nothing.
> Even if most of the tools are now free.

Yet it seems like even someone like you, who is supposed to be “used to”
Windows rather than *nix, still has the same trouble. So maybe it’s not
about being “used to” *nix at all, there really is something inherent in
the fundamental design of that environment that makes development work
easier.

On 2/3/2024 10:43 PM, Lawrence D'Oliveiro wrote:
> On Sat, 3 Feb 2024 15:44:29 +0000, Malcolm McLean wrote:
>
>> On the other had, if you want a GUI, the Windows system is all set up
>> for you and you just have to call the right functions.
>
> Except the Win32 GUI functions are pretty low-level, so everybody uses
> some kind of toolkit.

I used some toolkit that had a lot of macros, I cannot remember what one
it was right now. Damn! ATL? Was not MFC.

> Only it’s not clear which toolkit is Microsoft’s
> official recommendation this week--is it MAUI? Dotnet? WinForms? Something
> else I haven’t even heard of?

On 2/4/2024 9:27 AM, David Brown wrote:
> On 04/02/2024 16:50, Malcolm McLean wrote:
>> On 04/02/2024 12:44, David Brown wrote:
>>> On 04/02/2024 05:56, Malcolm McLean wrote:
>>>> On 04/02/2024 01:19, bart wrote:
>>>>>
>>>>> So I'm disappointed there isn't a better, simpler solution to a
>>>>> very, very simple problem: what exactly goes in place of ... when
>>>>> building any complete program:
>>>>>
>>>
>>>> No. I get it. Over complicated build systems which break. Very
>>>> serious issue. I've had builds break on me and I'm very surprised
>>>> more people haven't had the same experience and don't easily
>>>> understand what you are saying.
>>>>
>>>> But where David Brown is right is that it is one thing to diagnose
>>>> the problem, quite another to solve it. That is extremely difficult
>>>> and I don't think we'll find the answer easily. But continue to
>>>> discuss.
>>>>
>>>
>>> I'm glad you think I am right - and I agree that as a general point,
>>> solving issues is usually harder than diagnosing them.  But I did not
>>> say anything remotely like that in any posts, as far as I am aware.
>>>
>>> In particular, I am not aware of any "diagnosis" of fundamental
>>> issues with build tools that need solving - certainly not "solving"
>>> by Bart's solution.  (I am aware that /Bart/ has trouble using common
>>> tools, and that his solution might help /him/ - which is fine, and I
>>> wish him luck with it for fixing his own issues.)  Some people might
>>> use tools badly, and some people publish projects where others find
>>> the builds difficult on different systems.  That's a matter of use,
>>> not the tools - others find they work fine.  (No tool is perfect, of
>>> course, and there's always scope for improvement.)
>>>
>>> So if you want to use my name, I'd rather you did it in reference to
>>> things I have actually said.
>>>
>>
>> You've said repeatedly and at great length that Bart's proposed
>> solutions won't work.
>
> No, I have said repeatedly that it would not work for /me/.

I asked Bart about C11 support. He said something akin to his system
does not support it. So, his system would not work for me. :^)

[...]

On 2/4/2024 2:42 PM, Lawrence D'Oliveiro wrote:
> On Sun, 4 Feb 2024 20:18:20 +0000, bart wrote:
>
>> I think I'm starting to understand the rules: whatever Windows does is
>> always wrong, and whatever Linux does is always right!
>
> You said it, we didn’t.
>
> Remember that *nix systems were being used for “real” programming before
> Windows was even a gleam in Bill Gates’ eye.

Windows _gui_ from Xerox?

On 04/02/2024 21:51, David Brown wrote:
> On 04/02/2024 21:18, bart wrote:

>> BOTH methods can be problematic if you deliberately or accidentally
>> mix up file types and extensions.
>
> So stop deliberately being a screw-up.

I was replying initially to somebody claiming that being able to do:

cc prog.a
cc prog.b
cc prog.c

and marshalling the file into the right tool was not only some great
achievement only possible on Linux, but also desirable.

I think using dedicated tools instead is a better idea.

>

>> That was carried over to DOS's 8.3 filename.
>
> At a time when real OS's had moved beyond that.

When was that? The IBM PC came out in 1981. The DEC machines I mentioned
were still in use. Oh, you mean Unix was the One and Only Real OS? I get it.

  What a stupid decision
> - it's what you expect when you remember that MS DOS was written as a
> quick hack on a system called "quick and dirty OS" as a way for MS to
> con its customers.

Funny you should fixate on that, and not on the idea of a business
computer running on a 4.8MHz 8088 processor with a crappy 'CGA' video
board design that would barely pass as a student assignment. (Oh, that
was IBM and not MS, and it is only MS you want to shit all over.)

However it brought business computing to the masses. Where were the
machines running your beloved Unix?

I believe you were working on Spectrums then or some such machines; what
filenames did /they/ allow, or did they not actually have a file system?

You're being unjust on the people working on all this stuff at that
period, trying to make things work with small processors, tiny amounts
of memory and limited storage.

>>
>> This dot then was really a virtual separator that did not need
>> storing, any more than you need to store the dot in the ieee754
>> representation of 73.945.
>>
>> It has given very little trouble, and has the huge advantage that you
>> can have default extensions on input files with no ambiguity.
>>
>> Let me guess: Unix allows you to have numbers like 73.945.112, while
>> 73. is a different value from 73? Cool.
>>
>
> Um, you remember this is comp.lang.c ?  "73" is an integer constant,
> "73." is a double.

Yes. But the question is whether the "." separating out the two parts of
a filename should be actually stored, as a '.' character taking up extra
space.

It made perfect sense not to store it the time. But Unix made a decision
at the time to store it literally, which could also have been thought crass.

In hindsight, with filenames now allowing arbitrary dots, they made the
right decision. But that was more due to luck. And probably not having
to make concessions to running on low-end hardware.

You however would try and argue that some great foresight was
deliberately exercised and that the people behind those other systems
made a dumb decision.

I'm sorry but you weren't there.

On 04/02/2024 22:46, Lawrence D'Oliveiro wrote:
> On Sun, 4 Feb 2024 14:01:08 +0000, bart wrote:
>
>> But it does seem as though Unix was a breeding ground for multitudinous
>> developer tools. Plus there was little demarcation between user
>> commands, C development tools, C libraries and OS.
>>
>> Somebody who's used to that environment is surely going to have trouble
>> on an OS like MSDOS or Windows where they have to start from nothing.
>> Even if most of the tools are now free.
>
> Yet it seems like even someone like you, who is supposed to be “used to”
> Windows rather than *nix, still has the same trouble.

*I* don't have trouble. Only with other people's projects originating
from Linux.

Apparently, on that OS, nobody knows how to build a program given only
the C source files, and a C compiler.

Or if they do, they are unwilling to part with that information. It is
encrypted into a makefile, or worse.

On 2/4/2024 3:29 PM, bart wrote:
> On 04/02/2024 22:46, Lawrence D'Oliveiro wrote:
>> On Sun, 4 Feb 2024 14:01:08 +0000, bart wrote:
>>
>>> But it does seem as though Unix was a breeding ground for multitudinous
>>> developer tools. Plus there was little demarcation between user
>>> commands, C development tools, C libraries and OS.
>>>
>>> Somebody who's used to that environment is surely going to have trouble
>>> on an OS like MSDOS or Windows where they have to start from nothing.
>>> Even if most of the tools are now free.
>>
>> Yet it seems like even someone like you, who is supposed to be “used to”
>> Windows rather than *nix, still has the same trouble.
>
>
> *I* don't have trouble. Only with other people's projects originating
> from Linux.
>
> Apparently, on that OS, nobody knows how to build a program given only
> the C source files, and a C compiler.
>
> Or if they do, they are unwilling to part with that information.

> It is encrypted into a makefile, or worse.
>
[...]
Okay, you basically forced me to laugh right there! Yes, makefiles that
are "auto-generated" can tend to look a bit "cryptic" for sure.

On 04/02/2024 22:46, Lawrence D'Oliveiro wrote:
> On Sun, 4 Feb 2024 14:01:08 +0000, bart wrote:
>
>> But it does seem as though Unix was a breeding ground for multitudinous
>> developer tools. Plus there was little demarcation between user
>> commands, C development tools, C libraries and OS.
>>
>> Somebody who's used to that environment is surely going to have trouble
>> on an OS like MSDOS or Windows where they have to start from nothing.
>> Even if most of the tools are now free.
>
> Yet it seems like even someone like you, who is supposed to be “used to”
> Windows rather than *nix, still has the same trouble. So maybe it’s not
> about being “used to” *nix at all, there really is something inherent in
> the fundamental design of that environment that makes development work
> easier.
On Windows you can't assume that the end user will be interested in
development or have any develoment tools available. Or that he'll be
able to do anything other than the most basic installation. It's a
consumer platform.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 2/4/2024 4:07 PM, Malcolm McLean wrote:
> On 04/02/2024 22:46, Lawrence D'Oliveiro wrote:
>> On Sun, 4 Feb 2024 14:01:08 +0000, bart wrote:
>>
>>> But it does seem as though Unix was a breeding ground for multitudinous
>>> developer tools. Plus there was little demarcation between user
>>> commands, C development tools, C libraries and OS.
>>>
>>> Somebody who's used to that environment is surely going to have trouble
>>> on an OS like MSDOS or Windows where they have to start from nothing.
>>> Even if most of the tools are now free.
>>
>> Yet it seems like even someone like you, who is supposed to be “used to”
>> Windows rather than *nix, still has the same trouble. So maybe it’s not
>> about being “used to” *nix at all, there really is something inherent in
>> the fundamental design of that environment that makes development work
>> easier.
> On Windows you can't assume that the end user will be interested in
> development or have any develoment tools available.

Fwiw, I have seen Linux users that have no intent to program anything at
all.

> Or that he'll be
> able to do anything other than the most basic installation. It's a
> consumer platform.

On Mon, 5 Feb 2024 00:07:33 +0000, Malcolm McLean wrote:

> On Windows you can't assume that the end user will be interested in
> development or have any develoment tools available.

Worse than that, the assumption is that development will be done in a
proprietary, self-contained IDE, primarily sourced from a single vendor.

On 2/3/2024 10:47 PM, Lawrence D'Oliveiro wrote:
> On Sat, 3 Feb 2024 12:02:48 +0000, bart wrote:
>
>> I guess you're not curious about WHY a project that builds easily on
>> Unix causes problems on Windows?
>
> Fundamental NT kernel limitations, going back decades and seemingly
> unfixable. Like poll(2)/select(2) not being able to work on pipes. Like
> why WSL1 had to be abandoned (in spite of Microsoft’s best efforts), and a
> proper Linux kernel brought in with WSL2.
>

> The irony is, the Cygwin folk have been able to build a better POSIX
> emulation layer than Microsoft has been able to manage.

Ditto! Humm... :^)

On 2/3/2024 10:47 PM, Lawrence D'Oliveiro wrote:
> On Sat, 3 Feb 2024 12:02:48 +0000, bart wrote:
>
>> I guess you're not curious about WHY a project that builds easily on
>> Unix causes problems on Windows?
>
> Fundamental NT kernel limitations,

NT4:

https://github.com/ZoloZiak/WinNT4

;^D

> going back decades and seemingly
> unfixable. Like poll(2)/select(2) not being able to work on pipes. Like
> why WSL1 had to be abandoned (in spite of Microsoft’s best efforts), and a
> proper Linux kernel brought in with WSL2.
>
> The irony is, the Cygwin folk have been able to build a better POSIX
> emulation layer than Microsoft has been able to manage.

On 2/3/2024 7:07 PM, Gary R. Schmidt wrote:
[...]
> Oh, you mean FORTRAN-IV?

FORTRON?

https://youtu.be/tp8sAS1imS4

lol ;^D

On 2/4/2024 5:45 PM, Lawrence D'Oliveiro wrote:
> On Mon, 5 Feb 2024 00:07:33 +0000, Malcolm McLean wrote:
>
>> On Windows you can't assume that the end user will be interested in
>> development or have any develoment tools available.
>
> Worse than that, the assumption is that development will be done in a
> proprietary, self-contained IDE, primarily sourced from a single vendor.

https://youtu.be/i_6zPIWQaUI ;^)

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> On 2/4/2024 5:45 PM, Lawrence D'Oliveiro wrote:
>> On Mon, 5 Feb 2024 00:07:33 +0000, Malcolm McLean wrote:
>>> On Windows you can't assume that the end user will be interested in
>>> development or have any develoment tools available.
>> Worse than that, the assumption is that development will be done in a
>> proprietary, self-contained IDE, primarily sourced from a single
>> vendor.
>
> https://youtu.be/i_6zPIWQaUI ;^)

If you must post random YouTube links, can you at least include a 1-line
description so we don't waste *too* much time?

Better yet, if you could cut down on the followups that don't add
anything relevant, I for one would appreciate it.

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