Hi all,

(Cross posted to Lazarus+FPC lists)

Thanks to UPayload (http://www.delphidabbler.com/articles?article=7) and some help on the forum, I could implement an alternative way of storing files in an executable file (basically it just appends them with a footer). See source: poormansresource.pas in
https://bitbucket.org/reiniero/checkride/src/, and the CheckRideResourceZipper project for sample code

This method allows me to edit such a "resource" using an FPC/Lazarus program.
As - I think - DoDi predicted, I had a lot of trouble trying to work with regular Windows resources, but whether that is due to bugs in FPC, Windows or me, I don't know ;)

I updated my CheckRide remote control package with this functionality: a helper can edit CheckRide.exe with his hostname and port number and distribute that single exe to his clients/helped persons. This allows 1 click operation at the helped side.

I also tested operation with a Linux helper running stunnel+vncviewer and a WIndows helped party running CheckRide.exe

See the site mentioned above.

Comments, patches, as well as criticism welcome ;)

Thanks,
Reinier

What's the advantage compared to lrs files?

Mattias

Hi Mattias,

I hadn't even thought about lrs honestly. Would I be able to easily edit an lrs resource once it's added to an exe as well?

Thanks,
Reinier

When the lrs is changed you have to recompile.

I never thought of editing exe files. Antivirussoftware does not like that.

Mattias

I often edited Windows EXE and DLL binaries, using the famous Borland Resource Workshop :-)

The "offical" way of course is using RLINK to add the resources to compiled files. It's supplied with and most probably used by the BRW.

Antivirussoftware does not like that.

That's true, but liveable when used to configure *personalized* apps before shipping. I've turned off any AV software on my development system, because it only can cause trouble there.

DoDi

;) Could be.

Reason why I (think I) need some kind of resource editing functionality: I'm editing a config file, contained
in a zip (which also contains winvnc.exe) in CheckRide.exe (the exe for the "client", helped party).
This is done to customize the software before sending it out to the client i.e. when it is used the exe is not changed. Forcing admins to have a full Lazarus install just to change some settings would probably not be conducive to my tool's popularity... ;)

Submitted to http://virusscan.jotti.org/en; only Kaspersky indicated something:
not-a-virus:RemoteAdmin.Win32.WinVNC.mh

Other alternatives that can be used to customize:
1. Distribute an .ini file along with checkride.exe
2. Start checkride.exe with command line arguments
3. Let checkride autoconnect to the (hardcoded example.com) server; when it fails, the user can specify host/port in the GUI and try again

I suspect having winvvnc.exe (either plain or as a resource) might be a bigger problem...

Thanks,
Reinier

Out of curiosity: Why did you implement that? On Windows you can already edit resources using a resource editor if you use FPC's Resource support. On Linux I've not tested yet whether you can edit the embedded resources.

Regards,
Sven

A while ago I also looked into the different resource formats to include binary data (a custom installer). At that time I rejected lrs because binary data where stored as ascii, escaping non ascii chars as #iii. The result was a a huge file. I settled for the windows .res format which is supported by fpc cross platform and stores binary data as binary data. A minor disadvantage is the custom build script using windres to compile the resources on non windows systems. Windres can be difficult to find on some systems (typically found in mingw cross buildutils) or has to be made from source.

Ludo

Hi Sven,

That's what I thought, too ;)
I think DoDi warned me about problems. Decided to try it and yes: I had problems. While rewriting the resources seemed to work, the resulting exe crashed.
Either that or the resource editors I used didn't seem to recognize my resource.
In the end, I just gave up and implemented my ow... eehm, somebody else's idea ;)

The code dealing with proper resources is still in some revision in the bitbucket repository...

Regards,
Reinier

The lrs file is a source file, the lrs data is compiled as binary into the exe. The lrs has the overhead that it copies the data onto the heap. fpcres can sometimes avoid that.
AFAIK fpcres does not yet support any kind of binary.

Mattias

The lrs size wasn't my concern, the resulting binary was: it contained the #iii escaped data. This has perhaps changed in newer fpc versions.

Ludo

The compiler converts each #iii to 1 byte. That's why the lrs was always saved as binary in the exe. For older fpc < 2.0 (not sure, but it is long ago) the data had to be cut in 1KB chunks, so there was an overhead of a few percent.

Mattias

some help on the forum, I could implement an alternative way of storing files in an executable file (basically it just appends them with a footer).

This is actually a very common method that is used by installers and other self-extracting programs frequently (especially under Linux). UPX calls them "overlays", although i'm not sure this is a common term. In any case, this isn't a method that should be used by a compiler or other generic tool, because a lot of overlay loading implementations read the header file of the executable to figure out where the extra data are located and if compilers place extra data there, there will be conflicts.

mark the application as a virus if it tries to read the such resources.
At least there were some.

thanks,
Dmitry