[rInstallFriendly] Possible issues and improvements

[raysan5]

List referenced from AuburnSounds/Dplug#792

So a list of issues:

• can only eat a ZIP, containing one format only. No option to have several optional components, it just unpacks a ZIP. Would be solve if it take multiple (one path + one ZIP/file)
• no uninstaller
• VirusTotal flags our installer as malicious (2 / 64) while the original ZIP file is not (0 / 64) ahem.
• no support for macros such as %ProgramFiles% making it harder for internationalization
• no 32-bit support, it's not a problem but in light of Windows arm64 could be a problem
• Window too small. It has DPI support, but no option to up the resolution.
• DPI changes while the installer is running breaks the layout, but this would be rare. Minor.
• unlike raylib installer, this generates installer without a game. But would be great to have a way to minimally customize that.
• not sure how it manages privilege escalation, when downloaded from web this installs in program files without any prompt. Sounds like a loophole
• It's not clear why this would be preferred over custom installer generation (possibly using raylib too)

[avelican]

I think this is the right place to mention some feedback about the official raylib 5.0 installer, which seems to use the same code.

1. On my machine, the window is tiny, text almost unreadable. Perhaps the DPI flag was not set for the raylib installer?
2. Installation takes 01:53 (almost 2 minutes). Extracting the same folder (zipped with max compression) with 7-zip takes 10 seconds (>11x faster). *
3. Nitpick / side-note: Side note: 7-zip can also create self-extracting exe, which gives similar performance (10 seconds), while reducing disk usage by nearly half (68MB vs 122MB). i.e. raylib installer is almost 2x bigger than the same files converted into "self extracting" 7zip exe. (This isn't an ad for 7-zip haha, the choice of using zip is probably a wiser option. Just thought it was interesting.)
4. I wanted to take a look at the code to see what it's doing, but there is no code ;_;

* I also note (with some amusement) that the 7-zip utility can extract the raylib installer exe directly, and that it does this about 10x faster than the installer itself!

[raysan5]

@avelican thank you very much for the feedback! Here my answers:

1. There is a system ready to improve that but not enabled yet. Supporting HighDPI could be a bit tricky because if the system takes care of the scaling, the pixel-art style of the UI is highly distorted/blurry. The solution chosen is to detect if the monitor is HighDPI and scale x2 the window and the framebuffer (only if not going fullscreen). It will be implemented in next release.

2. Current implementation of the installer processes two files per frame, that way it gives additional time to the installer to run an interactive game-banner, also the users have more time to focus on the sponsors button... In any case, multithreading is in the works for next release and this behaviour would be optional.

3. About .zip vs .7z, rInstallFriendly implements a .zip decompressor but not a .7z decompressor, it's in the TODO list but it requires some work... in any case both option should be supported.

4. I'm afraid this project is close-source, like some of my other commercial tools...

I also note (with some amusement) that the 7-zip utility can extract the raylib installer exe directly, and that it does this about 10x faster than the installer itself!

That's because the .zip is directly embedded into the executable with no encryption, 7-zip probably scans the file and detects the .zip header and so it's able to process it.

[acoto87]

Hey, I want to add a couple to this list, mainly from the UX of the app itself:

• On smaller resolutions (1366x768 at 100% scaling) the app doesn't fit on the screen vertically.
• On smaller resolutions (1366x768 at 100% scaling) there are some misalignments on the hit boxes of the buttons.

WindowDontFitOnScreen.mp4

[GithubPrankster]

Wanted to add some issues relating to audio on Windows 10:

• playback seems highly stuttery (tried .mp3, .xm)
• .qoa playback outright crashes if an unusual samplerate is chosen (32000hz)

Also the text for license should use "You should accept the License Agreement before continuing.", in case the license is meant to be something such as GPLv3.

[raysan5]

@GithubPrankster Thanks for reporting!

• Playback issues are probably related because v1.0 is single-thread, so every frame two files are decompressed and the frame logic is executed, including audio buffers filling and application drawing, v2.0 supports multi-threading and decompression is executed in a second thread, so application (and audio) can run a 60 fps stables.
• That seems related to raylib, did you try it with a simple raylib example? Please, could you open an issue on raylib repo if it happens? If it does not happen with raylib master branch is because it has already been addressed and it will be fixed on v2.0.

About the text, you can customize all the text of the installer but you are right that a more generic message could be better, just updated it.

[turanszkij]

Hi, I just purchased this tool and I like the design and idea of it, but I have some problems when trying to use it:

• everything is very tiny, I think the DPI is not handled correctly which was mentioned before in this thread. This is true for the installer creator and the created installer itself too. This will be a problem for anyone using a high resolution laptop screen which must be set to high DPI to make it readable.
• When I try to select desktop shortcut, and press Select File/Path active button, then whatever is under it gets clicked too, so it is not selecting what I actually selected, but whatever is under that button
• I selected an icon, but the generated installer exe doesn't use the icon, but it uses a purple rIF icon
• I couldn't enter my name in the company text box because the letter á appears as ? character

[raysan5]

@turanszkij Hi! Thanks for the feedback! And congratulations for Wicked Engine! It looks amazing! 😄

I'm working on rInstallFriendly 2.0 release, actually it should be already published, but it's taking me a bit longer than expected...

About the mentioned issues:

• Main issue I found with scaling when HighDPI is detected is the blurring of the pixel-perfect fonts. The solution I implemented for next release is detecting monitor resolution and scaling the tool x2 if it fits in the monitor resolution. Probably not the best solution but it improves current behaviour.
• Oh, I didn't notice this issue, below UI elements should be locked! I'm reviewing it for next release.
• I already put lot of time on that but I couldn't solve it, the generated executable needs to be edited to find the resource and change it but I couldn't get it working... definitely it's on the TODO list.
• Mmmh... actually that should work... what UI style were you using? Afair, I added Latin-1-extended charset to all UI styles provided. I will review it again. As a temp solution, you can provide your own UI style for the installer (a .rgs file) created with rGuiStyler, that also allows loading custom fonts and custom charsets.

Hopefully, next rInstallFriendly v2.0 would be ready in a couple of weeks and I'll try to address most of this issues.

[turanszkij]

@turanszkij Hi! Thanks for the feedback! And congratulations for Wicked Engine! It looks amazing! 😄

Thanks!

• Mmmh... actually that should work... what UI style were you using? Afair, I added Latin-1-extended charset to all UI styles provided. I will review it again. As a temp solution, you can provide your own UI style for the installer (a .rgs file) created with rGuiStyler, that also allows loading custom fonts and custom charsets.

I was just using the default style, didn't change anything. Actually the default style looks a lot like the default theme in Wicked Editor which is great.

[raysan5]

@turanszkij Some of the mentioned points are already reviewed. Still rethinking how HighDPI can be better addressed (beside the x2 scaling). About the icon update over a pre-generated executable in memory... keep working on it...

[raysan5]

UPDATE: For the last two days I've been working on the possibility to update the generated installer.exe icon. Unfortunately and unbelivably, it's being way more complex than expected and just hit a road-block.

The process goes as follow, using the Win32 API, open the generated installer.exe, locate the resources to be updated, update the required resources (following some constraints) and resave the executable (when all PE section is properly updated, including sections offsets and so). Here a small code sample:

// Start updating resources on the specified .exe file
HANDLE hUpdate = BeginUpdateResourceA(exePath, FALSE);

// Update icon resources image data
// NOTE: It must be done for all available icon images and following its constraints (ID, data format, language...)
UpdateResource(hUpdate, RT_ICON, MAKEINTRESOURCE(iconGroupHeader.iconID), 1033, iconData, iconDataSize));

