On 2/3/2024 3:54 AM, bart wrote:
[...]

Say I want to use your C compiler. How do I use it when I need to
assemble and link external asm code? Say, I assembled something into an
..o file, how can I make your C compiler use it, link it in, ect...

Using the C ABI, I would create declarations for its functions.

masm version, intel syntax:

http://web.archive.org/web/20060214112539/http://appcore.home.comcast.net/appcore/src/cpu/i686/ac_i686_masm_asm.html

So, this creates some functions. How would I use your compiler to call
these functions from my C code in your system?

On 2/3/24 20:35, bart wrote:

> But what is the point? Do you routinely invoke cc with multiple files of
> mixed languages? 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.

And this is better done with a short Maakefile.

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

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
periority.
>
>It's a very silly attitude of course.

Ah, self-awareness after all...

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On 02/02/2024 18:26, Scott Lurndal wrote:
>> bart <bc@freeuk.com> writes:
>>> On 02/02/2024 15:18, Scott Lurndal wrote:
>
>
>To build a "smaller, easier, nicer" make, if that is the goal (and it's
>a very legitimate one),

No, it's not really a legitimate one, since make supports the
single file cases -without a makefile-.

And it supports the largest projects as well (the linux kernel,
for example, is built with make).

>(Unfortunately if you write C++ rather than C, even a 3.7 GHz machine
>isn't going to be fast enough. But maybe your users don't use C++).

FYI, on my 64-core 3.4Ghz build machine, it takes an hour
to build our C++ application on a single core. With -j32,
it finishes in a bit under 5 minutes. (32 because it is
a system shared by a number of users, and the compiles
end up I/O bound).

On Sat, 3 Feb 2024 05:52:18 +0000, Malcolm McLean wrote:

> .. but if you were given a UNIX system you were a
> bit special. And that gave UNIX programmers a sense of superiority.
>
> It's a very silly attitude of course.

Naturally. And a company like Microsoft, that is right now trying to turn
Windows into Linux, is simply behaving like a very silly company.

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.

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

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> as is a development tool. So there are two aspects to it. The first is
> deploying as itself. It must be available and capable of being invoked
> on all machines where it needs to be available. It mustn't refuse to
> run correctly because some path somewhere is not set up or it doesn't
> have write permission to output an executable, and so on. That may
> well have been achieved. Typing "as" into the shell on the computer
> I'm typing this on does indeed invoke the program.
>
> But the other side to it that as must make it easy to deploy the
> actual useful end user programs that it is used to develop. So if we
> write an as script, it must be easy to make that script part of an
> executable, place it on the user's machine, and set it up so that the
> user can easily run it and play space invaders or achieve whatever
> else he ultimately wishes to achieve. And what Bart is saying is that
> that is where as is falling down.

"as", as typically provided on Unix-like systems, has a command-line
interface that bart finds distasteful. There is nothing bart wants to
do that he can't do with the as interface, but he doesn't like the way
he has to do it. He has made the false claim that there's something
seriously wrong with "as". (It does have its quirks, but those quirks
are easy to work around, or even to use as intended.)

> I don't use as myself, so it's hard to commment on the specifics. But
> from experience with similar systems, this will be where the problems
> lie. The complaint sems to be that because of the quirky way in which
> it matches up scripts to output executables, it's too hard to package
> the scripts so that they are assembled correctly. Since as I say I
> don't use as I can't comment on that directly, but I can well believe
> it.

So you've simply assumed, without evidence, that the "as" command line
interface causes all these problems.

It doesn't.

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

bart <bc@freeuk.com> writes:
> On 03/02/2024 01:31, Lawrence D'Oliveiro wrote:
>> 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?

Yes, this is the filename extension which Linux (whether you're using
the term to refer to the kernel or to the OS) mostly ignores, but which
certain tools like gcc pay attention to.

[...]

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

On 03/02/2024 20:31, Chris M. Thomasson wrote:
> On 2/3/2024 8:03 AM, bart wrote:
> [...]
>
> Do you have a windows installation with a recent version of MSVC
> installed? Give vcpkg a go, and see how it builds things... Then
> automatically integrates them into MSVC. It's pretty nice and about
> time. ;^)

You haven't followed by posts very well. I want to keep as far away from
all that stuff as possible.

(The last time I installed VS, it took 90 minutes. Each time it started
up, usually by inadvertently because of file association, it took 90
seconds. On the same machine, an old one, it took 0.2 seconds to build
my C compiler.)

