On Thu, May 21, 2009 at 6:58 AM, Zero3 <zero3 at zerosplayground.dk> wrote: > Matthew Toseland skrev: >> On Sunday 17 May 2009 11:41:00 Zero3 wrote: >>> Matthew Toseland skrev: >>>>> Detecting the version of an installed application in the launcher (at >>>>> least in Windows) shouldn't be a problem. It will most likely be >>>>> registered in the registry next to the .exe path we are checking already >>>>> for the individual browsers. We can also check the version info of .exes >>>>> as an alternative (most Windows applications are compiled with various >>>>> static info like version and author). The Windows launcher is already >>>>> running Chrome with a command line argument making it start in privacy >>>>> mode btw. >>>> You should prioritise Chrome with privacy mode over Firefox without it. >>> Agreed: https://bugs.freenetproject.org/view.php?id=3118. >> >> I thought you had already done this? > > At time of writing, no. But since then I managed to figure git out and > changed it (hence the bug is now "resolved"). > > ... which leads to another thing to consider: We need to make it > possible to update the start.exe/stop.exe/freenetlauncher.exe files for > existing users when new updates are made available. > > The easiest way to do this right now would probably be to add them to > the update.cmd script. > > - Zero3 > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >
I would be happy to do this, however I will need a defined directory structure on the download site, with known file names. Like we have the .url link for the freenet.jar. I believe I can use the .sha1 file to check for updates if you want to have a static name. ie wrapper_win32x86.exe etc. Also I would prefer to not have them inside a zip unless we have have a built-in unzipping program in Windows I can reliably call by command line. Otherwise we will have to bundle yet another third party utility.