Portable updated

I just created a portable release of the 5.0 beta code. Other than previous portable releases, this is not an installer any longer, but a simple ZIP file. Just unpack and run it.

How does HeidiSQL portable exactly work?
r3201 implements additional code into heidisql.exe, which checks for a "portable_settings.txt" file in the same directory. If present, heidisql.exe will read any settings from this file into a unique registry key, without interfering any running Heidi process or even other running portables. When you close the main window, settings will be written to the above mentioned text file and the registry key gets removed.

This way, the user is able to create its own portable with any build (ok, any later than r3201), just by placing an empty textfile into the same directory.

from the build notes:

* Avoid using Microsoft's .reg file syntax, as you need admin privileges to
store and restore such files, even when using the appropriate Windows API
functions.

why create a custom parser/writer AND a new syntax for this file? it would be more useful for users to just have a regular .reg file so they dont need the software to restore settings manually. plus you can avoid custom file writing on save.

rather than a custom format or using windows .reg APIs, just treat it as an .ini file (maybe after stripping the header):
http://delphi.about.com/od/objectpascalide/a/tinifile.htm

as a last resort you can just write a basic parser for .reg files then read them in as text. it would eliminate the need for a custom format with the additional benefit of using the .reg or .ini APIs to run a straight export on save. would this work?

either way, not needing a separate launcher is a huge plus.

regards,
Leon

Thanks for suggestions. Some of them were also my first thought. But I think I pretty balanced all options out:
* INI files cannot grow larger than 64k, a section even not over 8k. My own settings have grown to ~130k already (although that might be quite large and not representative, but anyway).
* .reg files need admin privs if you don't want to write an own parser
* a parser for .reg files would have taken several hours more to implement and much less fun than it was now. Additionally I didn't see any benefit, apart from being able to doubleclick these as a user.