scott@slp53.sl.home (Scott Lurndal) writes:

> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>
>> On 2024-02-05, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>> [...]
>> The Glibc shared library loading mechanism doesn't implement the nice
>> strategy of finding libraries in the same directory as the executable.
>
> Sure it does, if you tell it to. viz. LD_LIBRARY_PATH.

I would appreciate if folks posting stuff that pertains
almost exclusively to comp.unix.programmer would take
comp.lang.c off of those postings. Thank you.

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:

> On Tue, 06 Feb 2024 20:32:49 +0000, Lawrence D'Oliveiro wrote:
>
>> On Tue, 06 Feb 2024 19:20:06 GMT, Scott Lurndal wrote:
>>
>>> LD_LIBRARY_PATH isn't a distro thing, its a shell thing
>>> interpreted by the dynamic linker. The dynamic linker has
>>> a set of default paths that it uses, set by the distro,
>>> which can be overridden in LD_LIBRARY_PATH by each user.
>>
>> It?s a GNU thing, I think.
>
> It's a UNIX thing. GNU supports it, as it supports other
> UNIX requirements.

I would appreciate if folks posting stuff that pertains
almost exclusively to comp.unix.programmer would take
comp.lang.c off of those postings. Thank you.

On 2024-02-09, bart <bc@freeuk.com> wrote:
> On 09/02/2024 00:58, Ben Bacarisse wrote:
>> bart <bc@freeuk.com> writes:
>
>>> BTW if gcc /isn't/ installed, do you still get a bunch of standard C
>>> headers in /usr/include? If so, what do you have to select to not install
>>> them?
>>
>> I can't say what happens without specifics. There are hundreds of Linux
>> distributions.
>>
>> This is exactly why I was curious about what prompted Malcolm's
>> confident statement about what comes with "Linux" -- it runs contrary to
>> my limited experience.
>
> Not to mine. I thought the big deal with Linux compared with Windows was
> that it came with compilers, headers and libraries at least for C.

Desktop GNU/Linux distributions come with thousands of packages.
You don't get all of them by default. That's what the thread is about.

Depending on the distro, getting the compilers that could be as little
as answering one question: like for instance that your installation
type is that of a development workstation.

People just looking to surf the web and use e-mail don't require
compilers.

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

bart <bc@freeuk.com> writes:

> On 09/02/2024 00:58, Ben Bacarisse wrote:
>> bart <bc@freeuk.com> writes:
>
>>> BTW if gcc /isn't/ installed, do you still get a bunch of standard C
>>> headers in /usr/include? If so, what do you have to select to not install
>>> them?
>> I can't say what happens without specifics. There are hundreds of Linux
>> distributions.
>> This is exactly why I was curious about what prompted Malcolm's
>> confident statement about what comes with "Linux" -- it runs contrary to
>> my limited experience.
>
> Not to mine.

I thought you said you can't remember either? Frankly, I don't think
you can recall enough of your experience to be able to say this
honestly. But if you can recall, then tell me -- what distributions
install gcc and the other development tools by default? Malcolm can't
help, but maybe you can.

(As has been pointed out, some distributions are built from source by
the user doing the install. These are not the kind we are discussing.)

--
Ben.

On Fri, 9 Feb 2024 01:14:57 +0000, bart wrote:

> I thought the big deal with Linux compared with Windows was
> that it came with compilers, headers and libraries at least for C.
>
> Now that advantage may be just by chance?

Even when you add these for Windows, you do seem to have trouble building
C programs though, don’t you, as evidenced by your past complaints? So
clearly there must be a bit more to it than that.

On 09/02/2024 02:14, bart wrote:
> On 09/02/2024 00:58, Ben Bacarisse wrote:
>> bart <bc@freeuk.com> writes:
>
>>> BTW if gcc /isn't/ installed, do you still get a bunch of standard C
>>> headers in /usr/include? If so, what do you have to select to not
>>> install
>>> them?
>>
>> I can't say what happens without specifics.  There are hundreds of Linux
>> distributions.
>>
>> This is exactly why I was curious about what prompted Malcolm's
>> confident statement about what comes with "Linux" -- it runs contrary to
>> my limited experience.
>
> Not to mine. I thought the big deal with Linux compared with Windows was
> that it came with compilers, headers and libraries at least for C.
>
> Now that advantage may be just by chance?
>
>

