On Sunday 01 February 2009 15:33, Zero3 wrote:
> I'm going to merge several discussions from several places to here - I 
> hope you don't mind toad.
> 
> Matthew Toseland skrev:
> > I am not in a position to maintain it without help - I have not tried to 
build 
> > it yet. It uses one unmaintained freeware utility in the build process and 
> > another one at install time. And it is not localisable, and has to force 
font 
> > sizes and so on, with the result being that it likely would require major 
> > changes for l10n. In short it's not ready. Thanks for your help, but I'm 
not 
> > in a position to fix it and make it ready at the moment. IMHO it is not a 
> > critical piece of functionality for 0.8.0. What *is* critical is that 
> > start/stop work on Vista... getting clean start.exe/stop.exe's that can be 
> > shipped with our current installer is not straightforward either, but it 
does 
> > avoid some of the other problems...
> >   
> 
> Matthew Toseland skrev:
> > Using unmaintained freeware in the build process is unacceptable.
> >
> > Source is available for XN Resource Editor, is there a command line 
version?
> >
> > http://www.wilsonc.demon.co.uk/d10resourceeditor.htm
> >
> > Also, RemProf.exe is freeware and not maintained and source code will not 
be 
> > made available, and we use that at install time.
> >
> > Do we use any freeware utilities in the current java installer? I think 
maybe 
> > there was one...? If so, maybe it's an acceptable risk, but it should be 
> > minimised nonetheless - what we need most urgently are UAC-escalated 
> > start/stop exe's for the java installer.
> 
> Matthew Toseland skrev:
> > In fact, we already use netuser.exe on Windows ... see bug #1709. This is 
> > closed source freeware, although we may be able to replace it one day as 
it 
> > doesn't do very much; you probably call the dll's in your AHK code.
> >
> > Anyway, mingwin comes with a resource script compiler. So all we need to 
do is 
> > extract the resource script (which is source code), and if necessary edit 
it, 
> > then compile it with mingwin and feed it to the AHK compiler? This 
eliminates 
> > the need for reshacker.exe, so we can build start.exe and stop.exe cleanly 
> > from source and use them in our installer. Can AHK compile resource 
scripts, 
> > or does it need it to be already compiled? Could you extract and 
decompile, 
> > or assemble, the resource file needed for start.exe/stop.exe to escalate 
> > themselves?
> >
> > If we can fix the fact that Vista doesn't work before 0.8.0, that would be 
> > great. But actually using the AHK-based installer has other issues, so 
*for 
> > now* I'm saying no.
> >   
> 
> I plan on maintaining the installer regardless of my real life plans. 
> But I'm not sure that I will have to time to implement major features 
> during my military service (depends on how much free time I get in the 
> next 4 months that it lasts). Real life comes first, after all.
> 
> Regarding third party utilities, I think you need to look at the 
> situation from another perspective. Here is my viewpoint:
> 
> What we currently use in the Java installer:
> - cat.exe (used by install scripts, open-source GNU)
> - netuser.exe (used to set "password never expires" flag on an account. 
> Unknown origin (credited "Siemes AG") and source status)

netuser.exe is unmaintained closed source freeware. Having said that, it is a 
very small utility which we could replace - unfortunately it uses APIs that 
mingwin doesn't expose.

> - Ntrights.exe (used to set account rights. Seems to come from a Windows 
> 2000 resource kit (credited "Beta Version by Georg Zanzen"). Probably 
> unmaintained and closed-source?)

AFAIK this is a Microsoft redistributable.

