On 03/02/2024 18:02, Malcolm McLean wrote:
> On 03/02/2024 16:03, bart wrote:
>> On 03/02/2024 15:44, 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. On Unix you
>>> have to configure some sort of front end to X, there's a lot more
>>> messing about, and the GUI elements aren't consistent.
>>
>> For GUI they're both a nightmare unless you use a simpler library that
>> sits on top. Or are you saying that X is even worse than WinAPI?
>
> I've programmed for both and Windows GUI is quite a bit easier to use.
> You have to enter a library name explictly to get the common controls,
> for some stupid reason, but once you do that the whole system is set up
> for you. Just call the API more or less as you would any other C
> function (except for tiny message loop interface), you've got a rich set
> of controls, and they are well designed and harmonised with the rest of
> the programs on the system.
>
> X - if you try to program to Xlib directly you're messing about with
> colur maps and goodness knows what just to get up a window. And if you
> don't it's dependency land and all that that entails, with some popular
> widget toolsets but no real standards. And often you find that these
> will break. However nowadays you can use QT. Which is alot better but
> still not very well designed with a non-canonical slot / message system
> and poor facilites for layout. That's why I was driven to write Baby X.
> A simple clean interface to Xlib that would allow you to get graphics up
> quickly and easily. You shouldn't have to do that, of course.
>

No sane person ever programs directly using Xlib or WinAPI for a gui
unless they have extremely niche requirements. People program using QT,
wxWidgets, GTK, SDL, or a range of other toolkits - almost all of which
are cross-platform and also support a range of language bindings. (Few
people program gui apps in C.)

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.

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, simulations,
and other demanding work), server usage, and other "big" things. DOS
and Windows were targeted at simpler consumer usage, office applications
and games.

As Linux gained traction, it became perfectly good for "ordinary
consumers" too.

My mother-in-law has used Linux for the last 15 years or so, for email,
browsing, writing letters, banking, and suchlike. And she is as far
from being a "computer nerd" as you can get!

(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?)

> Few ordinary consumers directly use a Unix-like system unless it is made
> to look like MacOS or Android. Or they run a GUI desktop that makes it
> look a bit like Windows.
>

