On 30/07/2021 21:03, Bart wrote:
> On 30/07/2021 18:49, David Brown wrote:
>> On 30/07/2021 17:31, Bart wrote:
>>> On 30/07/2021 16:06, Kaz Kylheku wrote:
>>>> On 2021-07-29, Bart <bc@freeuk.com> wrote:
>>>>> Anyway, how can the C library be obsolete if it comes /with/
>>>>> Windows 10?
>>>>
>>>> Windows 10 does not come with a C library.
>>>>
>>>> Windows 10 comes with an undocumented internal component called
>>>> MSVCRT.DLL (or something similar) which is in the system folder.
>>>>
>>>> This is used by some utilities that come with Windows.
>>>>
>>>> If you create executable programs which link or load this and call into
>>>> it, you're misusing Windows in an undocumented way, like sticking a
>>>> fork
>>>> in a toaster whose user manual describes only bread being stuck into
>>>> the toaster.
>>>
>>> Yet gcc on Windows (or my TDM version of it) does the same. As does Tiny
>>> C. So would any application built with those compilers.
>>>
>>> Including tcc.exe itself.
>>>
>>> And gcc.exe itself.
>>>
>>
>> That matches precisely with what Kaz wrote.  Using MSVCRT.DLL as your
>> "system C library" is a lazy, undocumented way to make your C programs
>> work, and being able to boast (pointlessly) about generating small
>> executables.
>
> Hmm, the hello.exe executable generated by gcc (after you specify
> -ohello.exe!) is about 330KB.
>
> And this still imports msvcrt.dll. So small executables aren't the
> reason gcc does it. (tcc produces a 2KB executable.)
>
> You also don't seem to understand the point of DLLs: they are SHARED
> libraries. They are supposed to save space; it is not just disk space,
> but process space. What's the point of 100 active programs all running
> their own private copies of the C runtime?
>

I /do/ understand the point of DLL's. The possibility of sharing space
is just one aspect - and it is totally underused on Windows, since
pretty much every program installs its own copies of the DLL's it needs
(with the exception of the /real/ system DLL's) due to a lack of any
centralised repository and a total chaos of DLL versioning on Windows.
(On Linux, and other *nix, DLL equivalents work well as shared
libraries.) There are other reasons for having DLL's, such as breaking
big programs into more manageable pieces, or re-using code for different
programs.

Most of the standard C library functions are fairly trivial in size -
many are wrappers around system calls (which are, of course, in system
libraries, not the C library). For many, the overhead of calling
external DLL functions greatly outweighs the size or the time taken by
the function itself - you want functions like strcat, memcpy, etc., to
be inlined in many cases, or at least implemented by a static library
rather than a DLL. Statically linking your C library is going to be of
insignificant size cost for most programs, but will often be of speed
benefit.

> Plus, system DLLs (as I consider msvcrt.dll) are usually not practical
> to statically link, because only DLLS are available (eg. kernel32.dll).
>

Regardless of how you consider things, "msvcrt.dll" is not a system DLL.
And any decent C standard library will be available for static linking.
(/Real/ system libraries, such as kernel32.dll, are a different matter.)

> How big would a program be if it incorporated half the Windows API as
> statically linked code?
>

For someone who claims to have developed their own languages, compilers,
linkers and other tools for decades, you are remarkably ignorant of how
toolchains work. Or you are trolling, as some people have suggested.
Perhaps you have just written in haste, without thinking - everyone
makes mistakes and occasionally writes something stupid.

> The GTK libraries on Windows numbered 28 different DLLs (I don't know
> how many MB in total). So what is special about using another DLL called
> msvcrt.dll?
>
> You just want to pour more scorn on the efforts of amateur compiler
> writers.
>

Given that there are other free C runtime libraries, I don't see any
good reason for using it when you simply want C coding, without a
specific need for compatibility with (older) MS tools. It is quite
possible that MSVCRT.DLL was the best choice in the past - it is not
now. I can't say I have looked into this in too much detail, since it
is not an issue that is at all relevant to me or my work. But I could
point out that at least two people here have shown the use of gcc with C
libraries that are quite happy with C99 printf. One - Keith - said he
had no trouble when using Cygwin. Someone else - I forget who - said
they could just use the "-lucrt" switch to get a working library. It
does not seem to be too difficult.

>> Anyone can take the source code for gcc
>
> No. It is a product that consists of about 100,000 files, of which about
> half are source files. It is HUGE. It would be a miracle just to get it
> to build using the automatic means provided, let alone understand the
> ins and outs of it enough to figure out how it deals with system libraries.
>

I've compiled it a good many times over the years (first with version
2.95 for the m68k target and a Windows NT 4 host, IIRC), for
cross-compiling.

But let me rephrase. Anyone competent and interested in compiling gcc,
can take the source code and compile it and package it in whatever way
they like. It does require a willingness to read the information
available, follow suggestions and instructions from others, and
generally do your best to get a working result. Those whose main aim is
to whine and cry, complain about the size, and generally try to find
excuses to say how terrible it all is, will probably find it hard to get
a working toolchain.

> When gcc compiles hello.c, it eventually invokes a linker with FIFTY
> different options.
>

So what?

I generally involve the /compiler/ with fifty different options - but
that is because I want these options and features while others might
not. I use build tools, and can write these options in a makefile. And
I /really/ don't care how many options are passed behind the scenes for
different parts of the toolchain - it is behind the scenes!

> That is a totally different world from what I do. My product doesn't
> even HAVE a linker! (Because it doesn't need it; an obsolete concept in
> my view.)
>

Yes, but your tools are useless for anyone but you. gcc (and binutils
for the linker, assuming that's the linker you are using) are designed
to be used by vast numbers of people for vast numbers of different
purposes in vast numbers of different circumstances.

Do you also complain about the size of supermarkets, or the number of
restaurants in your town, just because you are happy with a cheese
sandwich for dinner every night?

>
>>> So my attitude is, so what?
>>>
>>
>> If that's your attitude, that's fine - it's up to you.
>
> Because even your beloved gcc does it. And every program that a mingw
> gcc builds on Windows, will depend on it too, even when linked with
> -lucrt. So why on earth should I worry about whether /I/ use it?
>
>
>>
>> Many other C programmers - most, perhaps - have joined this century and
>> are using C99 at least.  If you are happy with a setup, toolchain and OS
>> for which you can't use C99, that's fine.  Don't expect anyone else to
>> have much consideration for your limited arrangements, however.
>
> All this fuss about "%zu" which is incredibly naff anyway. If using my
> bcc compiler, I can just write:
>
>    printf("%?", sizeof(T));
>
> which would work with ANY C library.
>
> If using my private language, it's even simpler:
>
>    print T.bytes
>
> So, I should put myself out for a 'format specifier' of the kind that
> should have been done away with last century. How about /you/ lot
> joining the 21st century!
>

Look, no one gives a ***** about your private little toy language. No
one cares. It is useless for anything real. Even if it was the
greatest invention since sliced bread, no one would use it because it is
the product of one angry little man whose prime motivation is a bizarre
and obsessive hatred of C (and C++) and tools for those languages. This
is comp.lang.c, where we use and discuss C. If any of us here want to
use a different language just to make it slightly simpler to print a
number, we all know of many /real/ languages to use. (And many of us
/do/ use other languages which are better than C for particular tasks.)