Everything I am about is managing to do this stuff by the simplest,
leanest means possible. If a program is written in C, then why would you
need anything other than a C compiler to build it?

On 03/02/2024 20:39, Chris M. Thomasson wrote:
> On 2/3/2024 3:54 AM, bart wrote:
> [...]
>
> Say I want to use your C compiler. How do I use it when I need to
> assemble and link external asm code? Say, I assembled something into an
> .o file, how can I make your C compiler use it, link it in, ect...
>
> Using the C ABI, I would create declarations for its functions.
>
>
> masm version, intel syntax:
>
> http://web.archive.org/web/20060214112539/http://appcore.home.comcast.net/appcore/src/cpu/i686/ac_i686_masm_asm.html
>
>
> So, this creates some functions. How would I use your compiler to call
> these functions from my C code in your system?

My compilers are written as self-contained products. Inputs are source
files in the language, the output is a EXE or DLL binary.

External code from other languages is usually dynamically linked. You
provide a C header file, and a DLL, say yourlib.dll:

mcc prog.c yourlib.dll

For anything different, then you do this:

mcc prog.c -c

This produces a standard prog.obj object file. Now you can use regular
tools to statically link with code from other languages.

I don't have my own tool to read .obj files and statically link them.
That could be done, but it is not a priority for my stuff.

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

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

On 2/3/2024 2:11 PM, bart wrote:
> On 03/02/2024 20:31, Chris M. Thomasson wrote:
>> On 2/3/2024 8:03 AM, bart wrote:
>> [...]
>>
>> Do you have a windows installation with a recent version of MSVC
>> installed? Give vcpkg a go, and see how it builds things... Then
>> automatically integrates them into MSVC. It's pretty nice and about
>> time. ;^)
>
> You haven't followed by posts very well. I want to keep as far away from
> all that stuff as possible.

Okay.

> (The last time I installed VS, it took 90 minutes. Each time it started
> up, usually by inadvertently because of file association, it took 90
> seconds. On the same machine, an old one, it took 0.2 seconds to build
> my C compiler.)

It boots right up for me, less than two seconds, even though it is
pretty damn fat.

> Everything I am about is managing to do this stuff by the simplest,
> leanest means possible. If a program is written in C, then why would you
> need anything other than a C compiler to build it?

Can you C compiler handle C11? If so, that would be great. This one can
do it, MSVC well, nope. MSVC handles C11 atomics, but not threads! GRRRRR.

http://www.smorgasbordet.com/pellesc

On 04/02/2024 00:24, Chris M. Thomasson wrote:
> On 2/3/2024 2:11 PM, bart wrote:
>> On 03/02/2024 20:31, Chris M. Thomasson wrote:
>>> On 2/3/2024 8:03 AM, bart wrote:
>>> [...]
>>>
>>> Do you have a windows installation with a recent version of MSVC
>>> installed? Give vcpkg a go, and see how it builds things... Then
>>> automatically integrates them into MSVC. It's pretty nice and about
>>> time. ;^)
>>
>> You haven't followed by posts very well. I want to keep as far away
>> from all that stuff as possible.
>
> Okay.
>
>
>> (The last time I installed VS, it took 90 minutes. Each time it
>> started up, usually by inadvertently because of file association, it
>> took 90 seconds. On the same machine, an old one, it took 0.2 seconds
>> to build my C compiler.)
>
> It boots right up for me, less than two seconds, even though it is
> pretty damn fat.

It might be faster now on my SSD drive. However my own stuff didn't need
an SSD drive; that's part of the point of keeping things small.

>
>
>> Everything I am about is managing to do this stuff by the simplest,
>> leanest means possible. If a program is written in C, then why would
>> you need anything other than a C compiler to build it?
>
> Can you C compiler handle C11? If so, that would be great. This one can
> do it, MSVC well, nope. MSVC handles C11 atomics, but not threads! GRRRRR.

It compiles some undefined subset of C. But I haven't touched that side
of it for years. That last update of it changed the backend.

MCC is anyway now a private tool. Either programs work with it or they
don't.

But the problem being discussed at length is getting that input into the
compiler in the first place!

Everybody says use makefiles; well they don't work. They tend to be
heavily skewed towards the use of gcc. My compiler isn't gcc.

