On 31/07/2021 02:51, Bart wrote:
> On 30/07/2021 22:16, David Brown wrote:
>> On 30/07/2021 21:03, Bart wrote:
>

>>> 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.
>
> Why, what's wrong with my question? It is perfectly reasonable.
>
> I might consider bundling RAYLIB with an application for example, by
> statically linking (it's some 3MB I think). But not libraries which are
> guaranteed to come with the OS.
>
> (Some exceptions such as OpenGL where the OS one may lag behind.)
>
>> 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.
>
> OK, now I'm curious; what's the thing that is stupid? Having an opinion
> different from yours?
>

When you use statically linked libraries, you only link in the functions
you actually /use/. So it doesn't matter if the static library supports
a hundred thousand WinAPI functions and weighs in at 100 MB - if you use
a hundred functions, the library will give you an extra 100 KB in your
binary. Using a static library for the WinAPI or the C standard library
is only going to give you a big binary if you use a very large number of
functions from the library - in which case your binary is already very big.

>
>>> 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,
>
> I don't like dependencies. I like that there is just my program, and the
> OS. Some third party libraries may necessarily have to be sourced, but
> MSVCRT.DLL works perfectly well for the vast majority of my needs.

I understand not wanting dependencies, and preferring a stand-alone
program. That is another good reason to ditch MSVCRT.DLL, which is a
completely unnecessary dependency, and statically link a C library.

>
> (From my private language, I only use about 20 C functions anyway, out
> of about 1400 in MSVCRT.DLL.
>
> It wouldn't be that hard to eliminate it (I did without it for years).)
>
>  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.
>
> I use Windows. (Imagine someone said they had no problem running my
> Windows program under Wine; but Wine isn't Linux)

I see "runs fine with Wine" as a reasonable solution to porting Windows
programs to run on Linux - just as Cygwin is a reasonable solution to
porting POSIX programs to Windows. It's not native, but it works well
for many purposes.

>
>> Someone else - I forget who - said
>> they could just use the "-lucrt" switch to get a working library.
>
> That was me. But it's not a solution (assuming there was a problem in
> the first place) as I need to have C code run under bcc and tcc.

It is a solution for when you want to use a C compiler, rather than a
compiler for a limited subset of C. If you want C, you need a real
compiler and a real library. If you are happy with just part of C (and
often that is sufficient), you can use a limited tool like bcc or tcc,
and a limited library like MSVCRT.DLL, if you like. Just don't complain
when you use such tools and they don't handle some valid C code.

> Especially tcc, since I have an upcoming project that may need a C
> backend (and for some challenging C code), and using any other compiler
> would be like hitting a brick wall.
>
>> 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.
>
> Not interested. Life is too short. My entire compiler builds in 0.2
> seconds, but might generate code 50% slower than gcc. That will do me.
>
>
>>> 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.
>
> Sure. But they are also proof of concept. Want a blazing fast C
> compiler? I've done it! (Tcc got there first and better, but I'm not far
> behind.)

Why should anyone care about how fast something runs if it does not do
the job? If these niche tools are good enough for your particular
needs, fine - use them and enjoy them. There is a place in this world
for Formula 1 cars that are lighter, smaller, and much faster than
normal cars - but only a fool would think they are /better/ than the car
you drive every day.

>
> Do away with object files? I've done it! Do away with a linker? I've
> done it! Do away with makefiles? I've done it! Write a whole-program
> compiler? I've done it! (But not with C - yet.) A 4-million-line-per
> second assembler? I've done it!

I have always been impressed by the fact that you have written a
compiler at all. Your obsession with speed and size, however, is less
impressive.

>
> So it can all show what is possible. Of little interest in this group
> obviously and especially to you because you don't understand that some
> of us are interested in developing efficient, minimalist, human-scale
> tools, and which might be an inspiration to others.
>

I can appreciate people making hobby tools.

>
>> 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?
>
> I would like to cook my own recipes without getting involved in
> industrial-scale food production. There's a need for that, obviously,
> but I'm simply not interested.
>
>> Look, no one gives a ***** about your private little toy language.  No
>> one cares. It is useless for anything real.
>
> I would let that go. But actually, I worked in a commercial environment
> for 20 years and used exclusively my private languages.
>
> They /were/ useful, and were used for a product that was generating,
> then, perhaps $1m a year of business. So I'm not going to be shouted
> down by you.
>

I have seen the mistakes made by customers getting software written with
"one-man" tools. It can sound like a good idea at the time, but leaves
the customer with unmaintainable code. /Sometimes/ it can be a
reasonable choice, especially when the system is highly person-specific
in the first place and using a language known by others would not help.
And it used to be more common long ago, in the "cowboy days" of
software development.

>
>   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 entire subthread is a perfect example of what I hate about it: all
> this fuss about a stupid "%zu" format code just to print out a number.
>

Just use a C toolchain and the C language, as it is defined - it's not
hard. It's only people who haven't joined this century that have problems.

> Whose idea was that? And how about /properly/ fixing 'print'?
>

If we were discussing how a programming language could handle tasks in a
different way from the C way, that would come up. No one is in any
doubt that a programming language designed today would be somewhat
different from one designed 50 years ago. But this is about how to
write code in C.

>
>
>> This
>> is comp.lang.c, where we use and discuss C.
>
> I knew it was a mistake coming back to this newsgroup.
>
> You know, because of the massive negative reaction in this group
> (everthing I did was wrong, all my C code was rubbish, I knew nothing
> about the language, etc etc) a year ago I burnt most of my bridges with
> C, got rid of my C backends; actually you guys put me off the language a
> lot more than the language itself.
>
> That was a mistake. A C target is genuinely useful to have. And you
> people don't actually own the language. Neither do you write any of the
> tools, mostly (some exceptions like JN).
>
> And, you can't actually tell people what they can or can't do (go and
> program in WSL; no thanks!).
>
> So I'm resurrecting that C target in a novel, experimental project. I
> won't make the mistake of posting code here for you to shoot down. And I
> will use whatever compilers I like with the libraries I want and on the
> OSes that I choose.
>

People here have tried to /help/ you. You have never appreciated that.