Questions before moving on to FB

[jj2007]

then and only then you can try hand coding it in assembly.

We use what we know. In the past, I've coded mainly in BASIC, that's why I hang around here. Nowadays most of my coding is in assembly. My "Tiny IDE for FreeBasic" comes in at 7,168 bytes. The source of my other editor is currently at 22,000+ lines - in assembly, nothing else. Pure mnemonics plus Windows API, I don't even use the good ol' C runtime DLL. Why? Because I can do it ;-)

[Cretin Ho]

@Marcov: the largest FB app I could think of is the WinFBE suite, an IDE for FreeBASIC. Anyway, it's just my guess.

Your statement about Lazarus app could be down to 2MB seems not right to me. I have to enable Smart Linking and later strip the binary manually using GNU strip with strip --strip-all, even so the binary can't be that small. Lazarus app is much bloated than Qt app in size. And as many FB forks here don't know we can combine both, using Qt5Pas :)

Lazarus was only beaten by Win32++. Using a 64 bit g++ the binary is about 27MB in size! Of course this is caused by debug info and static linking (it's a template library with a permissive license, so it uses static linking by default). If you strip the binary or build with the release target without static linking the binary is just about 1.5MB. If we count the size of libstdc++ and some other small dlls needed for it to run, the app is same same to the size of the Lazarus app after all size treatments applied.

[marcov]

@Marcov: the largest FB app I could think of is the WinFBE suite, an IDE for FreeBASIC. Anyway, it's just my guess.

So, how large is it? How many screens does it have? Does it use dlls or runtimes? Scintilla in DLL form alone is usually over a 1MB.

Your statement about Lazarus app could be down to 2MB seems not right to me. I have to enable Smart Linking and later strip the binary manually using GNU strip with strip --strip-all, even so the binary can't be that small. Lazarus app is much bloated than Qt app in size. And as many FB forks here don't know we can combine both, using Qt5Pas :)

I recompiled with a newer lazarus, and the new (win32) binary was 2.7MB. This is a simple but usable sqlite database app with a few core screens and a few popups. I have several for these, they are like my Access substitute whenever I need to maintain simple lists etc. Everything is static except the 600k sqlite dll. It is a bit larger than an absolute empty form since it of course has database classes, the database grid class etc.

The only configuring I did was to set a release build, so no real optimizing for size. (but that option should do the bulk of the work, indeed smartlinking and no debug generation), which is go to compiler-options->build modes and allowed Lazarus to initiate "release and debug buildmodes", and then selected the "release buildmode and press alt-F9 to build.

Easy, not bloated, no chance on stumbling on broken GNU strips etc, since the debugcode is simply not generated. And that for a development system that doesn't continously overfocusses on size.

The whole test took 30s.

Lazarus was only beaten by Win32++. Using a 64 bit g++ the binary is about 27MB in size! Of course this is caused by debug info and static linking (it's a template library with a permissive license, so it uses static linking by default). If you strip the binary or build with the release target without static linking the binary is just about 1.5MB. If we count the size of libstdc++ and some other small dlls needed for it to run, the app is same same to the size of the Lazarus app after all size treatments applied.

How big was the static stripped binary in the end? And how long did it take you to get that result?

[marcov]

These extremists are hackers. Normal people doesn't do that!

No they are not hackers. Hackers know what they are doing and work efficient. These are more script kiddies and lamers.

Script kiddies will use QT (standalone exe: at least 8MB) or .NOT for their hello world proggies, because they are too dumb to study the internals of the PE format. What you call "lamers" are 99% people who like the challenge of tickling the last cycle out of assembly code, or solve the last Windows secret. Proud hobby programmers, not people who must code to feed their family. It's a bit like playing chess - completely useless and inefficient, but it's fun. My personal hobby is to demonstrate that hand-crafted assembly is often twice as fast as the code spit out by VC or GCC. Btw I fully agree that "Normal people doesn't do that!" ;-)

Script kiddies and lamers will both use anything where they can string things that are already done together and then pretend it is a great gain for mankind.