AFAIK the C standard doesn't mention gcc (nor, probably, makefiles!).

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:

cc ...

And after 100s of posts, still nobody gets it. Oh, just use an
invariably Linux-centric, gcc-centric script in a different language.
How about an OS-neutral, compiler-neutral solution that doesn't involve
a third-party language? (English - or Norwegian - accepted.)

On 2/3/2024 5:19 PM, bart wrote:
[...]
> Everybody says use makefiles; well they don't work. They tend to be
> heavily skewed towards the use of gcc. My compiler isn't gcc.

Shit happens. What else can I say? ;^o

[...]

On 04/02/2024 12:19, bart wrote:
> On 04/02/2024 00:24, Chris M. Thomasson wrote:
>> On 2/3/2024 2:11 PM, bart wrote:
>>> On 03/02/2024 20:31, Chris M. Thomasson wrote:
>>>> On 2/3/2024 8:03 AM, bart wrote:
>>>> [...]
>>>>
>>>> Do you have a windows installation with a recent version of MSVC
>>>> installed? Give vcpkg a go, and see how it builds things... Then
>>>> automatically integrates them into MSVC. It's pretty nice and about
>>>> time. ;^)
>>>
>>> You haven't followed by posts very well. I want to keep as far away
>>> from all that stuff as possible.
>>
>> Okay.
>>
>>
>>> (The last time I installed VS, it took 90 minutes. Each time it
>>> started up, usually by inadvertently because of file association, it
>>> took 90 seconds. On the same machine, an old one, it took 0.2 seconds
>>> to build my C compiler.)
>>
>> It boots right up for me, less than two seconds, even though it is
>> pretty damn fat.
>
> It might be faster now on my SSD drive. However my own stuff didn't need
> an SSD drive; that's part of the point of keeping things small.
>
>>
>>
>>> Everything I am about is managing to do this stuff by the simplest,
>>> leanest means possible. If a program is written in C, then why would
>>> you need anything other than a C compiler to build it?
>>
>> Can you C compiler handle C11? If so, that would be great. This one
>> can do it, MSVC well, nope. MSVC handles C11 atomics, but not threads!
>> GRRRRR.
>
> It compiles some undefined subset of C. But I haven't touched that side
> of it for years. That last update of it changed the backend.
>
> MCC is anyway now a private tool. Either programs work with it or they
> don't.
>
> But the problem being discussed at length is getting that input into the
> compiler in the first place!
>
> Everybody says use makefiles; well they don't work. They tend to be
> heavily skewed towards the use of gcc. My compiler isn't gcc.
>
> AFAIK the C standard doesn't mention gcc (nor, probably, makefiles!).
>
> 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:
>
>     cc ...
>
> And after 100s of posts, still nobody gets it. Oh, just use an
> invariably Linux-centric, gcc-centric script in a different language.
> How about an OS-neutral, compiler-neutral solution that doesn't involve
> a third-party language? (English - or Norwegian - accepted.)
>
>
Oh, you mean FORTRAN-IV?

On 03.02.2024 16:19, Tim Rentsch wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>
>> [.. various philosophical musings ..]
>
> Please take this irrelevant crap somewhere else. Thank you.

