Thank you Andrii.
Since you probably know this program better than me, can you explain what the Rathlev version really is?
It seems like a branched version of this same repository but the author doesn't explain that in any place (unless I lost something from the German part).
Even the documentation is still the old one. The changelog has been updated but the other paragraphs are still the same and, for this reason, they are a bit odd (i.e. "Once you have the bug report ready, post it to the forum...". What forum? The SourceForge one?).
Don't take me wrong, I'm not critical but obviously the way Rathlev choosed to publish this program, and his others too, it's strange and it doesn't grant him the reputation he deserves.
Plus, since this repository seems abandoned it could be nice if its home page (https://innounp.sourceforge.net/) is updated with a backlink to the Rathlev page.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am providing a Windows GUI for the Inno Setup Unpacker on GitHub, The description there contains a link to the SourceForge website of innounp.
Since there have been no updates of the SourceForge project since 2020 and the source codes
not yet are adapted to the current Delphi versions (by default strings are Unicode)
I have modified them so that they can be compiled with Delphi 10ff.
Some bugs have also been fixed. Apart from that, it is a branch of the original sources but currently still experimental. The source code can be downloaded here.
The file innounp.htm contains corresponding references to my changes. I am currently preparing a deployment on GitHub.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you Jürgen, now the situation is clear.
When you create the GitHub repo for your branched innounp, please post the news everywhere because I think yours is a really important project.
Thank you again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, there is one, I met. I use as a console unpacker in Far Manager through the Multiarc plugin. They asked for a hint, I decided to give an example - hwi64_810.exe does not open, and in the console the Innounp version of Inno Setup 6.30 and the error message.
The original Innounp 0.50 has a size of less than 690 KB, and the Jürgen Rathlev console v1.72.0 is not only three more than three more (2155 KB), but for some reason Netwkstagetinfo() calls to obtain a remote host configuration. And why do this if all operations are carried out locally?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Delphi compiles with RTTI, which considerably increases the size of the exe files. To disable this, you can use the compiler directive {$RTTI...} but as of Delhi XE6 this needs to be added to each individual unit of the project. "innounp" has more than 120 units.
Does the exe size really matter?
Furthermore, no remote host connection is required in any case.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The size is desirable because the assembly carrier is often a flash pen with limited capacity, and there are already many plugins that solve different problems.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, I can, but the UPX has overhead costs in the amount of about 6 - 8 MB of RAM for each module packaged by him - I tested this. Okay, I have 64 - 128 GB of RAM at my workstations, but if you take a typical user machine, then there is a different running of the programs, a strong fragmentation of the RAM and each extra megabyte of memory, the required -in -law, affects the stability of the OS in general because this is the consumption of the most valuable computer resource after the processor time - RAM.
Yes, and yet - UPX really does not like other antivirs like Avast/Avira - any program packaged by him without verification is announced malicious - this is the position of their developers "If the program is packed by UPX then this is the virus!" It does not change since the 90s.
Last edit: VictorVG 2024-08-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
it is not good practice to insert the compiler directives in this form. It would be better to do this via an include file.
However, this does not really result in a significant reduction in size: from 1.60 MB to 1.43 MB.
I think this discussion is superfluous.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
And about carriers - of course I can write everything on 1TB card SanDian Ultra microSDXC class A2, only it is slow speed - write 4 - 6 MB/s, read 8 - 10 MB/s. But at the price of the kit "microSDXC card + adapter + USB 2.0 microSD card-reader" equ 1/10 SanDisk microSDXC 1TB card low read/write speeds are justified.
IMHO doing anything to shrink an executable weighting 2MB is senseless regardless of the previous size of the file.
@VictorVG
Are U serious. Is your pen drive so small you have to spare 1.5MB??? Aren't you in 2024?
A 64GB pen drive costs less than a beer, so drink one less and buy a new device.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Why? What will I put there? The swollen under the pretext of - "There is a place on the disks, urgently score fresh garbage!" The code that no one optimizes because "grab the bags - the station has left!"? I once wrote SVC Type 1 - the IGC019XW module - its code is 30 lines in the OS/360 Assembler language - and the restriction of the OS architecture "If the place allocated for the data is ended, then the task ends with emergency" was removed forever, and today the code is written on the principle "Ah, and so it will go! The disks are large, and if they buy a new one!" ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The new InnoSetup version 6.3.1 has been released two days ago.
Unfortunately Innounp 0.50 is not able to open this kind of packages.
Is there any hope for an update?
Thanks
Try this - https://www.rathlev-home.de/index-e.html?tools/prog-e.html#unpack
Thank you Andrii.
Since you probably know this program better than me, can you explain what the Rathlev version really is?
It seems like a branched version of this same repository but the author doesn't explain that in any place (unless I lost something from the German part).
Even the documentation is still the old one. The changelog has been updated but the other paragraphs are still the same and, for this reason, they are a bit odd (i.e. "Once you have the bug report ready, post it to the forum...". What forum? The SourceForge one?).
Don't take me wrong, I'm not critical but obviously the way Rathlev choosed to publish this program, and his others too, it's strange and it doesn't grant him the reputation he deserves.
Plus, since this repository seems abandoned it could be nice if its home page (https://innounp.sourceforge.net/) is updated with a backlink to the Rathlev page.
I am providing a Windows GUI for the Inno Setup Unpacker on GitHub, The description there contains a link to the SourceForge website of innounp.
Since there have been no updates of the SourceForge project since 2020 and the source codes
not yet are adapted to the current Delphi versions (by default strings are Unicode)
I have modified them so that they can be compiled with Delphi 10ff.
Some bugs have also been fixed. Apart from that, it is a branch of the original sources but currently still experimental. The source code can be downloaded here.
The file innounp.htm contains corresponding references to my changes. I am currently preparing a deployment on GitHub.
Thank you Jürgen, now the situation is clear.
When you create the GitHub repo for your branched innounp, please post the news everywhere because I think yours is a really important project.
Thank you again.
The repository for my innounp Unicode version is now online::
Innounp on GitHub
Yes, there is one, I met. I use as a console unpacker in Far Manager through the Multiarc plugin. They asked for a hint, I decided to give an example - hwi64_810.exe does not open, and in the console the Innounp version of Inno Setup 6.30 and the error message.
The original Innounp 0.50 has a size of less than 690 KB, and the Jürgen Rathlev console v1.72.0 is not only three more than three more (2155 KB), but for some reason Netwkstagetinfo() calls to obtain a remote host configuration. And why do this if all operations are carried out locally?
Delphi compiles with RTTI, which considerably increases the size of the exe files. To disable this, you can use the compiler directive {$RTTI...} but as of Delhi XE6 this needs to be added to each individual unit of the project. "innounp" has more than 120 units.
Does the exe size really matter?
Furthermore, no remote host connection is required in any case.
The size is desirable because the assembly carrier is often a flash pen with limited capacity, and there are already many plugins that solve different problems.
You can use UPX to compress the exe file:
https://upx.github.io
Yes, I can, but the UPX has overhead costs in the amount of about 6 - 8 MB of RAM for each module packaged by him - I tested this. Okay, I have 64 - 128 GB of RAM at my workstations, but if you take a typical user machine, then there is a different running of the programs, a strong fragmentation of the RAM and each extra megabyte of memory, the required -in -law, affects the stability of the OS in general because this is the consumption of the most valuable computer resource after the processor time - RAM.
Yes, and yet - UPX really does not like other antivirs like Avast/Avira - any program packaged by him without verification is announced malicious - this is the position of their developers "If the program is packed by UPX then this is the virus!" It does not change since the 90s.
Last edit: VictorVG 2024-08-27
I could shrink the exe file to 1.6 MB but it seems to me like whining on a high level.
Last edit: Jürgen Rathlev 2024-08-27
Hi!
{$IFDEF RELEASE}
{$WEAKLINKRTTI ON}
{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}
{$ENDIF}
I took the current 1.72 sources and added this to each module. Here is the finished result. Please use it.
By the way your e-mail don't work!
Last edit: Lity 2024-08-30
it is not good practice to insert the compiler directives in this form. It would be better to do this via an include file.
However, this does not really result in a significant reduction in size: from 1.60 MB to 1.43 MB.
I think this discussion is superfluous.
Here,
https://www.upload.ee/files/17047099/innounp172_-src.7z.html
Jürgen Rathlev
And about carriers - of course I can write everything on 1TB card SanDian Ultra microSDXC class A2, only it is slow speed - write 4 - 6 MB/s, read 8 - 10 MB/s. But at the price of the kit "microSDXC card + adapter + USB 2.0 microSD card-reader" equ 1/10 SanDisk microSDXC 1TB card low read/write speeds are justified.
Last edit: VictorVG 2024-09-10
- errorLast edit: VictorVG 2024-09-10
IMHO doing anything to shrink an executable weighting 2MB is senseless regardless of the previous size of the file.
@VictorVG
Are U serious. Is your pen drive so small you have to spare 1.5MB??? Aren't you in 2024?
A 64GB pen drive costs less than a beer, so drink one less and buy a new device.
Why? What will I put there? The swollen under the pretext of - "There is a place on the disks, urgently score fresh garbage!" The code that no one optimizes because "grab the bags - the station has left!"? I once wrote SVC Type 1 - the IGC019XW module - its code is 30 lines in the OS/360 Assembler language - and the restriction of the OS architecture "If the place allocated for the data is ended, then the task ends with emergency" was removed forever, and today the code is written on the principle "Ah, and so it will go! The disks are large, and if they buy a new one!" ...