The key distinction is that Linux /distributions/ invariably (or almost
invariably - I haven't checked them all) come with compilers, headers
and libraries. But Linux /installations/ often don't.

Distributions typically contain enormous quantities of software, and any
one user will only want a fraction of that. Default installs will have
a common base (bigger or smaller, depending on the flavour of the
distribution), and may have options for conveniently installing bunches
of software.

On 09/02/2024 01:30, Ben Bacarisse wrote:
> bart <bc@freeuk.com> writes:
>
>> On 09/02/2024 00:58, Ben Bacarisse wrote:
>>> bart <bc@freeuk.com> writes:
>>
>>>> BTW if gcc /isn't/ installed, do you still get a bunch of standard C
>>>> headers in /usr/include? If so, what do you have to select to not install
>>>> them?
>>> I can't say what happens without specifics. There are hundreds of Linux
>>> distributions.
>>> This is exactly why I was curious about what prompted Malcolm's
>>> confident statement about what comes with "Linux" -- it runs contrary to
>>> my limited experience.
>>
>> Not to mine.
>
> I thought you said you can't remember either? Frankly, I don't think
> you can recall enough of your experience to be able to say this
> honestly.

"In MY limited experience" - the bits I can remember - whenever I needed
to compile any C code on Linux, then gcc was always there.

> But if you can recall, then tell me -- what distributions
> install gcc and the other development tools by default? Malcolm can't
> help, but maybe you can.

All the various Linuxes I used on RPi1 and RPi4, 32-bit and the odd
64-bit, had gcc. I know because that was the primary reason for using
those boards.

Those OSes were downloaded in one lump, or sometimes came as plug-in SD
cards.

The same for all the various Linuxes I used on my PC via VirtualBox. The
same with the pre-installed OS on a Linux notebook I once tried.

Further back, I can't remember if the Linuxes I used to install on my PC
via CDs, which were done a package at a time, definitely had gcc since I
can't remember if I ever tried to compile C code on them. (I had enough
trouble just doing the basics, like a working screen and keyword.)

But don't ask me exactly which distributions they are; to me Linux is
Linux and they are all a blur.

So, /this/ is my limited experience. Why are you trying to accuse me of
pulling a fast one?

On 05/02/2024 12:02, David Brown wrote:
> 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.

20+ years ago I depended on an Intel JPEG library called IJL15.DLL, a
32-bit binary of 370KB.

Then they decided to withdraw it; you couldn't find binaries anywhere,
although I had copies. Its replacement was buried inside a massive 75MB
developer's package (at a time when modems worked at 14.4Kbaud), and I
think had to be built from source.

I remember that it was totally impractical and highly inconvenient. And
later on I needed a 64-bit version, which is when I started looking at
libraries like LibJPEG.

As it turned out, these libraries were over-the-top anyway. (The 64-bit
JPEG-load libraries I use now are about 20KB, and JPEG-save about 15KB)

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

I literally ran my fingers through my hair and groaned aloud just
reading about makefiles and CMake.

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

Windows works on binaries. There is a format called 'DLL' that will work
on any Windows OS and for any language that has a suitable FFI.

At worst there will be 32-bit and 64-bit versions, but these days you
only need one.

Even if a developer wanted to make it available as C source code only,
then that is easy: just write in it portable C code. Here, nano.c is
such a library (to decode jpeg) with an accompanying test function in
main():

c:\cx>mcc nano.c
Compiling nano.c to nano.exe

c:\cx>wsl
...
root@XXX:/mnt/c/cx# gcc nano.c

And it runs on both:

root@XXX:/mnt/c/cx# ./a.out /mnt/c/jpeg/card2.jpg
root@DESKTOP-11:/mnt/c/cx# ls *.ppm
nanojpeg_out.ppm
...

c:\cx>nano \jpeg\card2.jpg
c:\cx>dir *.ppm
09/02/2024 11:31 6,220,817 nanojpeg_out.ppm

So, what's the problem? This just needs ANY C compiler, and doesn't need
make or anything else:

