Suggestion -Dzlib or -z parameter for build or test?

#1

Hello guys, can I give suggestions for compressed executable.

For example
Starling demo has 13,42 MB ( static release x64 )

I have tried Easy Upx GUI and result looks 4,36 MB

If you like compressing mode into static lime example
lime build windows -64 -release -static -z or lime build windows -64 -release -static -compress
lime test flash -z ( flash has support compress mode )
lime test air -z ( compress smaller with swf file )
lime test android -z ( Make apk smaller - I am not sure if Android works small apk files )
lime test html -z ( it looks like without “\n” it looks like compressed javascript )
If you don’t use -z than lime test html will make normal and large files.
And more anything with -z for linux and mac work too. They have not problem with small size of executables.

Do you allow to add my idea “-z” It means compress with zlib library ( x64 and x86 )

Like mkbundle makes smaller with bundled executable with C# assemblies into native executable with small size.

I hope you allow to add new parameter for lime/openfl if executable are static and make small size.

If you don’t like than you can ignore my idea.

Thanks!

#2

How does it work? Does it use it’s own EXE wrapper, zip the other executable, and extract it on the fly at runtime?

#3

@singmajesty Good day / night, No it is not wrapper. It is statically and compressed. And it doesn’t need fly - It works like static and native. You don’t need to install runtimes…

If you find Google search: executable has small size.

Stack Overflow - How can an executable be this small in file size?
codeguru - zlib: Add Industrial Strength Compression to Your C/C++ Apps
Github - Miniz Example
bts.blog - How to make smaller C and C++ binaries
Bobobobo’s Weblog - How to use zlib

There are examples from links If you understand how does haxe program with compressing mode than executable will small and we do not need big executable who has poor hard disk like 1 TB or 500 GB than Windows 10 makes installation with Visual Studio 2017 Community bigger. That is why I want we have to make executable smaller and we don’t worry for low space of hard disk.

If you install Windows 10 Pro x64 with full-installation of Visual Studio 2017 Community up to 600 GB. ( Cause downloaded images of Android Systems ). That is very big and we have problem we have not more space of hard disk. We would like save required space - executable should be small. Before 10 MB after with zlib-used = 3 MB or 2 MB than it works fine.

I hope you understand that.

// EDIT:
If you don’t like executable to make small size. If you use UPX than hackers are happy to crack that is why I wish Lime application binaries should compress and protect and don’t get problems.

I hope you have to get chance with Lime application executable and small size and we don’t have low level rate like mobile surfstick if you are travelling and it makes expensive for example EU Roaming limited up to 1 GB or 2 GB. - If you made small executable’s size and pack to setup or installer or steam pipeline than small size will download until complete and do not wait for large sizes.

// Updated 1:
Found like memory of executable
experts-exchange - In-Memory Compression and Decompression Using ZLIB

lime build windows -z ( it is compressed executable ) If you can try if Haxe / Lime works with -z for small size of executables. I hope my help can resolve you.

// Updated 2:
You can read tutorial easy zlib website Because I found it. It looks like simple executable will be compressed. Thanks I am sorry for forgotten points…

#4

We could zip our output executables, but I don’t think the OS would run it. I think the solution is to zip the executable, and join it with a small executable that knows how to decompress, and either it does it into memory and runs it, or writes it to disk somewhere, I’m not sure. It would be interesting to know, I’m not against adding this feature in the Lime tools :slight_smile:

#5

I’m just chiming in with my 2c’s

Although generally I like the idea of compressed executables, you’re blaming OpenFL for not saving like, what, 9MB per application? That’s nothing nowadays on desktops.

Using another 3rd-party library just to gain that little can open up an entirely new line of bug reports, and possibly break the cross-platform aspects as well.

If you’re distributing you app for desktop with an installer, it will be compressed anyway, whether it’s a Windows or a Mac installer. In fact you can easily end up having larger files than before (compressing an already compressed file usually produces larger files).

Flash/AIR SDK already has LZMA compress for SWF files, in fact LZMA is enabled by default for non-debug builds in the latest SDKs. If it’s not sufficient for you, just Google “zlib2lzma”, you’ll have plenty of solutions to re-compress your SWF to LZMA from the command line (there are Java and exe results with source code)

APK and IPA files are technically ZIP files, so there’s nothing to gain there, and even if it’s possible to compress the embedded unix binaries you may end up with longer launch times and increased memory usage.

If you really need to save 10MB try neko. Neko builds are smaller in my experience (9MB vs 28MB for the application I’m currently working on, including exe and dlls)

IMO you’re better off optimizing assets by reducing PNG size, using JPG wherever it’s possible, use zipped assets etc etc., there’s much more to gain there in terms of bytesize.

You think Easy Upx will stop anybody from cracking your software? You need much more sophisticated algorithms than that.

The fact that you already managed to compress executables shows what you only need is proper build scripts. Create scripts that make the build, then compress whatever needs compression, delete intermediary/uncompressed files if needed, and you’re set.

2 Likes
#6

That is really correct - you mean that like me too. But I don’t blame about big size.

PS: I will tell you about mkbundle / monolinker but I would like to tell about haxe / lime too because they don’t want forget after lime rebuild -static if they forget static version.

It seems like mkbundle has bundled net assemblies in temp.s with more lines with byte date lines like “0x0F”, “0xA0” , etc… and clang.exe from Visual Studio 2017 Community converts temp.s into temp.s.obj ( it is object file with embedded assemblies with “name_data_exe” for example )

Example with Lime test -z ( it looks like mkbundle made new file temp.s )

For Lime we should write advanced like mkbundle’s function
Generate executable ( and dll for Windows, so/dso for Linux and dylib for Mac ) into temp.s
lime_compressed_data_executable_yourexecutable = { 0x0F, 0x10, … };
lime_compressed_data_dynamic_library_yourlibrary = { 0x0D, 0x0A, … }

And lime will let convert with clang.exe from Visual Studio 2017 Community
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\ClangC2\14.10.25903\bin\HostX64\clang.exe" -c -x assembler -o temp.s.obj temp.s

And builds finish:
cl.exe ... temp.s.obj ... /out:YourExecutable.exe

For g++/gcc and as for Linux and Mac.

I hope that somebody has not problem…