Hi everyone I've been working on a new native Windows installer for Freenet for some time now. It's actually almost done! A quick round-up of the features:
- Simple customized offline "1-click installer" - Prechecks for required admin privileges (including Vista UAC escalation), Windows version, Java version (helps the user installing/upgrading his Java via the bundled online installer, see screenshot below) and old installations - Support for multiple concurrent installations - Port availability check and automatic selection (hard-coded limit of 256 checks because of the time requirements) for both fproxy and fcp ports - Semi-intelligent installation folder selector (checks path for existing installation, the "Freenet" keyword (if not found, appends "\Freenet" to avoid installing in root of drive or "Program files" folder), too long for file system to handle, not enough free space (with reserve for other software and Windows itself) and write-access. Install path status is updated live (see screenshot below). - Checkboxes for "Install start menu shortcuts", "Install desktop shortcut" and "Browse Freenet after installation" - Reduced installer file size (9.5 -> 7.5 MB) and number of files installed - New browse/start/stop bins will be included as well (mostly to fix Vista issues and support concurrent installs) On my to-do before a release is: - i18n support - Command line support - Support for recognizing more browsers in the launcher (need a list of which we support, btw.) - Maybe an "advanced" GUI allowing user to pick fproxy and fcp ports - Maybe support for reinstallation (while keeping identity and settings) Screenshots: http://privat.zero3.dk/FreenetInstaller_MainGUI.png http://privat.zero3.dk/FreenetInstaller_JavaMissing.png However, there are some remaining policy questions to be answered before I can send out a working alpha. So here we go: 1) Is it worth the time to include checks for existing 0.5 installations in order to not collide with them? 2) Is there anything in the folder structure that ought to be moved around? E.g. atm. we have browse.cmd in the install root, but start.cmd and stop.cmd in the bin folder. My installer also creates a new installid.dat file containing a string needed to identify the node among concurrent installations. Is there some kind of guideline about where files should be placed? 3) If FireFox (or whatever "safe" browsers we support) is not found, and the launcher falls back to using Internet Explorer, should it warn/nag the user about the problem with using IE, and suggest installing another browser? 4) Would it be a good idea (read: worth the time) to make the installer log its progress to a logfile in the system's temporary folder for debugging/troubleshooting reasons? 5) Is the .fref file association a good idea at all? It's a bit messy, and very hard to manage in environments with multiple installations or nodes on another machine than the client. It seems like we are moving towards friend codes/tokens in the future too, so is it really worth keeping? Isn't the upload/paste reference features in fproxy good enough for now? 6) update.cmd was *not* created with concurrent installations in mind (read: it won't work), and certainly won't be compatible with the current installer and mine at the same time. The best solution would probably be to branch update.cmd for my installer. Juiceman, how are you feeling about it (being the current maintainer)? Constructive feedback/questions/suggestions/etc. welcome :) - Zero3