c:\cx>tcc nano.c
c:\cx>mcc nano.c
Compiling nano.c to nano.exe
c:\cx>gcc nano.c
c:\cx>\dm\bin\dmc nano.c

Why is everyone so intent on making this harder than necessary? Forget
CYGWIN, MSYS2, WSL, mingw64, or make. Either supply one DLL (that will
work on every 64-bit Windows machine in the world), or supply portable C
code.

bart <bc@freeuk.com> writes:

> On 09/02/2024 01:30, Ben Bacarisse wrote:
>> bart <bc@freeuk.com> writes:
>>
>>> On 09/02/2024 00:58, Ben Bacarisse wrote:
>>>> bart <bc@freeuk.com> writes:
>>>
>>>>> BTW if gcc /isn't/ installed, do you still get a bunch of standard C
>>>>> headers in /usr/include? If so, what do you have to select to not install
>>>>> them?
>>>> I can't say what happens without specifics. There are hundreds of Linux
>>>> distributions.
>>>> This is exactly why I was curious about what prompted Malcolm's
>>>> confident statement about what comes with "Linux" -- it runs contrary to
>>>> my limited experience.
>>>
>>> Not to mine.
>> I thought you said you can't remember either? Frankly, I don't think
>> you can recall enough of your experience to be able to say this
>> honestly.
>
> "In MY limited experience" - the bits I can remember - whenever I needed to
> compile any C code on Linux, then gcc was always there.

That's not the point. The question is whether it got there by default.
That's not what most people are saying.

>> But if you can recall, then tell me -- what distributions
>> install gcc and the other development tools by default? Malcolm can't
>> help, but maybe you can.
>
> All the various Linuxes I used on RPi1 and RPi4, 32-bit and the odd 64-bit,
> had gcc. I know because that was the primary reason for using those
> boards.

That's probably not what Malcolm was using, but they may well install
gcc by default.

> Those OSes were downloaded in one lump, or sometimes came as plug-in SD
> cards.
>
> The same for all the various Linuxes I used on my PC via VirtualBox.

Which ones installed gcc by default?

> The same with the pre-installed OS on a Linux notebook I once tried.

How can that be relevant to what is installed by default? Someone else
chose what to install.

> Further back, I can't remember if the Linuxes I used to install on my PC
> via CDs, which were done a package at a time, definitely had gcc since I
> can't remember if I ever tried to compile C code on them. (I had enough
> trouble just doing the basics, like a working screen and keyword.)
>
> But don't ask me exactly which distributions they are; to me Linux is Linux
> and they are all a blur.

Yes, that's why I wondered how you could be so sure that I was being
unfair to Malcolm.

> So, /this/ is my limited experience. Why are you trying to accuse me of
> pulling a fast one?

No. I was taking you at your word -- that you did not remember: "If
those asked whether I wanted gcc added, then I really can't remember."

--
Ben.

On 09/02/2024 02:07, Lawrence D'Oliveiro wrote:
> On Fri, 9 Feb 2024 01:14:57 +0000, bart wrote:
>
>> I thought the big deal with Linux compared with Windows was
>> that it came with compilers, headers and libraries at least for C.
>>
>> Now that advantage may be just by chance?
>
> Even when you add these for Windows, you do seem to have trouble building
> C programs though, don’t you, as evidenced by your past complaints? So
> clearly there must be a bit more to it than that.

Linux (by which I mean all such Unix-related OSes) is a C machine.

Not only is it all implemented in C, but it won't let you forget that,
with little demarcation between the OS, C libraries, C headers, C
compilers, and a myriad assorted routines that are all amazingly chummy.

Some people here seem to think that POSIX is an essential part of C, yet
windows.c is not considered part of C on Windows.

So, having a C compiler on Windows is not enough, if an application has
an over-reliance on that ecosystem as part of its build process.

