PureBasic Forums - English

PureBasic version 6.10 is generating files that are five times larger than those produced by version 6.04.
I will not be moving to the new version!
Is this is happening with me only?

Read the release notes. It is a necessary improvement compiling with latest C libs. You can reduce the larger files somewhat using VS2022 link.exe.

Maya wrote: Sat Apr 13, 2024 7:12 pmIs this is happening with me only?

No, others have reported it. It's the price of progress. Personally I like the 6.10 improvements (Date lib for years up to 9999 for one); and I use UPX to shrink my exe from 10 MB to 4 MB (which also has the benefit of reducing VirusTotal false positives).

BarryG wrote: Sun Apr 14, 2024 4:45 amI use UPX to shrink my exe from 10 MB to 4 MB (which also has the benefit of reducing VirusTotal false positives).

Many thanks for this!

PS: Please don't tell to the ppl on Mac section I own a PC

Yup, this is a side effect of switching to VS 2022. See this blog post: https://www.purebasic.fr/blog/?p=538
Seconding what BaryG said about UPX, I use it to compress all my apps and it helps keep my over 5K LOC program under 4 MB, with around 3 MB of data embedded in it's executable

Not use UPX for years, but did a test.

VirusTotal results:

PB 6.0 (x86)
without UPX: 4/70
with UPX: 8/70


PB 6.1 (x86)
without UPX: 6/70
with UPX: 11/70

I was loving the Tiny size of PB Assembly.

It's still incredibly small IMO, 150 KB for an executable these days isn't bad at all. A hello world Go binary is 2 MB out-of-the-box.

Expanding the output assembly by five times is truly disappointing!

PoorMan wrote: Sun Apr 14, 2024 10:38 pm Expanding the output assembly by five times is truly disappointing!

Why? I fully admit that one of the things that drew me to PB is it's small executables, but that really hasn't changed. Like I said above, go compare it to virtually any other tool, you'll find the only ones that are about equal with 6.10 are C/C++ with minimal libraries linked.
Don't get me wrong, I'd absolutely love it if we could still get 10 KB base executables. But I also understand that progress sometimes means sacrificing some things, and I'd much rather slightly sacrifice executable size over speed or security (something that the new C runtime will help with).

I know Fred was reluctant to do this but he did it out of necessity, he would still like to see 19kb exe for a hello world console exe but it's just not realistic when half the libs we depend on have capitulated and moved on to linking to the UCRT.

I will try add an option to link the UCRT dynamically so if you program is targeting Windows 10 or above it would be smaller. It won't remove the MSVCRT dependency but it would be a start.

Quin wrote: Sun Apr 14, 2024 10:45 pm
Why? I fully admit that one of the things that drew me to PB is it's small executables, but that really hasn't changed. Like I said above, go compare it to virtually any other tool, you'll find the only ones that are about equal with 6.10 are C/C++ with minimal libraries linked.
Don't get me wrong, I'd absolutely love it if we could still get 10 KB base executables. But I also understand that progress sometimes means sacrificing some things, and I'd much rather slightly sacrifice executable size over speed or security (something that the new C runtime will help with).

I make these my words too.

Fred wrote: Mon Apr 15, 2024 10:02 am I will try add an option to link the UCRT dynamically so if you program is targeting Windows 10 or above it would be smaller. It won't remove the MSVCRT dependency but it would be a start.

I love you!

Fred wrote: Mon Apr 15, 2024 10:02 am I will try add an option to link the UCRT dynamically so if you program is targeting Windows 10 or above it would be smaller. It won't remove the MSVCRT dependency but it would be a start.

Terrific! Thank you very much!

When I started programming in Basic, the desktop HP 9845 (in 1978) had about 8k of memory and a cassette drive and a thermal printer, no screen. My first TRS-80 model 1, a year later, had < 4k memory which I quickly upgraded to 16 then 48k. Even with a Commodore 64, one learned to be code-miserly, and that was in assembler. Old habits.

In my humble opinion and experience over 45 years, a program should theoretically only have the compiled code it needs. Avoid bloatware. I have found smaller programs generally run faster, and bigger programs seem more of a target to malicious anti-virus and security systems. Internet speeds are not yet fantastic no matter what the hype says, so a smaller program to download helps the user. I am guilty myself of putting together my own Include libraries that contain 80 or 90%+ unused code. I am currently breaking these big include library files down into many small pbi files, only included when needed. The result has been a reduction in scores when checked by Hybrid-Analysis and VirusTotal. The downside is keeping track of all the files. This is where an automatic include system in PB would be helpful.

But, thank you Fred for considering.