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

On 2/4/2024 8:41 PM, Keith Thompson wrote:
> "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.
>

Is somebody watching me? ;^)

https://youtu.be/7YvAYIJSSZY

On 2/3/2024 2:19 PM, bart wrote:
> 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.

Just an object file created from an assembler.

On 2/3/2024 2:19 PM, bart wrote:
> On 03/02/2024 20:39, Chris M. Thomasson wrote:
>> On 2/3/2024 3:54 AM, bart wrote:
[...]
> For anything different, then you do this:
>
>    mcc prog.c -c

mcc, humm. Is you assembler called mas?

In article <87jznjle00.fsf@nosuchdomain.example.com>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>"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.

Nice to see you back, Keith. I've been worried about you.

"14 A View to a Kill Opening Theme 1985"

--
One should not believe everything posted to USENET.

- Aharon (Arnold) Robbins arnold AT skeeve DOT com -
- 4/15/19 -

On 2/4/2024 10:00 PM, Kenny McCormack wrote:
> In article <87jznjle00.fsf@nosuchdomain.example.com>,
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> "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.
>
> Nice to see you back, Keith. I've been worried about you.
>
> "14 A View to a Kill Opening Theme 1985"
>

Right. I posted that link because totally relying on an IDE can be a
view to a kill... ;^)

On 05/02/2024 01:07, 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. Or that he'll be
> able to do anything other than the most basic installation. It's a
> consumer platform.

It /is/ a consumer platform, yes. And because it has no standard ways
to build software, and no one (approximately) using it wants to build
software on it, the norm is to distribute code in binary form for
Windows. That works out fine for almost all Windows users. That
includes libraries - even C programmers on Windows don't want to build
"libjpeg" or whatever, they want a DLL.