On 2024-02-09, bart <bc@freeuk.com> wrote:
> On 09/02/2024 02:07, Lawrence D'Oliveiro wrote:
>> On Fri, 9 Feb 2024 01:14:57 +0000, bart wrote:
>>
>>> I thought the big deal with Linux compared with Windows was
>>> that it came with compilers, headers and libraries at least for C.
>>>
>>> Now that advantage may be just by chance?
>>
>> Even when you add these for Windows, you do seem to have trouble building
>> C programs though, don’t you, as evidenced by your past complaints? So
>> clearly there must be a bit more to it than that.
>
> Linux (by which I mean all such Unix-related OSes) is a C machine.
>
> Not only is it all implemented in C, but it won't let you forget that,
> with little demarcation between the OS, C libraries, C headers, C
> compilers, and a myriad assorted routines that are all amazingly chummy.

Windows is built on C. API's expressed in C with function prototypes
and data structures.

I have worked in several Windows shops as a C++ developer. The culture
was just as steeped in C and C++ as development on Unix. The feeling
was almost as if Microsoft had invented C and Unix didn't exist.

Modern Windows now even has the equivalent of a C library: the UCRT
(universal C run time), a public library, okay to use by applications,
which has your malloc, printf and all that.

> Some people here seem to think that POSIX is an essential part of C, yet
> windows.c is not considered part of C on Windows.

Anyone who claims that POSIX is part of C in comp.lang.c will be
corrected, and if they persist, ultimately ridiculed and ostracized. :)

POSIX has a relationship to ISO C in that it includes the standard by
reference. Everything in C is in POSIX. POSIX redundantly documents
numerous C library functions. Or not always redundantly; here and there
it has additional requirements. POSIX also extends the standard C
headers with its own functions. Some features of POSIX are accessible
via <stdio.h> or <stdlib.h>.

C is an essential part of POSIX, but the reverse isn't true.

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

On 09/02/2024 17:13, Kaz Kylheku wrote:
> On 2024-02-09, bart <bc@freeuk.com> wrote:
>> On 09/02/2024 02:07, Lawrence D'Oliveiro wrote:
>>> On Fri, 9 Feb 2024 01:14:57 +0000, bart wrote:
>>>
>>>> I thought the big deal with Linux compared with Windows was
>>>> that it came with compilers, headers and libraries at least for C.
>>>>
>>>> Now that advantage may be just by chance?
>>>
>>> Even when you add these for Windows, you do seem to have trouble building
>>> C programs though, don’t you, as evidenced by your past complaints? So
>>> clearly there must be a bit more to it than that.
>>
>> Linux (by which I mean all such Unix-related OSes) is a C machine.
>>
>> Not only is it all implemented in C, but it won't let you forget that,
>> with little demarcation between the OS, C libraries, C headers, C
>> compilers, and a myriad assorted routines that are all amazingly chummy.
>
> Windows is built on C. API's expressed in C with function prototypes
> and data structures.

But the demarcation is better. The C-ness doesn't leak through, except
via the OS APIs.

There are no C standard headers provided (nor in a centralised location;
if a C compiler is installed, they are local to the compiler).

It doesn't enforce C's case-sensitivity in the file system and shell
programs.

At a program's entry point, you won't find 'argn', 'argv' conveniently
pushed onto the stack.

Even if you look at the API, it uses a set of precisely defined Windows
data types which wrap the raw C types. (BTW that API is now marked as
being C++.)

And of course you don't routinely have C compilers, assemblers and
linkers provided.

With Linux, everything screams 'C'.

> I have worked in several Windows shops as a C++ developer. The culture
> was just as steeped in C and C++ as development on Unix.

It would be if they used C++.

> The feeling
> was almost as if Microsoft had invented C and Unix didn't exist.

There's Windows. There's Linux. And then there are MS development tools.

People tend to mix up those tools with Windows. Note that MS also have
languages such as VB, F# and C#, all working on top of CLI/CIL
(whichever it is, perhaps both), and something called .NET. I'm not sure
they even acknowledge the existence of C anymore.

> Modern Windows now even has the equivalent of a C library: the UCRT
> (universal C run time), a public library, okay to use by applications,
> which has your malloc, printf and all that.

It's called now MSVCRT.DLL. I've used that since the 90s, simply because
it was simpler than WinAPI. I was only vaguely aware then that it was
also to do with C.