> - sed.exe (used by install scripts

Also open source and GNU afaik.

> - wget.exe (used by install scripts, open-source GNU)
> 
> In my installer:
> - cat.exe, sed.exe and wget.exe are not needed
> - netuser.exe and Ntrights.exe usage has been copied/ported

Yes but there are two new exe's you need:
reshacker.exe in the build process
RemProf.exe in installation.

Both are unmaintained closed source freeware.
> 
> So far, that must be kind of an improvement in this area, aye?
> 
> When testing, I realized that the user's profile folder ("C:\Documents 
> and Settings\..." on XP) and various user registry entries are *not* 
> deleted when we delete the user in the current installer, and that there 
> apparently isn't a straightforward way to do this (yes, another argument 
> from me about not creating a custom user account - but never mind). 
> Instead of leaving the files intact (cluttering the user's machine + 
> leaving permanent traces of Freenet), I found a third party freeware 
> utility called RemProf.exe from an IT consultancy website. In my 
> opinion, it's more important to have full functionality with the cost of 
> using a couple of closed-source tools rather than not providing full 
> functionality, and in this case, leaving permanent and easily-available 
> traces of Freenet on every single Windows machine it has been installed 
> onto.
> 
> If you don't agree - I can simply remove the utility again. In any way, 
> I cannot see how this can be an argument *against* deploying my 
> installer, as worst-case scenario (when comparing to the current 
> installer) is 'no improvement' in this particular area.

What is wrong with just recursively deleting the directory?
> 
> In the build process, I'm using the closed-source freeware tool Resource 
> Hacker (http://www.angusj.com/resourcehacker/) to add Freenet icons and 
> Vista UAC manifests to the binaries. Resource Hacker is pretty much 
> *the* tool to modify Windows executable resources. If you don't take my 
> word on it, googling "Resource Hacker" returns ~775.000 results (you 
> could compare that to the ~19.000 results for "ntrights"). The 3 million 
> downloads (according to the site) kind of supports that. It is true that 
> it is no longer under any development, but I'd argue that it doesn't 
> matter, since it's practically "done" and works just fine. There are 
> most likely open-source tools with the same functionality (you mention a 
> MinGW tool yourself),  but in my opinion it was a better solution to use 
> the well-known tool I knew worked and knew how to use, compared to spend 
> my limited time testing new tools and delaying a release.
> 
> Regarding l10n, I don't know where you've got:
> 
> "...And it is not localisable, and has to force font sizes and so on, 
> with the result being that it likely would require major changes for 
> l10n...."
> 
> from. I have chosen to set a specific font and font size for the english 
> version to ensure GUI layout consistency across different setups - 
> rather than relying on unknown user settings that might mess up the 
> layout. A translator can simply pick another font and font size for his 
> language if he feels that works better. Of course implementing l10n 
> requires changes to the source (as any feature does). Again, I've felt 
> it was more important to actually get a good, working installer out, 
> rather than spending a lot of time in l10n which always can be added 
> later on. As far as I know, the greatest commonly understood language 
> among our users is English, hence it makes sense to me to start out with 
> an English version.

My understanding from reading the source code is that you make assumptions 
about the number of lines/characters in many places. Isn't this true?
> 
> Regarding "Can AHK compile resource scripts, or does it need it to be 
> already compiled?": The AHK compiler is shipped with a "base" consisting 
> of the library and PE headers and stuff - and then compiles the script 
> into/on top of the base. The base is what we modify to replace and add 
> resources (Freenet icons and UAC manifest).

Ok. So the old base can be produced cleanroom by compiling AHK from source 
under mingwin. And we need some procedure to transform that into the new 
base. At the moment this is implemented with Resource Hacker.
> 
> Regarding "Could you extract and decompile, or assemble, the resource 
> file needed for start.exe/stop.exe to escalate themselves?": The 
> manifest that needs to be "manifested" into an .exe to make it 
> selv-UAC-elevate is in SVN already.

This is an additional resource to be added, right? We have a bunch of 
resources to remove, also. Currently reshacker does this.
> 
> In my very humble opinion, we are talking about *minor* issues compared 
> to great improvements. But I'll leave that to you guys to decide...
> 
> - Zero3

Attachment: pgpug7gDDGnPW.pgp
Description: PGP signature

_______________________________________________
Devl mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to