Again you play the control freak addressing a posting from me, and
again a clearly tagged one. If you are suffering so much from your
obsession it would certainly be the easiest for you to just put me
in your kill-file. (Okay, I know, it wouldn't satisfy your control
freak exposition, but I'm nonetheless sure you'd feel better. It's
worth a try, I'm sure!)

See... *p* ...and your posts are gone, it's so easy. Just try it.
I'll certainly feel better now that I don't see your pathological
posts any more, not only your control freak posts but also all the
other personal junk that you regularly emit in your other replies
to the audience here.

Janis

On 02.02.2024 18:29, Kaz Kylheku wrote:
> On 2024-02-02, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> In article <20240202165335.0000384a@yahoo.com>,
>> Michael S <already5chosen@yahoo.com> wrote:
>> ...
>>>> I have no idea who that is, so I'll take your word for it.
>>>>
>>>
>>> Inventor of make
>>
>> At Bell Labs, in 1976.
>>
>> Currently, like quite a few ex-Bell Labs people, a big wheel at Google.

Also fired from AT&T/Bell Labs like the/some other Unix pioneers?

>
> It's like a cargo cult. If we hire old Unix geezers and prop them up in
> chairs, be they dead or alive, magic will happen.

Certainly no magic. But I'd also not disdain their experience.
It has its price, and management typically considers that most.
Google might have more money to afford the expenses.

Janis

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:
>
>     cc ...
>
> And after 100s of posts, still nobody gets it. Oh, just use an
> invariably Linux-centric, gcc-centric script in a different language.
> How about an OS-neutral, compiler-neutral solution that doesn't involve
> a third-party language? (English - or Norwegian - accepted.)
>
>
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.

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

On 2/3/2024 8:56 PM, 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:
>>
>>      cc ...
>>
>> And after 100s of posts, still nobody gets it. Oh, just use an
>> invariably Linux-centric, gcc-centric script in a different language.
>> How about an OS-neutral, compiler-neutral solution that doesn't
>> involve a third-party language? (English - or Norwegian - accepted.)
>>
>>
> 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.

I have had some bad experiences, but it was all my fault. One time I
forgot to install a prerequisite to a lib, that was a prerequisite for
another lib. Pissed me off! Then, I have had some interesting linker errors.

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

On 04/02/2024 04:29, Janis Papanagnou wrote:
> On 03.02.2024 16:19, Tim Rentsch wrote:
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>
>>> [.. various philosophical musings ..]
>>
>> Please take this irrelevant crap somewhere else. Thank you.
>
> Again you play the control freak addressing a posting from me, and
> again a clearly tagged one. If you are suffering so much from your
> obsession it would certainly be the easiest for you to just put me
> in your kill-file. (Okay, I know, it wouldn't satisfy your control
> freak exposition, but I'm nonetheless sure you'd feel better. It's
> worth a try, I'm sure!)
>
> See... *p* ...and your posts are gone, it's so easy. Just try it.
> I'll certainly feel better now that I don't see your pathological
> posts any more, not only your control freak posts but also all the
> other personal junk that you regularly emit in your other replies
> to the audience here.
>

Don't respond like that. Sweetness and light. It always wins in the long
run.

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

On 2/3/2024 9:36 PM, Chris M. Thomasson wrote:
> On 2/3/2024 8:56 PM, 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:
>>>
>>>      cc ...
>>>
>>> And after 100s of posts, still nobody gets it. Oh, just use an
>>> invariably Linux-centric, gcc-centric script in a different language.
>>> How about an OS-neutral, compiler-neutral solution that doesn't
>>> involve a third-party language? (English - or Norwegian - accepted.)
>>>
>>>
>> 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.
>
> I have had some bad experiences, but it was all my fault. One time I
> forgot to install a prerequisite to a lib, that was a prerequisite for
> another lib. Pissed me off! Then, I have had some interesting linker
> errors.

A couple of decades a go, I remember having a linker issue. I was
banging my head against the wall saying why won't this god damn bastard
link! Turns out that I forgot that I had altered one of the makefiles to
use a directory I was using for experiments. Totally forgot about it.
Uughhhh, damn it. Anyway, I finally fixed it in the makefile, and
everything linked up fine, and passed all unit tests. Grrr!

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

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

On Sat, 3 Feb 2024 14:59:14 +0000, bart wrote:

> I'm concerned about increasing bloat and complexity everywhere. So I'm
> just making a stand by developing my own small, human-scale products.

And you run your stuff on what is probably the most bloated, monolithic,
inflexible, unwieldy, clumsy, overcomplicated, inefficient and bug-ridden
OS in existence--Microsoft Windows.

On 04/02/2024 06:51, Lawrence D'Oliveiro wrote:
> On Sat, 3 Feb 2024 14:59:14 +0000, bart wrote:
>
>> I'm concerned about increasing bloat and complexity everywhere. So I'm
>> just making a stand by developing my own small, human-scale products.
>
> And you run your stuff on what is probably the most bloated, monolithic,
> inflexible, unwieldy, clumsy, overcomplicated, inefficient and bug-ridden
> OS in existence--Microsoft Windows.

I'm sure others can give it a run for its money too. I remember my
Android phone taking 3 minutes to do a restart.

However that vast complexity doesn't get in the way of building C
programs which is what this is about.

But the complexity of Linux CAN get in the way of that, since many build
processes like to utilise half of its features, and that complexity then
needs to be replicated on Windows it I want to build something there.

So while your hatred of Windows is irrational; my dislike of Linux is
rational, since it directly affects the subject of the thread.