bart <bc@freeuk.com> writes:
>On 09/02/2024 02:07, Lawrence D'Oliveiro wrote:
>> On Fri, 9 Feb 2024 01:14:57 +0000, bart wrote:
>>
>>> I thought the big deal with Linux compared with Windows was
>>> that it came with compilers, headers and libraries at least for C.
>>>
>>> Now that advantage may be just by chance?
>>
>> Even when you add these for Windows, you do seem to have trouble building
>> C programs though, don’t you, as evidenced by your past complaints? So
>> clearly there must be a bit more to it than that.
>
>
>Linux (by which I mean all such Unix-related OSes) is a C machine.

The linux operating system is written in a mix of assembler, C (and now Rust)
and supports a large and varied set of processor architectures.

The linux desktop and server applications are written in a mix of languages,
including C, C++, Python, Java, APL, ADA, COBOL, Fortran, Haskell, Pascal,
C#, D, and a host of other languages for which linux development
environments exist.

> Some people here seem to think that POSIX is an essential part of C,

I don't recall anyone other than you thinking that.

POSIX is an essential component in the applications I write,
just like libgmp or libreadline. C or C++.

bart <bc@freeuk.com> writes:
> On 09/02/2024 17:13, Kaz Kylheku wrote:
[...]
>> Modern Windows now even has the equivalent of a C library: the UCRT
>> (universal C run time), a public library, okay to use by applications,
>> which has your malloc, printf and all that.
>
> It's called now MSVCRT.DLL. I've used that since the 90s, simply
> because it was simpler than WinAPI. I was only vaguely aware then that
> it was also to do with C.

No, MCVCRT.DLL and the UCRT are not the same. UCRT is newer.

https://stackoverflow.com/q/67848972/827263

--
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 2024-02-09, bart <bc@freeuk.com> wrote:
> On 09/02/2024 17:13, Kaz Kylheku wrote:
>> The feeling
>> was almost as if Microsoft had invented C and Unix didn't exist.
>
> There's Windows. There's Linux. And then there are MS development tools.
>
> People tend to mix up those tools with Windows.

Yes, just like people tend to post to newsgroups saying that
everything screams "C" in Linux.

> Note that MS also have
> languages such as VB, F# and C#, all working on top of CLI/CIL
> (whichever it is, perhaps both), and something called .NET. I'm not sure
> they even acknowledge the existence of C anymore.

>> Modern Windows now even has the equivalent of a C library: the UCRT
>> (universal C run time), a public library, okay to use by applications,
>> which has your malloc, printf and all that.
>
> It's called now MSVCRT.DLL.

Umm, no.

> I've used that since the 90s, simply because
> it was simpler than WinAPI. I was only vaguely aware then that it was
> also to do with C.

You didn't use /that/ since the 90s. UCRT is a new thing that ships with
Windows 10, and is available as an add on for as back as Windows 7, an
that's it.

MSVCRT.DLL is not documented for public use; when you link to it,
you're sticking a fork into the proverbial toaster. UCRT is different.

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

On 09/02/2024 18:42, Kaz Kylheku wrote:
> On 2024-02-09, bart <bc@freeuk.com> wrote:
>> On 09/02/2024 17:13, Kaz Kylheku wrote:
>>> The feeling
>>> was almost as if Microsoft had invented C and Unix didn't exist.
>>
>> There's Windows. There's Linux. And then there are MS development tools.
>>
>> People tend to mix up those tools with Windows.
>
> Yes, just like people tend to post to newsgroups saying that
> everything screams "C" in Linux.
>
>> Note that MS also have
>> languages such as VB, F# and C#, all working on top of CLI/CIL
>> (whichever it is, perhaps both), and something called .NET. I'm not sure
>> they even acknowledge the existence of C anymore.
>
>>> Modern Windows now even has the equivalent of a C library: the UCRT
>>> (universal C run time), a public library, okay to use by applications,
>>> which has your malloc, printf and all that.
>>
>> It's called now MSVCRT.DLL.
>
> Umm, no.
>
>> I've used that since the 90s, simply because
>> it was simpler than WinAPI. I was only vaguely aware then that it was
>> also to do with C.
>
> You didn't use /that/ since the 90s. UCRT is a new thing that ships with
> Windows 10, and is available as an add on for as back as Windows 7, an
> that's it.
>
> MSVCRT.DLL is not documented for public use; when you link to it,
> you're sticking a fork into the proverbial toaster. UCRT is different.
>

