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

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

"Chris M. Thomasson" , dans le message <upm7na$3943m$5@dont-email.me>, a
écrit :
> Not true. First of all you need to download MSVC first

No, first you have to sell your soul and freedom to be allowed to download
it.

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

Janis Papanagnou , dans le message <upqpko$aild$1@dont-email.me>, a
écrit :
> 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.

Please do not rewrite history. Marketing and community has nothing to do
with it, the magic trick was to convince hardware vendors to ship the OS
pre-installed and then trap them with exclusivity contracts and NDAs about
the price.

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.

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

On 2/4/24 18:10, Chris M. Thomasson wrote:
> 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.
>

But the tools are *still preinstalled*, so installers can definitely
rely on compiling stuff.

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

--
user <candycane> is generated from /dev/urandom

On 2/4/24 16:02, Chris M. Thomasson wrote:
> 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.

Windows making such a big deal over file extensions and outright hiding
them is silly IMO
--
user <candycane> is generated from /dev/urandom

On Sun, 4 Feb 2024 01:19:53 +0000, bart <bc@freeuk.com> 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.

By default a lot of builtin "implicit rules" determine which
program to use to make a .o from a .c etc. etc., and yes, that
is GCC-centric.

However, it is possible to remove all of those rules by calling
make as
make -rR
meaning:
-r, --no-builtin-rules
-R, --no-builtin-variables
, or by writing an empty
.SUFFIXES:
section in the Makefile.

Then, provide an include file "myrules.mk" with your own rules.

<https://www.gnu.org/software/make/manual/make.html#Old_002dFashioned-Suffix-Rules>

Something like :
%.o : %.c
mcc $< -o $@

etc., and include that in your Makefile with
include myrules.mk

<https://www.gnu.org/software/make/manual/make.html#Including-Other-Makefiles>

I apologize in advance if I missed a post in this huge thread
that already hinted you for that.

--
Regards,
Kees Nuyt

Kees Nuyt <k.nuyt@nospam.demon.nl> writes:
> On Sun, 4 Feb 2024 01:19:53 +0000, bart <bc@freeuk.com> 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.
>
> By default a lot of builtin "implicit rules" determine which
> program to use to make a .o from a .c etc. etc., and yes, that
> is GCC-centric.

Not really. "make" is older than gcc, and GNU make was first released
about a year after the initial release of gcc.

