to optimize big EXE file.

[User137]

Where is Linux, Mac OS X, Android? Ops ... it doesnt run on them =)

Well, Lazarus applications run on those, so we have more features = more code = more binary size.

Actually, .exe files do not run on Linux unless that's with virtual machine like Wine. Application should always be compiled separately for each system. Multiplatform code is propably in big parts {$IFDEF} sections which only compile code for wanted operating system, others aren't included in the executable.

[Martin_fr]

Where is Linux, Mac OS X, Android? Ops ... it doesnt run on them =)

Well, Lazarus applications run on those, so we have more features = more code = more binary size.

Actually, .exe files do not run on Linux unless that's with virtual machine like Wine. Application should always be compiled separately for each system. Multiplatform code is propably in big parts {$IFDEF} sections which only compile code for wanted operating system, others aren't included in the executable.

Actually not corrert either.

Sure there are big parts of code that are only used for one platform each.

But there is lots of shared code that is for all platforms, and that need to be able to link to any of those per-platform sections.
Writing all that highly optimized (with ifdef or other means) would result in a maintenance hell.

[Troodon]

A 100MB microsoft .NET download is nothing these days. It's fast for me to download 100MB .NET runtime.. takes only a few seconds. And on my hard drive, 2TB or whatever, who cares about a 100mb .NET runtime? And also, computers are so fast, 3GHz, so the slowness of .NET or Java is irrelevant today due to Moore's Law!
End Sarcasm.

You are misinformed, my friend. I have to admit, I used to think like you. The Microsoft .Net 4.0 Frameword 4 Client is a 40 MB download. To my big surprise, C#.Net code actually runs faster than some native code that uses the same algorithm (ok, not the same data types, but still). In my experience a GUI Java application is still slower than native code but a C#.Net application is only slower to start (1-2 s instead of ~0.5 s). Besides, who runs Windows 7, which comes with .Net 3.5, and really thinks that getting the .Net 4.0 update is an issue? What .Net does not have and FreePascal does is the magic "write once, compile anywhere", with the compiler for "anywhere" provided free of charge. Trade-offs are in order, of course, but wow! this is a sort of Holy Grail of application development.

[marcov]

You are misinformed, my friend. I have to admit, I used to think like you. The Microsoft .Net 4.0 Frameword 4 Client is a 40 MB download. To my big surprise, C#.Net code actually runs faster than some native code that uses the same algorithm (ok, not the same data types, but still).

And when crafted to avoid unnecessary GC activity by using native types etc. At least from what I saw from it that most benchmarked C# has a different style than one the average C# business programmer produces. The same as with Java btw.
 
Of course that also applies to FPC a bit (if you look at e.g. the FPC entries in the shootout), but I have the feeling that for C#/Java that is a near complete style change, while in Pascal and Delphi that effect is way less pronounced.

[TurboRascal]

Writing all that highly optimized (with ifdef or other means) would result in a maintenance hell.

However, it often pays off to optimize code sections for the most used platform with that program Then you have two bonuses to offer - a fast and quite competitive application on the dominant platform, and one which also runs on several other platforms.

[delphiturk]

exe files, just how big I am for the Windows platform to optimize the response have developed a middleware. This is not good until the expansion of the matter. my friends who want to install software, use Windows systems. UPX.EXE with this software, install it on your host software.

my software is BINOptimizer :
http://www.delphiwise.com/binoptimizer/binoptimizer-setup.exe

[delphiturk]

fix to bug in binoptimizer. If you need it, you can download new version from

http://www.delphiwise.com/binoptimizer/binoptimizer-setup.exe.

thanks for all. 

[TurboRascal]

Every effort to do something to help people is great. However my opinion is, if someone really wants to help optimize the executable file size, one should get involved in the fpc linking process itself. Tweaking that has the greatest potential to do the right thing, other stuff like UPX are mostly (dirty) hacks and workarounds.

[delphiturk]

I am using the "upx.exe". and had no problems. This is a way to zip a binary file. If you know a better method  may you want to share with us perhaps. I'll wait  your response. Thank you in advance for your answer.

[BigChimp]