What exactly to you mean by UCRT; ucrtbase.dll?

That's missing a few useful things, like '_getmainargs' (used to get
argn, argv for main()), and obscure functions like 'printf'.

Meanwhile, if I look at programs such as gcc.exe, as.exe, ld.exe, not
only do THEY import msvcrt.dll, but the EXEs produced by gcc.exe do so too.

So they didn't get the memo.

On 09/02/2024 18:25, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:
>> On 09/02/2024 02:07, Lawrence D'Oliveiro wrote:
>>> On Fri, 9 Feb 2024 01:14:57 +0000, bart wrote:
>>>
>>>> I thought the big deal with Linux compared with Windows was
>>>> that it came with compilers, headers and libraries at least for C.
>>>>
>>>> Now that advantage may be just by chance?
>>>
>>> Even when you add these for Windows, you do seem to have trouble building
>>> C programs though, don’t you, as evidenced by your past complaints? So
>>> clearly there must be a bit more to it than that.
>>
>>
>> Linux (by which I mean all such Unix-related OSes) is a C machine.
>
> The linux operating system is written in a mix of assembler, C (and now Rust)
> and supports a large and varied set of processor architectures.
>
> The linux desktop and server applications are written in a mix of languages,
> including C, C++, Python, Java, APL, ADA, COBOL, Fortran, Haskell, Pascal,
> C#, D, and a host of other languages for which linux development
> environments exist.
>
>> Some people here seem to think that POSIX is an essential part of C,
>
> I don't recall anyone other than you thinking that.

It's mentioned a LOT. Half the open source programs I try seem to use
calls like 'open' instead of 'fopen', suggesting that the author seemed
to think such a function is standard C, or that can be used as though it
was standard.

While here (https://en.wikipedia.org/wiki/C_POSIX_library):

"The C POSIX library is a specification of a C standard library for
POSIX systems. It was developed at the same time as the ANSI C standard."

The table that follows is a list of headers with lots of standard C
headers included.

That looks quite chummy to me, and even nepotic.

On Fri, 9 Feb 2024 11:44:13 +0000, bart wrote:

> Then [Intel] decided to withdraw it; you couldn't find binaries
> anywhere, although I had copies. Its replacement was buried inside a
> massive 75MB developer's package (at a time when modems worked at
> 14.4Kbaud), and I think had to be built from source.
>
> I remember that it was totally impractical and highly inconvenient.

Why not extract it into its own source project and just build that?

>> And thus there is much less effort put into making projects easy to
>> build on Windows.

Ironic that your example is from Intel, from all people. If they cannot
support Windows properly, who can?

> Windows works on binaries. There is a format called 'DLL' that will work
> on any Windows OS and for any language that has a suitable FFI.

But DLLs have no versioning mechanism, do they? Hence, “DLL Hell”.

On Fri, 9 Feb 2024 15:49:45 +0000, bart wrote:

> Some people here seem to think that POSIX is an essential part of C, yet
> windows.c is not considered part of C on Windows.

Precisely. C was born on Unix. “Unix®” as such may be dead, but its
successor, POSIX, can be seen as basically the greatest run-time library
for C.

If Windows NT had not been created by a Unix hater, you would be having
much less trouble with it.

On Fri, 9 Feb 2024 20:55:19 +0000, bart wrote:

> That looks quite chummy to me, and even nepotic.

It’s your choice to be on the outside, looking in.

Come ... join us ...

bart <bc@freeuk.com> writes:
> On 09/02/2024 18:25, Scott Lurndal wrote:
>> bart <bc@freeuk.com> writes:
[...]
>>> Some people here seem to think that POSIX is an essential part of C,
>> I don't recall anyone other than you thinking that.
>
> It's mentioned a LOT. Half the open source programs I try seem to use
> calls like 'open' instead of 'fopen', suggesting that the author
> seemed to think such a function is standard C, or that can be used as
> though it was standard.

Rather, I'd say it suggests that the author doesn't care about
portability to non-POSIX systems, which is perfectly sensible if the
program depends on POSIX-specific features anyway. Similarly, plenty of
C and C++ code depends on Windows features.