... and that also means repetitive reuse of minimal assembler templates in some slightly new variations

And this has nothing to do with software development. If you want small binary size, without doing anything useful, use FPC 16-bit and create 16-bit COM files. I really don't mind people playing a bit with asm to get minimal programs, but does this nonsense have to be brought up in every toolchain discussion?

[jj2007]

If you want small binary size, without doing anything useful, use FPC 16-bit and create 16-bit COM files. I really don't mind people playing a bit with asm to get minimal programs, but does this nonsense have to be brought up in every toolchain discussion?

No, I don't want small binary size without doing anything useful. Most of my programming is pretty useful indeed, and I am not "playing a bit with asm". I have 5,000+ sources on this machine, some in the 20,000+ lines range.

You brought up the nonsense debate. You hate assembly as much as I hate the bloatware that slows down my machine (it's commonly called "Windows rot"). Can we agree to disagree, without insulting each other, or do you want to continue the "professional" argument, in a forum that is obviously full of hobby & for fun programmers?

[marcov]

You brought up the nonsense debate.

No I did not. We were talking about toolchains and doing useful things, and as always within 10 seconds that degrades to binary size mudslinging and whining about bloat. That was not the topic.

You hate assembly as much as I hate the bloatware that slows down my machine (it's commonly called "Windows rot").

Size does not slow down. Slow programs slow down. Windows does not need to fully load the exe to run it, and e.g. debug code and resources are default not loaded into memory. This is why EXEs are locked under Windows when they are running. (and under Linux they are not locked, but if you operate on them, the system keeps the old version of the binary around by not releasing the inodes back to the FS).

This is exactly why these discussions are so pointless. It is all baseless emotion and people are only soliciting for agreement that it is all so bloaty and everything was so much better in ye old days.

And I don't hate programing in assembler ( See e.g. http://www.stack.nl/~marcov/rot8x8.txt ), but that is for speed and not for size reasons. Even for embedded use, size rarely matters, if it just doesn't fit anymore, you usually just pick a micro with a larger flash size. (Not that I have to, since the smallest is 128kb, and my largest program is 30kb, containing a complete UDP stack)

I can also show you complete calendar and date routines done in pure assembler (16-bit real and 32-bit pm) from the early-mid nineties when my core program did log file scanning, and back then decoding the date on each line in the logfile was speed limiting. But even that was for speed, not size,

Size only matters for the very few that prepare a product for volume production, where it is sometimes (not always) worthwhile to miniaturize the program and try to get a better price. But this is rare (I have done it only once in my life). If it happens, the exact part is also selected, but until then it is usually smarter to keep it somewhat general to easier migrate parts.

Can we agree to disagree, without insulting each other, or do you want to continue the "professional" argument, in a forum that is obviously full of hobby & for fun programmers?

No, because that is not a real existing division. Most hobby programmers also just want to do things and don't care about size, at least not in such extreme matters that 1 vs 2 MB matters.

So the argument is not really on size, which is what I meant with the whole lamer part of the discussion. People are not really interested in size as the cited reasons for it are debunked in discussion after discussion. Even in this message there are examples of that, where size and speed are incorrectly conflated.

It seems they just want to comfort each other and whine about bloaty systems and how everything was better back in the day. Which is fine, but don't bring this up in each toolchain discussion.

[jj2007]

You brought up the nonsense debate.

No I did not. We were talking about toolchains and doing useful things, and as always within 10 seconds that degrades to binary size mudslinging and whining about bloat. That was not the topic.

Or simply don't needlessly make size the centre of the universe.
...
P.s. I really don't understand the small EXE cult

Apparently you must demonstrate your professional superiority, and you must insult the rest of the World. Get a shrink, please.

[caseih]

No, Marcov is not trying to demonstrate professional superiority, at least not in those posts. You're projecting onto his words. Nor did he start the bloat discussion; the original poster was the one who did that when I suggested Lazarus might be a better fit.

Anyway looks like this discussion is done. I wish the original poster luck in trying out FB. I hope it works out for him.

[Cretin Ho]

Most hobby programmers also just want to do things and don't care about size, at least not in such extreme matters that 1 vs 2 MB matters.

There are many kind of hobby programmers, though. There is no general discipline among us. I consider some as hackers, e.g: the assembly people.

[Cretin Ho]

P.s. I really don't understand the small EXE cult

The cult's exact name is minimalism.

[jj2007]

I consider some as hackers, e.g: the assembly people.

Compiler developers are hackers, then? I am a hacker because my 140kB editor is based on a 22,000+ lines assembly source? Be careful with generalisations, my friend...

[marcov]

P.s. I really don't understand the small EXE cult

The cult's exact name is minimalism.

Sometimes I think it is simply an easy way to deflect functional criticism and rave against the bloat of the evil world.

But it is not that it exists that annoys me, but the need that group has to evangelise their size-centric views in every discussion about toolchains and frameworks.

And I simply refuse to believe that minimalist are the bulk of the users, non-professional or otherwise.

Most hobby programmers also just want to do things and don't care about size, at least not in such extreme matters that 1 vs 2 MB matters.

There are many kind of hobby programmers, though. There is no general discipline among us. I consider some as hackers, e.g: the assembly people.

The whole hobby vs professional came from JJ (who is in my ignore filter for now), not from me. I was only talking about the goal of an application, which IMHO should be about what it does, not how big it is (within some very wide practical margins).

Maybe I'm lucky that my minimalist period was in a time when minimalism actually got you noticeable speed.

[Lost Zergling]

I would like to clear up some confusion from my point of view. First of all, the size of the executable as a file does not have a linear relationship with that of the executable in memory. What counts is the memory consumption during the execution of the program, and this occupation is variable according to the dynamics of the algorithms in progress. And what is relevant is not necessarily the minimization of memory consumption, let me explain: taking the example of lzle, the structure of the memory node can be specified in advance as a constant (TagMode) . It is possible that, for example, TagMode 2 consumes less memory resources overall (sum of one-time consumption * time spent) than others, but with peaks in consumption, in which case the most optimized solution on paper is not more neither the fastest nor the most efficient in real life, ..
Another important point is that the problems of speed and memory consumption are often multi-level. At the low level, it will be fundamental to have a small executable, but it is necessary to temper this approach by considerations of methodology and architecture in terms of software engineering, the higher we go to 'high level'. The more we increase in level and functionality, the less simple the optimizations will be, and the more difficult it will be to keep them minimalist.
We must therefore not oppose the functional richness to the culture of minimalism, because that amounts to denying the technical barrier which is precisely born from the confrontation of the two.

[dodicat]

To reduce pascal .exe sizes you can use strip.
ie
strip myfile.exe.
You need Mingw for this of course in windows.
Freebasic automatically strips the output .exe file.
Experimenting, most of my pascal .exe files can be stripped to about half their original size.

[jj2007]

We must therefore not oppose the functional richness to the culture of minimalism, because that amounts to denying the technical barrier which is precisely born from the confrontation of the two.

There is no culture of minimalism, unfortunately the culture of "don't care about size" has taken over a long time ago. The evidence is called "Windows rot", and it means that your 5 year old machine should go to the waste bin because it can't cope any more with "modern" software.

What I can't stand is the arrogance and insults that come, inevitably, from those who don't care about size. They are no poets or writers, they are just coders, but still, why all this hatred? Here are those of marcov, only in this thread, and only half of them directed at me:

don't needlessly make size the centre of the universe
forums have their weird and aggressive posters
I really don't understand the small EXE cult
Impressive waste of time
like doing dishes with a tootbrush
this bright mentality
Who determines this nonsense?
script kiddies and lamers
repetitive reuse of minimal assembler templates
use FPC 16-bit and create 16-bit COM files
degrades to binary size mudslinging and whining about bloat
these discussions are so pointless
It is all baseless emotion
the whole lamer part of the discussion
whine about bloaty systems
that group has to evangelise their size-centric views