Even modern GNU is not gcc-specific. It assumes by default that the C
compiler is called "cc" (which resolves to "gcc" on many systems, but it
doesn't have to).

Rather gcc mimics the user interface of earlier UNIX C compilers.

--
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 05/02/2024 16:48, candycanearter07 wrote:
> On 2/4/24 16:02, Chris M. Thomasson wrote:
>> 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.
>
> Windows making such a big deal over file extensions and outright hiding
> them is silly IMO

Hiding the extension is a complete nightmare. Unless the automatic
recognition system works perfectly, you can end up with a file you can't
use.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 2/5/24 11:29, Malcolm McLean wrote:
> On 05/02/2024 16:48, candycanearter07 wrote:
>> On 2/4/24 16:02, Chris M. Thomasson wrote:
>>> 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.
>>
>> Windows making such a big deal over file extensions and outright
>> hiding them is silly IMO
>
> Hiding the extension is a complete nightmare. Unless the automatic
> recognition system works perfectly, you can end up with a file you can't
> use.

Or they could just use the magic number as a fallback..
--
user <candycane> is generated from /dev/urandom

On 2024-02-04, bart <bc@freeuk.com> 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.

Programmers and Developers do.

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

Encrypted? I always thought makefiles were plain text? You can read them
with less^H^H^H^H "more" - which if memory serves, is also a DOS command?

As an aside I skip most of this rubbish and just dip in occasionally.
But I think I have some measure of where bart is coming from. Some
people come at things not as they are, but as they wish they were given
their background.

I'll go back to lurking and just dipping into this if I've time to waste.

On 05/02/2024 17:37, Jim Jackson wrote:
> On 2024-02-04, bart <bc@freeuk.com> 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.
>
> Programmers and Developers do.
>
>> Or if they do, they are unwilling to part with that information. It is
>> encrypted into a makefile, or worse.
>
> Encrypted? I always thought makefiles were plain text? You can read them
> with less^H^H^H^H "more" - which if memory serves, is also a DOS command?
>
Here's one on my machine I selected almost at random

!ifndef BCROOT
BCROOT=$(MAKEDIR)\..
!endif

BCC32 = $(BCROOT)\bin\Bcc32.exe

IDE_LinkFLAGS32 = -L$(BCROOT)\LIB
COMPOPTS= -O2 -tWC -tWM- -Vx -Ve -D_NO_VCL; -I../../../../;
-L..\..\build\bcb5

timer.exe : regex_timer.cpp
$(BCC32) @&&|
$(COMPOPTS) -e$@ regex_timer.cpp
|

Whilst some of this is pretty clear, it's not all obvious what the
second half of the line
$(BCC32) @&&|
is meant to mean.

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

On 2024-02-05, candycanearter07 <no@thanks.net> wrote:
> But the tools are *still preinstalled*, so installers can definitely
> rely on compiling stuff.

No, they aren't. It's common for devel tools not to be part of the base
system of a distro.

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

On 05/02/2024 18:03, Malcolm McLean wrote:
> On 05/02/2024 17:37, Jim Jackson wrote:
>> On 2024-02-04, bart <bc@freeuk.com> 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.
>>
>> Programmers and Developers do.
>>
>>> Or if they do, they are unwilling to part with that information. It is
>>> encrypted into a makefile, or worse.
>>
>> Encrypted? I always thought makefiles were plain text? You can read them
>> with less^H^H^H^H "more" - which if memory serves, is also a DOS command?
>>
> Here's one on my machine I selected almost at random
>
> !ifndef BCROOT
> BCROOT=$(MAKEDIR)\..
> !endif
>
> BCC32   = $(BCROOT)\bin\Bcc32.exe
>
> IDE_LinkFLAGS32 =  -L$(BCROOT)\LIB
> COMPOPTS= -O2 -tWC -tWM- -Vx -Ve -D_NO_VCL; -I../../../../;
> -L..\..\build\bcb5
>
>
> timer.exe : regex_timer.cpp
>   $(BCC32) @&&|
>  $(COMPOPTS) -e$@ regex_timer.cpp
> |
>
>
> Whilst some of this is pretty clear, it's not all obvious what the
> second half of the line
> $(BCC32) @&&|
> is meant to mean.
>
>

I thought of some project and decided to look at NASM sources, choosing
2.15 from a few years ago as it might be simpler.

There was no makefile, only makefile.in of 1000 lines. If I type 'make',
it says no targets found.

There was also 'configure' of 11,000 lines, so I switched to WSL. Now
typing ./configure shows:

-bash: ./configure: /bin/sh^M: bad interpreter: No such file or directory

So it doesn't work on Linux either. If I look at INSTALL, it actually
says use "sh configure". That now says:

: not found14:
configure: 30: Syntax error: newline unexpected (expecting ")")

The entire project is only 106 .c files.

If I try compiling a random .c file, it complains of a missing header.

This is all quite typical.

Kees Nuyt <k.nuyt@nospam.demon.nl> writes:
>On Sun, 4 Feb 2024 01:19:53 +0000, bart <bc@freeuk.com> 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.
>
>By default a lot of builtin "implicit rules" determine which
>program to use to make a .o from a .c etc. etc., and yes, that
>is GCC-centric.

I wouldn't call them GCC-centric, for the most it is POSIX-centric,
i.e.
CC = cc

Although there is
CXX = g++

The built-in recipes are pretty generic.

%.o: %.c
# recipe to execute (built-in):
$(COMPILE.c) $(OUTPUT_OPTION) $<

%.cc:

%: %.cc
# recipe to execute (built-in):
$(LINK.cc) $^ $(LOADLIBES) $(LDLIBS) -o $@

%.o: %.cc
# recipe to execute (built-in):
$(COMPILE.cc) $(OUTPUT_OPTION) $<

%.C:

%: %.C
# recipe to execute (built-in):
$(LINK.C) $^ $(LOADLIBES) $(LDLIBS) -o $@

%.o: %.C
# recipe to execute (built-in):
$(COMPILE.C) $(OUTPUT_OPTION) $<

%.cpp:

%: %.cpp
# recipe to execute (built-in):
$(LINK.cpp) $^ $(LOADLIBES) $(LDLIBS) -o $@

%.o: %.cpp
# recipe to execute (built-in):
$(COMPILE.cpp) $(OUTPUT_OPTION) $<

You can always override the variable on the make command line

$ make CC=bcc

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On 05/02/2024 17:37, Jim Jackson wrote:
>> On 2024-02-04, bart <bc@freeuk.com> 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.
>>
>> Programmers and Developers do.
>>
>>> Or if they do, they are unwilling to part with that information. It is
>>> encrypted into a makefile, or worse.
>>
>> Encrypted? I always thought makefiles were plain text? You can read them
>> with less^H^H^H^H "more" - which if memory serves, is also a DOS command?
>>
>Here's one on my machine I selected almost at random
>
>!ifndef BCROOT
>BCROOT=$(MAKEDIR)\..
>!endif
>
>BCC32 = $(BCROOT)\bin\Bcc32.exe
>
>IDE_LinkFLAGS32 = -L$(BCROOT)\LIB
>COMPOPTS= -O2 -tWC -tWM- -Vx -Ve -D_NO_VCL; -I../../../../;
>-L..\..\build\bcb5
>
>
>timer.exe : regex_timer.cpp
> $(BCC32) @&&|
> $(COMPOPTS) -e$@ regex_timer.cpp
>|

The recipes are executed using the host shell.

That must be one of barts makefiles.

As it is shown, it is not a valid make recipe for any unix or
linux shell.

timer.exe: regex_timer.cpp
$(BCC32) $(COMPOPTS) -e $@ regex_timer.cpp

would be more likely, but the parameter to '-e' is completely
interpeted by whatever program is specified by the BCC32 variable.

On 2/5/2024 7:45 AM, bart wrote:
[...]
> 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.
[...]
You never experienced a blue screen of death on Windows?

bart <bc@freeuk.com> writes:
[...]
> There was also 'configure' of 11,000 lines, so I switched to WSL. Now
> typing ./configure shows:
>
> -bash: ./configure: /bin/sh^M: bad interpreter: No such file or directory

It looks like you've downloaded the source as a .zip file, which was
packaged incorrectly. I've reported this to their mailing list. Try
downloading the .tar.gz file instead.

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