--
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 2024-02-09, bart <bc@freeuk.com> wrote:
>> MSVCRT.DLL is not documented for public use; when you link to it,
>> you're sticking a fork into the proverbial toaster. UCRT is different.
>>
>
> What exactly to you mean by UCRT; ucrtbase.dll?
>
> That's missing a few useful things, like '_getmainargs' (used to get
> argn, argv for main()), and obscure functions like 'printf'.

I believe printf is in there.

_getmainargs isn't; that's in a VC run time library.

> Meanwhile, if I look at programs such as gcc.exe, as.exe, ld.exe, not
> only do THEY import msvcrt.dll, but the EXEs produced by gcc.exe do so too.

Umm, no; you must be talking specifically about the MinGW ones.

> So they didn't get the memo.

They got the memo. The issue is that even though MSVCRT.DLL is
undocumented, it constitutes a "system library". This is important.

The GNU Public license prohibits programs from being linked to
proprietary code --- but it has an exception for system libraries
(libraries that are part of the target platform where the program runs).

Using MSVCRT.DLL is like sticking a fork in the toaster, but all those
programs being linked to MSVCRT.DLL means the GPL isn't violated.

Compilers under Cygwin don't link to MSVCRT.DLL --- including the ones
in the Cygwin MingW package. (Yes, Cygwin has a package of MinGW
compilers. If you have Cygwin, you just install that, and then you can
build MinGW programs. The built programs probably still link to
MSVCRT.DLL as far as I know. Cygwin itself uses this MinGW compiler
package for compiling some of its components, like the setup.exe program
and I think the cygwin1.dll also.)

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

On 2024-02-09, bart <bc@freeuk.com> wrote:
> It's mentioned a LOT. Half the open source programs I try seem to use
> calls like 'open' instead of 'fopen', suggesting that the author seemed
> to think such a function is standard C, or that can be used as though it
> was standard.

Open source programs tend to use POSIX functions because POSIX is
associated with open source.

The most successful open source operating systems we have are all
POSIX-based. Open source programs target open source platforms.
It's a no-brainer.

If you need functionality beyond what is in ISO C, POSIX is more
portable than the alternatives.

For instance, suppose we would like to write a cross-platform programs
that works with serial ports. It has to control baud rate, framing, and
whether hardware handshaking is enable and all that.

If we write that using the POSIX API in <termios.h>, it can easily
be made to run on Linux, Windows, Mac, BSD, ...

If we use the Win32 API for serial control, it will run on Windows.
Maybe on Linux using Wine, and ReactOS, ...

In the TXR project, I use <termios.h> to put the TTY in raw mode for the
editing features in the REPL, together with ANSI escape sequences.
This works fine on Windows: there is a termios implementation in Cygwin,
as well as a translation layer that converts ANSI escapes to
Win32 Console API calls. I can ship this stand-alone without Cygwin and
it runs fine in a cmd.exe Window.

I'd be silly not to use POSIX, because then I would have to write
that separately for Windows.

Among other things I can do in POSIX (including on Windows) is use poll
for all file descriptors, including sockets.

I can open a FILE * stream on a socket using fdopen(fd, "...mode...").

POSIX is the most widely implemented operating system interface
standard.

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

On 09/02/2024 21:56, Kaz Kylheku wrote:
> On 2024-02-09, bart <bc@freeuk.com> wrote:
>>> MSVCRT.DLL is not documented for public use; when you link to it,
>>> you're sticking a fork into the proverbial toaster. UCRT is different.
>>>
>>
>> What exactly to you mean by UCRT; ucrtbase.dll?
>>
>> That's missing a few useful things, like '_getmainargs' (used to get
>> argn, argv for main()), and obscure functions like 'printf'.
>
> I believe printf is in there.

Not under my ucrtbase.dll if that's the right file. If it was there, it
would go somewhere in here:

2332 00031F90 204688 Fun pow
2333 00033630 210480 Fun powf
2334 00058740 362304 Fun putc
2335 00080BE0 527328 Fun putchar
2336 00059660 366176 Fun puts

I suspect this is used by MS programs which may have their own wrappers
around 'printf'.