And thus there is much less effort put into making projects easy to
build on Windows. People on Windows fall mostly into two categories -
those that neither know nor care about building software and want
ready-to-use binaries (that's almost all of them), and people who do
development work and are willing and able to invest time and effort
reading the readmes and install.txt files, looking at the structure of
the code, running the makefiles or CMakes, importing the project into
their favourite IDE, and whatever else.

It's not that Linux software developers go out of their way to annoy
Windows developers (well, /some/ do, but not many). But on Linux, and
widening to other modern *nix systems, there are standard ways to build
software. You know the people building it will have make, and gcc (or a
compatible compiler with many of the same extensions and flags, like
clang or icc), and development versions of countless libraries either
installed or a quick apt-get away. On Windows, however, they might have
MSVC, or cygwin, or mingw64, or TDM gcc, or lccwin, or tcc, or Borland
C++ builder. They might have a "make", but it could be MS's more
limited "nmake" version.

People who do their work and development on Linux can't be expected to
try to support every Windows setup. People who are making open source
software voluntarily (as distinct from people paid to do so) certainly
can't. It makes more sense for groups who specialise in porting and
building software in Windows to do that work for many projects, rather
than the original project developers doing that work. Thus groups like
msys2, TDM, and others take open source projects and make Windows
binaries for them.

On 05/02/2024 00:11, bart wrote:
> 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.
>
>
>>> 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.
>

There have been lots of OS's. MS DOS was - from the beginning - a hack
on a simple limited OS.

Older systems, or systems for more limited hardware, had limits on their
filenames - that is reasonable and makes sense. By the time of the IBM
PC, that should not have been necessary - at least not /so/ short names.
The all-caps names (which then led to the silly case insensitive
behaviour) had no excuse at all. And /relying/ on file extensions for
critical things like executable type was never smart. (File extensions
for user convenience is fine as a useful convention.)

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

Is it "funny" that in discussion about operating systems, I talked about
the operating system - not the hardware? I agree that the IBM PC
hardware was pathetic for its time - for a start, it should have been,
as the designers wanted, built around an 68000 cpu.

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

They were doing all the important work. They still are.

(And I certainly don't think Unix - either of that time, nor modern
descendants, are perfect. But you only see everything as black or
white, which is quite sad and pathetic.)

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

There was some file system on microdrives - otherwise, no, no file system.

I also worked with BBC Micros - now there was an OS that was extremely
well designed.

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

No, I just think they could have done a lot better with what they had.

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

I understand how DOS and its descendants handle this. I understand how
almost every other file system and OS handles this. I know which is better.

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

I appreciate that many decisions were the best choice at the time, and
afterwards you are stuck with the consequences of that. Most of what I
think is bad in C falls into that category.

But some decisions were also clearly inferior at the time they were made.

On 30/01/2024 08:17, David Brown wrote:
> On 30/01/2024 02:45, bart wrote:
>> On 30/01/2024 00:57, Lawrence D'Oliveiro wrote:
>>> On Mon, 29 Jan 2024 16:03:45 +0000, bart wrote:
>>>
>>>> By 'Build System', I mean a convenient or automatic way to tell a
>>>> compiler which source and library files comprise a project, one that
>>>> doesn't involve extra dependencies.
>>>
>>> If it only works for C code, then that is going to limit its
>>> usefulness in
>>> today’s multilingual world.
>>
>> Languages these days tend to have module schemes and built-in means of
>> compiling assemblies of modules.
>>
>> C doesn't.
>>
>> The proposal would allow a project to be built using:
>>
>>     cc file.c
>>
>> instead of cc file.c file2.c .... lib1.dll lib2.dll ...,
>>
>> or instead of having to provide a makefile or an @ filelist.
>>
>> That is significant advance on what C compilers typically do.
>
> You are absolutely right that C does not have any real kind of module
> system, and that can be a big limitation compared to other languages.
> However, I don't think the build system is where the lack of modules is
> an issue - it is the scaling of namespaces and identifier clashes that
> are the key challenge for large C projects.
>
> Building is already solved - "make" handles everything from tiny
> projects to huge projects.  When "make" isn't suitable, you need /more/,
> not less - build server support, automated build and test systems, etc.
> And for users who like simpler things and have simpler projects, IDE's
> are almost certainly a better option and will handle project builds.
>
> I don't doubt that your build system is simpler and easier for the type
> of project for which it can work - but I doubt that there are many
> people who work with such limited scope projects and who don't already
> have a build method that works for their needs.  Still, if it is useful
> for you, and useful for some other people, then that makes it useful.
>
>

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

On 05.02.2024 13:42, David Brown wrote:
> On 05/02/2024 00:11, bart wrote:
>>
>> [...] Oh, you mean Unix was the One and Only Real OS? I get it.

(Obviously not.)

> There have been lots of OS's. MS DOS was - from the beginning - a hack
> on a simple limited OS.

And MS marketing was able to foster a community who could easily be
brainwashed to find it natural that SW is so buggy and unreliable.
And few (from the many) flaws, deficiencies, and bugs can be clumsily
worked around. Countless "experts" were arising from that who have
specialized "guru wisdom" about the magic to work around some of these
well known flaws. Blue screens were common. A standard tip - and even
still in use nowadays! - was and is "Reboot your system.", and if that
doesn't help then "Reinstall the software.", or the "Reinstall the OS"
if nothing helped, and finally "Wait for version N+1 of this OS, there
will be all good then." - and of course it never was.

>
> [...]
> The all-caps names (which then led to the silly case insensitive
> behaviour) had no excuse at all.

All caps was initially a historic restriction of many OSes due to the
limited character sets. At some point working case sensitivity became
possible and supported; MS was not amongst the first here. Later the
need for non-ASCII and internationalization became prevalent and it
became technically possible to support that. Meanwhile we have multi-
lingual computing. For certain user front-ends of applications it is
more useful to not distinguish case; see Google search for a prominent
example. For other application (or OS) interfaces it is necessary (or
at least much desired) to support not only case sensitivity but also
regular expression searches. Unix systems supported that inherently.
In other contexts it needed decades to even consider supporting a
switch to activate such a feature. Later applications supported own
methods, for example to include or exclude words in searches.

> And /relying/ on file extensions for
> critical things like executable type was never smart. (File extensions
> for user convenience is fine as a useful convention.)
>
>> [...]
>
> Is it "funny" that in discussion about operating systems, I talked about
> the operating system - not the hardware? I agree that the IBM PC
> hardware was pathetic for its time - for a start, it should have been,
> as the designers wanted, built around an 68000 cpu.

One of the best and outstanding pieces of hardware from that time
was (IMO) the IBM PC's "Model M" keyboard. (I'm still typing on a
Model M clone.)

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

(And I heard at that time that 640k would be more than enough. LOL.)

> No, I just think they could have done a lot better with what they had.

Indeed. (But they refused. It's easier to manipulate a user base by
the marketing division than fix inherently broken things.)

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

Again "guessing"? Or just making up things? Or creating a straw man?"

Frankly, I don't understand what argument you want to construct here,
Bart.

73.945.112 seems obviously to be a standard representation of a number
with eight figures, using one of many internationally used separators.
While some computer languages indeed allow to process "73 945 112" and
also "73945112", you cannot expect that legibility support. Mostly, if
at all, you may have the option to choose decimals after the "comma"
only, as in 123.34$ or 123,45€.

