Download
InnoUnp v0.50.3 + Observer 1.12.0 - Source + Binaries
Installation
- From the archive, copy bin\innounp.x86.so (for 32bit FAR) or bin\innounp.x64.so (for 64bit FAR) to %FARHOME%\Plugins\Observer\Modules.
- In %FARHOME%\Plugins\Observer\observer.ini:
- In the Modules section, add the following line: (for 32bit version)
Code: Select all
Inno=modules\innounp.x86.so
(for 64bit version)Code: Select all
Inno=modules\innounp.x64.so
- In the Filters section, add the following line:
Code: Select all
Inno=*.exe
- In the Modules section, add the following line:
- Restart FAR.
- Press CTRL+PgDown on an InnoSetup file to open it.
The module is compatible with all versions of Observer. At least, it should be - I only tested it for FAR3, but there isn't really anything that could cause trouble with previous versions of FAR. 64bit versions are supported since version 0.47.2, but should not be considered reliable without extensive testing as the changes needed for them were rather horrific. Note that Observer 1.12 changed the structure of its plugins so a different version of the plugin is needed.
License
Same as InnoUnp, which is, I believe, GPL (oh well). If Ariman wants to incorporate my changes into InnoUnp, I would welcome it.
Changes made to InnoUnp
- Compatibility with Unicode Delphi (tested with Delphi XE2). Non-unicode Delphi still works, too (tested with Delphi 7).
- Since version 0.48.0, all builds produce the same output, using UTF8. The original InnoUnp creates a different input depending on whether the installer itself was unicode or not.
- Support for x64 builds (with Delphi XE6+).
- No more global variables for non-shared stuff. Some global variables remain, but they are not activelly accessed by the current code.
- Proper dealocation of allocated structures. The original InnoUnp leaked horribly - strings didn't get deallocated, even though they are reference-counted (the nasty use of structures accounted for that).
- I provided a standalone class for InnoSetup file handling. That way you can easily use InnoUnp in your own software (e.g. Observer modules).
- Much simplified build environment.
- All this was made while keeping the original code as much as possible. For this reason the code tends to be difficult to read and unnecessarily complex (see the TInnoSetupFile.Extract function, or the runtime variables which are split among TMainInfo and TInnoSetupFile).
- The code should be treated with caution. I did only a very limited testing with limited InnoSetup files. If your life or well-being depends on properly extracting InnoSetup archives, do perform some major testing before using my module!
- A few memory leaks remain. I know where FastMM4 tells me they originate, but I couldn't find the cause. It should not present a problem unless you plan to extract thousands of setups without restarting FAR, though.
- Once the modification gets properly tested, I would strongly recommend rewriting it from its current records-and-pointers-based structure to standard class structure. I can understand why InnoSetup wants to use records (it keeps the size small, which is quite useful in a setup-building program), but that is irrelevant to InnoUnp - and with my modifications, InnoUnp is quite far away from InnoSetup, anyway, so why stick to its philosophy?
- It would be, IMHO, quite useful if Observer introduced a new API which would allow to e.g. return textual description of errors, so that the user could get a more detailed reason for failure than, basically, "error reading archive".
Old downloads