> _getmainargs isn't; that's in a VC run time library.
>
>> Meanwhile, if I look at programs such as gcc.exe, as.exe, ld.exe, not
>> only do THEY import msvcrt.dll, but the EXEs produced by gcc.exe do so too.
>
> Umm, no; you must be talking specifically about the MinGW ones.

I'm talking about lots of binaries, for example:

raylib.dll
opengl.dll
sdl2.dll
sqlite3_32.dll
s7.exe
tcc.exe
nim.exe
nasm.exe

>> So they didn't get the memo.
>
> They got the memo. The issue is that even though MSVCRT.DLL is
> undocumented, it constitutes a "system library". This is important.

If they got rid of it, half the programs that run under Windows would
stop working.

> The GNU Public license prohibits programs from being linked to
> proprietary code --- but it has an exception for system libraries
> (libraries that are part of the target platform where the program runs).
>
> Using MSVCRT.DLL is like sticking a fork in the toaster, but all those
> programs being linked to MSVCRT.DLL means the GPL isn't violated.
>
> Compilers under Cygwin don't link to MSVCRT.DLL --- including the ones
> in the Cygwin MingW package. (Yes, Cygwin has a package of MinGW
> compilers. If you have Cygwin, you just install that, and then you can
> build MinGW programs. The built programs probably still link to
> MSVCRT.DLL as far as I know. Cygwin itself uses this MinGW compiler
> package for compiling some of its components, like the setup.exe program
> and I think the cygwin1.dll also.)
>

I'm no idea what the point of CYGWIN is. Never have done either. What
does it bring to the table? Presumably to make some programs that
originate on Linux feel more at home, instead of making the effort to
make them more portable.

On 09/02/2024 21:56, Kaz Kylheku wrote:
> On 2024-02-09, bart <bc@freeuk.com> wrote:
>>> MSVCRT.DLL is not documented for public use; when you link to it,
>>> you're sticking a fork into the proverbial toaster. UCRT is different.
>>>
>>
>> What exactly to you mean by UCRT; ucrtbase.dll?
>>
>> That's missing a few useful things, like '_getmainargs' (used to get
>> argn, argv for main()), and obscure functions like 'printf'.
>
> I believe printf is in there.

Not under my ucrtbase.dll if that's the right file. If it was there, it
would go somewhere in here:

2332 00031F90 204688 Fun pow
2333 00033630 210480 Fun powf
2334 00058740 362304 Fun putc
2335 00080BE0 527328 Fun putchar
2336 00059660 366176 Fun puts

I suspect this is used by MS programs which may have their own wrappers
around 'printf'.

> _getmainargs isn't; that's in a VC run time library.
>
>> Meanwhile, if I look at programs such as gcc.exe, as.exe, ld.exe, not
>> only do THEY import msvcrt.dll, but the EXEs produced by gcc.exe do so too.
>
> Umm, no; you must be talking specifically about the MinGW ones.

I'm talking about lots of binaries, for example:

raylib.dll
opengl.dll
sdl2.dll
sqlite3_32.dll
s7.exe
tcc.exe
nim.exe
nasm.exe

>> So they didn't get the memo.
>
> They got the memo. The issue is that even though MSVCRT.DLL is
> undocumented, it constitutes a "system library". This is important.

If they got rid of it, half the programs that run under Windows would
stop working.

> The GNU Public license prohibits programs from being linked to
> proprietary code --- but it has an exception for system libraries
> (libraries that are part of the target platform where the program runs).
>
> Using MSVCRT.DLL is like sticking a fork in the toaster, but all those
> programs being linked to MSVCRT.DLL means the GPL isn't violated.
>
> Compilers under Cygwin don't link to MSVCRT.DLL --- including the ones
> in the Cygwin MingW package. (Yes, Cygwin has a package of MinGW
> compilers. If you have Cygwin, you just install that, and then you can
> build MinGW programs. The built programs probably still link to
> MSVCRT.DLL as far as I know. Cygwin itself uses this MinGW compiler
> package for compiling some of its components, like the setup.exe program
> and I think the cygwin1.dll also.)
>

I'm no idea what the point of CYGWIN is. Never have done either. What
does it bring to the table? Presumably to make some programs that
originate on Linux feel more at home, instead of making the effort to
make them more portable.