I run a gui that makes my computer look like a computer - instead of
Windows which tries to make it look like a giant schizophrenic telephone
(after having gone through stages such as XP's Teletubbies interface).

Of course, with Linux you have a choice - you can pick a giant telephone
gui if you like.

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

> (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).

Some aspects of it, such as case-sensitive commands and file system,
would have caused difficulties. Real-life is not usually case-sensitive.
Even now, ordinary people's exposure to it seems to be mainly with
passwords.

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

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.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>
>>>> On Thu, 01 Feb 2024 19:03:38 -0800, Keith Thompson wrote:
>>>>
>>>>> A #include directive with <> searches for a "header", which is
>>>>> not stated to be a file. A #include directive with "" searches
>>>>> for a file in an implementation-defined manner; if that search
>>>>> fails, it tries again as if <> had been used.
>>>>
>>>> The trouble with that interpretation is, it would seem to rule
>>>> out the use of things like include libraries for user headers.
>>>> Do you really think that was the intention?
>>>
>>> I don't know. I imagine an implementation could interpret the
>>> word "file" to include information extracted from libraries. Note
>>> that it doesn't have to correspond to the concept of a "file" used
>>> in <stdio.h>; that refers to files in the execution environment,
>>> not the compilation environment.
>>
>> To me what the C standard says is clear. A #include "whatever.h"
>> gets its stuff from a file (assuming of course the appropriate
>> file can be found, and not revert to the #include <whatever.h>
>> form). A #include <whatever.h> gets its stuff from a header,
>> said header perhaps being stored in a file or perhaps not, and if
>> file-stored then it could be a 1-1 relationship, or a 1-many
>> relationship, or a many-1 relationship. Since the C standard
>> doesn't define the term 'header', an implementation is allowed to
>> actualize it however the implementation chooses (including the
>> possibility of storing information inside the compiler itself).
>
> On further thought, I tend to agree.
>
> I was thinking that an implementation could usefully provide some of
> its own headers as something other than files, as it's clearly
> allowed to do for the C standard headers. But the obvious way to do
> that would be to require such headers to be included with <>, not
> "". POSIX-specific headers like unistd.h are already conventionally
> included with <>.
>
> An implementation probably *could* bend the meaning of "file" enough
> to support having `#include "whatever.h"` load something other than
> a file in the host filesystem, but it's not as useful as I first
> thought it might be -- and it could interfere with user-provided
> header files that happen to have the same name.

A correction of my earlier statement: actually the C standard does
define the word header, via the convention of using italics, in the
first sentence of section 7.1.2, paragraph 1 (and it is "defined" in
a way that IMO is singularly useless as a definition).

It seems clear that any implementation-provided "include units" are
meant to be supplied as 'headers', so that they may be accessed by
using a #include <name.h> form of inclusion. Similarly it seems
clear that any compilation-specific or project-specific "include
units" are meant to be supplied as files, so that they may be
accessed by using a #include "foo.h" form of inclusion. I don't see
any place in the C standard that expresses this distinction, but
surely it is meant to reflect the normal use pattern.

Also I don't see anything in the C standard that would preclude
having system-wide (but not tied to the implementation) "include
units" be available as headers, and so accessible using the <> form
of inclusion. Third-party libraries are often made available in
this way.

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. You haven't actually admitted that he has
diagnosed a problem which needs to be solved and maybe I should have
made that clearer. Where you're right is that writing a better build
system than make is hard. Bart referenced Norwegian, which obviously
meant you, and so I didn't introduce your name.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 02/02/2024 10:05, David Brown wrote:
> On 02/02/2024 00:30, Lawrence D'Oliveiro wrote:
>> On Thu, 1 Feb 2024 22:34:36 +0100, David Brown wrote:
>>
>>> I am, however, considering CMake (which works at a
>>> higher level, and outputs makefiles, ninja files or other project
>>> files).
>>
>> Ninja was created as an alternative to Make.
>
> It is an alternative to some uses of make - but by no means all uses.
>
>> Basically, if your Makefiles
>> are going to be generated by a meta-build system like CMake or
Meson, then
>> they don’t need to support the kinds of niceties that facilitate writing
>> them by hand. So you strip it write down to the bare-bones
functionality,
>> which makes your builds fast while consuming minimal resources, and that
>> is Ninja.
>
> Yes.
>
> It is not normal to write ninja files by hand - the syntax is
relatively simple, but quite limited. So it covers the lower level bits
of "make", but not the higher level bits.
>
>
> Perhaps ninja is the tool that Bart is looking for? For the kinds of
things he is doing, I don't think it would be hard to write the ninja
files by hand.

I've had a look. It doesn't look much simpler to me. But even if it was
(in that I could trivially extract the necessary info), open source
projects would need to use it.

This is from its manual:

"Ninja is yet another build system. It takes as input the
interdependencies of files (typically source code and output
executables) and orchestrates building them, quickly.

Ninja joins a sea of other build systems. Its distinguishing goal is to
be fast. It is born from my work on the Chromium browser project, which
has over 30,000 source files ... "

The projects I'm into are 100 to 1000 times smaller than that.

(On my machine, the binaries for Chrome are 20 files totalling 320MB.
But 230MB of that is in one giant DLL file. I wouldn't have taken that
approach. There are ways to split it up into more discrete binaries, and
yet still present one monolithic DLL.

BTW that 230MB DLL exports these 6 functions:

0 00CF1480 13571200 Fun ChromeMain
1 06DBE4B0 115074224 Fun CrashForExceptionInNonABICompliantCodeRange
2 02423320 37892896 Fun GetHandleVerifier
3 031AB2F0 52081392 Fun IsSandboxedProcess
4 0240DCD0 37805264 Fun RelaunchChromeBrowserWithNewCommandLineIfNeeded
5 08EF8C40 149916736 Fun sqlite3_dbdata_init
)

Richard Damon <richard@damon-family.org> writes:

> On 2/3/24 4:51 PM, Keith Thompson wrote:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>>
>>>>> On Thu, 01 Feb 2024 19:03:38 -0800, Keith Thompson wrote:
>>>>>
>>>>>> A #include directive with <> searches for a "header", which is
>>>>>> not stated to be a file. A #include directive with "" searches
>>>>>> for a file in an implementation-defined manner; if that search
>>>>>> fails, it tries again as if <> had been used.
>>>>>
>>>>> The trouble with that interpretation is, it would seem to rule
>>>>> out the use of things like include libraries for user headers.
>>>>> Do you really think that was the intention?
>>>>
>>>> I don't know. I imagine an implementation could interpret the
>>>> word "file" to include information extracted from libraries.
>>>> Note that it doesn't have to correspond to the concept of a
>>>> "file" used in <stdio.h>; that refers to files in the execution
>>>> environment, not the compilation environment.
>>>
>>> To me what the C standard says is clear. A #include "whatever.h"
>>> gets its stuff from a file (assuming of course the appropriate
>>> file can be found, and not revert to the #include <whatever.h>
>>> form). A #include <whatever.h> gets its stuff from a header,
>>> said header perhaps being stored in a file or perhaps not, and if
>>> file-stored then it could be a 1-1 relationship, or a 1-many
>>> relationship, or a many-1 relationship. Since the C standard
>>> doesn't define the term 'header', an implementation is allowed to
>>> actualize it however the implementation chooses (including the
>>> possibility of storing information inside the compiler itself).
>>
>> On further thought, I tend to agree.
>>
>> I was thinking that an implementation could usefully provide some
>> of its own headers as something other than files, as it's clearly
>> allowed to do for the C standard headers. But the obvious way to
>> do that would be to require such headers to be included with <>,
>> not "". POSIX-specific headers like unistd.h are already
>> conventionally included with <>.
>>
>> An implementation probably *could* bend the meaning of "file"
>> enough to support having `#include "whatever.h"` load something
>> other than a file in the host filesystem, but it's not as useful as
>> I first thought it might be -- and it could interfere with
>> user-provided header files that happen to have the same name.
>
> I beleive an implementation doesn't need to provide a way to provide
> replacements for the standard defined headers.
>
> The include search method is fully implementation defined,

Not exactly. The <> form of #include searches "a sequence of
implementation-defined places" for a header, whereas the "" form
of #include searches "in an implementation-defined manner" for
"the named source file". The sequence of places (for headers) is
fixed for each implementation, but where a "" form of #include
searches (for a file) is not fixed but may vary from, for example,
compilation to compilation. Of course there is nothing stopping
an implementation from defining those two searches so that there
is some overlap, but surely that possibility is not expected to be
realized in any normal configuration (except perhaps by accident),
either by the C standard's authors or by developers.

> with only
> the provision that if you use " " and don't find the file, it
> needs to use the < > method, but that doesn't say that the
> standard headers might not be first in the " " search order.

The "" form of #include doesn't have a "search order", only a
statement that a search is done "in an implementation-defined
manner". Normally the set of places searched for "" files is
not fixed, and typically can be changed by the developer using
compilation options such as -I.

> Als 7.1.2p4 says:
>
> If a file with the same name as one of the above < and > delimited
> sequences, not provided as part of the implementation, is placed in
> any of the standard places that are searched for included source
> files, the behavior is undefined.
>
> So overridding a Standard defined header is explicitly Undefined
> Behaivor. (Not sure if POSIX extends that to its headers).

I believe this conclusion is a misreading. The C standard uses the
word "places" only in connection with the <> form of #include, and
not with the "" form of #include. There is nothing wrong with, for
example, #include "stdio.h", and having a local stdio.h file (which
may do a #include <stdio.h> internally). Indeed it appears that
part of the point of the rule that the <> form is used if the ""
form fails is so that a #include "stdio.h" may be used and simply
fall back to the <stdio.h> header if the file stdio.h is not
present. There is no undefined behavior for having a file named
"stdio.h" (or any other standard header name), as long as such
files are not in one of the fixed set of places defined by the
implementation for where headers (as opposed to regular #include
source files) might reside.

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 :-)

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

> You haven't actually admitted that he has
> diagnosed a problem which needs to be solved

Why would I "admit" something I don't believe?

> and maybe I should have
> made that clearer.

It's not a matter of clarity - you said explicitly and clearly that I
had talked about "diagnosing the problem".

> Where you're right is that writing a better build
> system than make is hard. Bart referenced Norwegian, which obviously
> meant you, and so I didn't introduce your name.
>

I think Bart referenced Norwegian as something of a joke, as a pun on
programming languages and human languages and a reference to the
wandering topics we've had here recently.

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