(But your intention here was most likely anyway just a red herring.)

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

Filenames consisting of "two parts" is a fundamental misconception.

>
> I understand how DOS and its descendants handle this. I understand how
> almost every other file system and OS handles this. I know which is
> better.
>
>> [...]
>>
>> In hindsight, with filenames now allowing arbitrary dots, they made
>> the right decision.

(What a bright enlightenment. Great.)

>> But that was more due to luck. And probably not
>> having to make concessions to running on low-end hardware.

(And again some stupid continuation; random guesses based on opinion.)

>> [...]

Janis

On 30/01/2024 08:17, David Brown wrote:
>
> You are absolutely right that C does not have any real kind of module
> system, and that can be a big limitation compared to other languages.
> However, I don't think the build system is where the lack of modules is
> an issue - it is the scaling of namespaces and identifier clashes that
> are the key challenge for large C projects.
>
> Building is already solved - "make" handles everything from tiny
> projects to huge projects.  When "make" isn't suitable, you need /more/,
> not less - build server support, automated build and test systems, etc.
> And for users who like simpler things and have simpler projects, IDE's
> are almost certainly a better option and will handle project builds.
>
We don't use make in our build system. I didn't devise it. I don't think
it was specifically rejected. It just wasn't useful and there were
better ways of achieving the same things. However I'm glad I don't have
to maintain makefiles.

The build system isn't really about specifying an executable from
sources. If that was all there was to I'd probably heve been told to set
it up myself. It's more about giving people access to sources and
ensuring that they are consistent and the right version is being used,
then making sure that the excutable is built with the same compilers and
from the same sources on every machine, and automatically packaging the
executables and passing them on to testers and ultimately to customers,
and making sure that the customer has the right version. It all takes a
lot of doing and more money has been spent on the distribution system
than the actual programs, and the build system is completely integrated
with it. Whilst it works well, it isn't really solved, and someone has a
job devoted to it.

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

bart <bc@freeuk.com> writes:
>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.

Nobody other than you have made such a claim.

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:

> On 2/4/2024 8:41 PM, Keith Thompson wrote:
>
>> [...]
>>
>> Better yet, if you could cut down on the followups that don't add
>> anything relevant, I for one would appreciate it.

For what it's worth, I second Keith's request, and strenuously
support it.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On 30/01/2024 08:17, David Brown wrote:

>The build system isn't really about specifying an executable from
>sources. If that was all there was to I'd probably heve been told to set
>it up myself. It's more about giving people access to sources and
>ensuring that they are consistent and the right version is being used,

Now you are changing the topic from build system to source code control
system, git.

On 05/02/2024 12:02, David Brown wrote:
> On 05/02/2024 01:07, Malcolm McLean wrote:
>>
> It's not that Linux software developers go out of their way to annoy
> Windows developers (well, /some/ do, but not many).  But on Linux, and
> widening to other modern *nix systems, there are standard ways to build
> software.  You know the people building it will have make, and gcc (or a
> compatible compiler with many of the same extensions and flags, like
> clang or icc), and development versions of countless libraries either
> installed or a quick apt-get away.  On Windows, however, they might have
> MSVC, or cygwin, or mingw64, or TDM gcc, or lccwin, or tcc, or Borland
> C++ builder.  They might have a "make", but it could be MS's more
> limited "nmake" version.
>
Usually they will have Visual Studio if they want to develop native
Windows programs, but then for emulation there are lots of systems and
it's hard to say.
>
> People who do their work and development on Linux can't be expected to
> try to support every Windows setup.  People who are making open source
> software voluntarily (as distinct from people paid to do so) certainly
> can't.  It makes more sense for groups who specialise in porting and
> building software in Windows to do that work for many projects, rather
> than the original project developers doing that work.  Thus groups like
> msys2, TDM, and others take open source projects and make Windows
> binaries for them.
>
I program Windows and Linux. Whilst I own a Linux machine, I currently
don't have room to set it up. I find I just can't work on a laptop. So
currently I'm only developing on Windows and Mac. Which is a bit of
nuisance. I try to make everything I do work on Windows and Linux if
possible, because I personally move between them a lot. Baby X is a
cross-platform GUI that enables simple GUI programs to work on both
Windows and Linux, but the problem is that it's too ambitious for a one
man project, and whilst it works it's not really mature enough for
anything other than very basic programs. It is of course open source and
free to anyone to use for any purpose they find useful. As a developer
rather than a user, obviously Windows binaries without source which can
be built on Windows aren't much use to me.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 05/02/2024 14:48, Scott Lurndal wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> On 30/01/2024 08:17, David Brown wrote:
>
>> The build system isn't really about specifying an executable from
>> sources. If that was all there was to I'd probably heve been told to set
>> it up myself. It's more about giving people access to sources and
>> ensuring that they are consistent and the right version is being used,
>
> Now you are changing the topic from build system to source code control
> system, git.