// Finalize the update
EndUpdateResource(hUpdate, FALSE));

It seems the process works successfully when analyzed using a Pepper:

But I found some unexpect issues:

1. Windows does not seem to update/read the correct installer.exe properties, neither update the icon thumbnails on explorer. But it seems it's just a explorer thingy, when the file is copied somewhere else (where the cache has no previous reference). The installer.exe resource properties are displayed properly. It's just confusing...

2. The real problem comes at execution:

As we can see, the new icons are read correctly and used on the console window BUT the main window, managed by GLFW, is displaying the icons cut. My guess is that the GLFW window is processing the icons reading the original icons sizes available in the original installer.exe (before being updated with new icons). I verified that previous icon data sizes were smaller than new ones and after some tests it seems the "cut" is proportional to those sizes variation.

At this moment I don't know how to address it... 😞

[DarknessFX]

Hi,

Issue 1 is Windows Explorer normal behaviour, it caches icon image at that folder location for some time. Renaming the file, reading the properties page, creating shortcuts, or moving to another location, are some ways to ensure seeing the updated resource icon.

Issue 2, hard to say... It is strange to see the code UpdateResource RT_ICON 1033 but the resource screenshot displays the same slot as .png in the hex editor instead of a .ico signature. Also, if you didn't create this .RC (resource configuration) and don't need this current structure, perhaps you could simplify a lot, normally this are just listed as IDI_ICON1 ICON "MyApp.ico" but your resource have 8 of icons without name/label? Looks a lot more complex than necessary.

Perhaps an easier fix is to ignore the GLFW part and just work like any window hwnd, use ExtractIconA(hInstance, file_path, icon_index) to read from your own resources or use LoadImage(hInstance, file_path,IMAGE_ICON, ...) to read a local file, and SetWindowLongA to replace the window icon (edit, note: this will only works after ShowWindow(), if you want to create the window with the right icon you need to set RegisterClassExA .hIcon before CreateWindowExA).

I used Win32API a lot in the past, if you want I can build a small sample code.

[raysan5]

@DarknessFX thank you very much for your answer and all the points/ideas you mention.

I finally found the culprit of the issue, it was when updating the RT_ICON_GROUP resource. Despite all RT_ICON data was correctly updated, I mangled the RT_ICON_GROUP data relative to icon sizes (compressed PNGs), issue combined with 2 bytes padding that was automatically added to the structs I defined...

My next challenge: update RT_VERSION data, already struggling with blocks headers and key-value pairs...