InnoUnp v0.47 + Observer 1.11.0 - Source + Binaries
- From the archive, copy bin\innounp.so to %FARHOME%\Plugins\Observer\Modules.
- In %FARHOME%\Plugins\Observer\observer.ini:
- Restart FAR.
- Press CTRL+PgDown on an InnoSetup file to open it.
The module is compatible with all 32bit 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 not supported and likely won't ever be supported - InnoUnp uses some nasty difficult-to-find type conversions incompatible with 64bit code and, anyway, I don't have 64bit unpacking modules for it.
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).
- 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 considered alpha at best. I did only a very limited testing with limited InnoSetup files. I particularly did not test any password-protected setups, and the Unicodification could easily lead to problems in this area. 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.
- The progress display of the module is very quirky. When I tested it on a 100+ MB archive with 1000+ files, it displayed correctly for some parts of the extraction process, then suddenly switched to values such as "completed 15000% / 2400%", then switched back to correct display, then once again showed huge percentages. I don't know why, I would think my handling is correct, but apparently it isn't.
- 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".
InnoUnp v0.46 + Observer 1.11.0 - Source + Binaries
InnoUnp v0.45 + Observer 1.11.0 (mod 2) - Source + Binaries
InnoUnp v0.45 + Observer 1.11.0 - Source + Binaries
InnoUnp v0.43 + Observer 1.10.1 - Source + Binaries