It's completely integrated. The build system builds the debug
executables that I develop on my personal machine, and also the
executables we distribute to customers. And it ensures that if someone
else puts something on git, I pick uo the right version. Source control,
building the executable, and distibuting it is completely seamless and
it's the same suite of programs, managed and controlled by the same
person, who isn't me.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 05/02/2024 13:59, Janis Papanagnou wrote:
> On 05.02.2024 13:42, David Brown wrote:
>> On 05/02/2024 00:11, bart wrote:
>>>
>>> [...] Oh, you mean Unix was the One and Only Real OS? I get it.
>
> (Obviously not.)
>
>> There have been lots of OS's. MS DOS was - from the beginning - a hack
>> on a simple limited OS.
>
> And MS marketing was able to foster a community who could easily be
> brainwashed to find it natural that SW is so buggy and unreliable.
> And few (from the many) flaws, deficiencies, and bugs can be clumsily
> worked around. Countless "experts" were arising from that who have
> specialized "guru wisdom" about the magic to work around some of these
> well known flaws. Blue screens were common. A standard tip - and even
> still in use nowadays! - was and is "Reboot your system.", and if that
> doesn't help then "Reinstall the software.", or the "Reinstall the OS"
> if nothing helped, and finally "Wait for version N+1 of this OS, there
> will be all good then." - and of course it never was.

Yeah, because no other OS has ever required a hard reboot. I've had to
do a hard power-off and power-on cycle endless times on smart TVs,
phones and tablets. None of them ran Windows.

>>
>> [...]
>> The all-caps names (which then led to the silly case insensitive
>> behaviour) had no excuse at all.
>
> All caps was initially a historic restriction of many OSes due to the
> limited character sets. At some point working case sensitivity became
> possible and supported; MS was not amongst the first here. Later the
> need for non-ASCII and internationalization became prevalent and it
> became technically possible to support that. Meanwhile we have multi-
> lingual computing. For certain user front-ends of applications it is
> more useful to not distinguish case; see Google search for a prominent
> example.

Pretty much every front-end not aimed at technical users is
case-insensitive.

Most people will also come across case-sensitive filenames simply
because the underlying *nix file system is exposed.

Even then, sensible steps have been taken to ensure that main parts of
URLs and email addresses are case-insensitive. There it is easy to see
what chaos could ensue otherwise.

> Filenames consisting of "two parts" is a fundamental misconception.

File specs can consist of multiple parts. On OSes that used drive
letters like:

A:filename.ext

then that has 3 parts. It would be ludicrous to store that "A:" inside a
directory. Especiall on media that then ends up as drive B:.

Even in a file-spec like this:

/a/b/c/filename.ext

Is the full string "/a/b/c/filename.ext" stored in the directory entry
for this file, or is it split up into different components?

I don't know; you tell me. The former looks unwieldy.

On some OSes the filetype was an attribute, stored separately from the
filename, and displayed with a "." separator.

In the same way, with these qualified names in some language source code:

a.b.c
a::b::c

it is extremely unlikely that those "." and "::" symbols actually form
part of the identifier for each.

Meanwhile I need to use a small library of routines to split filespecs
up into path, base file, and extension.

>>
>> I understand how DOS and its descendants handle this. I understand how
>> almost every other file system and OS handles this. I know which is
>> better.
>>
>>> [...]
>>>
>>> In hindsight, with filenames now allowing arbitrary dots, they made
>>> the right decision.
>
> (What a bright enlightenment. Great.)
>
>>> But that was more due to luck. And probably not
>>> having to make concessions to running on low-end hardware.
>
> (And again some stupid continuation; random guesses based on opinion.)

But it might well be perfectly true; you don't know either. So it is
plausible.

Based on my examples above, having notional "." and "/" symbols seemed
the sensible thing to do. It is quite possible that Unix (remember this
was part of the same group that made all those wise decisions about C),
really did make that crass decision to actually store dots as part of
the filename.

BTW on Unix-like file systems, is a filename like "abc.def.ghi"
considered to have the extension "def.ghi", or "ghi"? If the latter,
then I take it that extensions can't have embedded dots?

On Windows, the extension is "ghi". If that is the case on Linux too,
then that treats the right-most dot specially.

But I get it: you deeply despise Windows, MSDOS, MS, and you hate me for
being an upstart.

>>> [...]
>
> Janis
>