Yes, my advice would be to not use upx as people have been trying to tell you. Read the size matters wiki article why, also Arny's earlier post.

If you are worried about the download size of your programs, you can use a much better compressor like 7zip or winzip or rar to compress the executable, readmes etc in one archive.

And Arny is right: optimizing for size at the source (the process that generates the executable) by leaving out what is not needed or compressing data structures etc is much more efficient/useful than trying to compress the resulting executable with tools like upx which mess up the computer's cache etc.
So rather than trying to compress the executable, it is much more useful to help improve the FPC compiler/linker to provide smaller executables.

[marcov]

I am using the "upx.exe". and had no problems.

That's something totally different from that being a netto plus.
 

[delphiturk]

I am using the "upx.exe". and had no problems.

That's something totally different from that being a netto plus.
 

I'm trying to tell you anyway. This provides the advantage of the compression process in mobile devices. and alternative. For those who want to use a method.

best regards.

[KpjComp]

EXE/Program size in general I don't see been a massive issue for say Window/Linux/MacOS etc.

But for WINCE it does, I've recently been developing WINCE Apps, and unfortunately I've come to the decided the LCL bloat practically makes it useless for WINCE.  Unfortunately the EXE was about 5 meg, and at this size the WINCE device I was using would start to Stack Overflow, I assume the Stack for WINCE is shared with the same address space as the program.  And it's not like I didn't try optimizing,  eg.  Smart Linking etc, even Full Code optimization etc.  In the end I've had to use KOL, and this brings the EXE down to 1 Meg, that the WINCE device has no issues with.

ps. Yes, I of course excluded Debug info too, with debug info the compiler would even say it's too large.

[delphiturk]

EXE/Program size in general I don't see been a massive issue for say Window/Linux/MacOS etc.

But for WINCE it does, I've recently been developing WINCE Apps, and unfortunately I've come to the decided the LCL bloat practically makes it useless for WINCE.  Unfortunately the EXE was about 5 meg, and at this size the WINCE device I was using would start to Stack Overflow, I assume the Stack for WINCE is shared with the same address space as the program.  And it's not like I didn't try optimizing,  eg.  Smart Linking etc, even Full Code optimization etc.  In the end I've had to use KOL, and this brings the EXE down to 1 Meg, that the WINCE device has no issues with.

ps. Yes, I of course excluded Debug info too, with debug info the compiler would even say it's too large.

Do you try upx.exe to optimize your binary project for wince? or I developed my binoptimizer'i you can use.

my software is BINOptimizer :
http://www.delphiwise.com/binoptimizer/binoptimizer-setup.exe

[marcov]

EXE/Program size in general I don't see been a massive issue for say Window/Linux/MacOS etc.

But for WINCE it does, I've recently been developing WINCE Apps, and unfortunately I've come to the decided the LCL bloat practically makes it useless for WINCE.  Unfortunately the EXE was about 5 meg, and at this size the WINCE device I was using would start to Stack Overflow, I assume the Stack for WINCE is shared with the same address space as the program.  And it's not like I didn't try optimizing,  eg.  Smart Linking etc, even Full Code optimization etc.  In the end I've had to use KOL, and this brings the EXE down to 1 Meg, that the WINCE device has no issues with.

Most CE devices easily have 64MB RAM, and gigabytes of SD flash. This is magnitudes more than the VCL and LCL were originally designed for (think 486's with 8MB, or pentiums with 16MB in ideal cases).

Personally I think your problem has a different origin than size, and as usual, the smart shopping mentality ensures that shallow "feelings" are only reinforced, rather than getting to the core of the problem.

Note that I don't blame you for choosing the easy and quick way out (going KOL). We all have schedules to make. However I do think you didn't  proper reflected on what the problem with wince really (even if it is simply saying "I don't know"), echoing cheap "bloat" sentiment instead.

ps. Yes, I of course excluded Debug info too, with debug info the compiler would even say it's too large.

How much memory did that device have? Less than 5MB? What makes you so sure it is size related? Here you say it is the compiler, in the previous paragraph you mentioned the app stack overflowed. What is it?