Mitsuko Aninikkou wrote:Mrs Peel, a bit off-topic but I stumbled upon some things while making an addon using your µTorrent inf as a template.
Not off topic at all. I only wish I had started a post about this before I started posting my rebuilds, cos it would have saved me 3 or 5 rewrites on some of them
So I will take this opportunity to explain my reasoning behind what I have done so far....
Mitsuko Aninikkou wrote:Firstly apparently taskkill is only included in Windows XP Pro, Windows XP Home users won't have it (can't confirm this as I don't have Windows XP Home). You can use tskill which is included in both versions but is more limited. Also neither program works if terminal services is removed with nLite, or if they're removed as part of the command line utilities with nLite.
Yes, somebody has already bought this to my attention and the point you make about what happens if a user has removed certain components with nLite is a very good one too.
Firstly, I am trying my best to cover all possible uninstall scenarios so that a program is removed completely and this has taken a lot of extra field testing on my part, because many of the utilities I have been releasing here as addons thinking that they were completely
portable (self-contained) are actually adding stuff to their program files, users app data folder and registry on first run. So all those extra things I have had to make allowances for in my uninstallers.
I also have tried my best to cover all contingencies with the different operating systems as well. I personally run Win2003 server here and for the most part whatever runs on 2003 will also work fine on XP, but I confess that I had only been testing on XP Pro and not made allowances for any differences with XP Home. So all I can say is sorry about that and it is something I will be sure to consider in future.
Also I have recently been informed that the [SourceDisksNames.x86] will not work with 64-bit O/S's so I have had to make sure to include that in my release notes from now on. And please note that I will currently NOT be supporting 64-bit addons - except in the very RARE event that I might find myself on 64-bit in future (not in my upgrade budget for at least the next 5yrs)
I am still pondering on a solution to this absence of taskkill.exe in XP Home and my possible solutions might be to include a copy of that in the original installer - but I am not particularly in favour of that option except as a last resort, because I don't think it's polite to include stuff in my addons that might replace a user's existing system files.
The other possibility is that it might be feasible to add an extra set of commands in the inf file that XP Home can recognise and call on tskill
instead of taskkill. If anybody has any suggestions about that I am always open to constructive input.
Ideally however, users should be wise enough to do the suggested thing and "close running programs" before they install or uninstall stuff - but heck who even bothers to do that?
I know I rarely ever do LOL, which is why I decided to include the Kill Process in the first place hehehe
Mitsuko Aninikkou wrote:Secondly you might want to add another copyfiles directive to the DefaultInstall section to copy the inf to %17%; the inf will be copied there during windows setup but not if you install it manually. (of course when you install the program manually it will also complain about the cab not being in the i386 folder, but the user can easily select the correct location)
Thanks for mentioning this also because I thought about this and made a concious decision to not do that and here's my reasoning:
I am thinking that if a user is advanced enough to be able to figure out firstly to "right click on inf to install" and secondly to know that when the windows pops up asking them for their i386 folder that this means they need to actually navigate to the folder of the unarchived addon cab and point their browser to that (which novice users obviously would not know how to do) then they should also be technically savy enough to know they must copy their inf file to the %17% directory.
Another thought I have about this is that I am not making these for local installs, I am making them to be integrated into an unattended setup, so I have to ask myself do I really want to make it easy for people to use Ryans server as a repository to download local installers that they should be sourcing directly from the program authors site and consuming the developers server's bandwidth instead of his.
I hope this reasoning makes sense, yes?
Mitsuko Aninikkou wrote:Finally to remove the inf after uninstallation completes add a DelFiles directive with %prog_infs%,,,1. (you know how this works, I'm just pointing out that currently the inf remains after uninstallation)
Edit: Actually, scratch that last, here's a much better way to do it:
Cleanup = 1
Will get rid of the inf called to uninstall the program. (although it doesn't get rid of the 'Precompiled Setup Information' .pnf file windows seems to create)
Yes I am aware of that and if you happened to download any of my first batch of uninstaller rebuilds you will notice that I did have them set to delete the inf and also the pnf files from the %17% BUT I have since been informed of a very big problem with doing that on XP and Win2000 (it is not a problem for Win2003 however) which is this....
If the software has been unattendedly installed from a slipstreamed windoze ISO (integratored or nlited) then there will be an extra line of code placed in your sysoc file pointing to the inf file in the %17% directory which looks like this:
Code: Select all
If the inf file is deleted then the next time you run windoze add/remove programs applet it will kick up a fit telling you that the inf file is missing - because, as I have since learned, these integrated addons are being recognised as windoze components and obviously windoze does not like it when the sysoc tells it a component (or part of that compenent) should be there and it can't find it.
This is a very big annoyance to me and I don't know why Win2003 is not bothered by this but yet the other O/S's go nuts. The only feasible way to safely reinclude my inf/pnf file deletes again in my uninstallers is if we could figure out a way for the uninstallation sequence to edit the sysoc file and remove the line of code referring to that deleted inf/pnf file.
I've spoken to quite a few advanced techy people about this and nobody has a solution (as yet). There is one small ray of hope however, which is that bashrat has somehow figured out a way to remove entries in the sysoc with his driver pack builds. So I have a friend investigating that for me at the moment.
As soon a workable solution is found then I will reinclude the inf/pnf deletes. I sure hope we can find one because I so detest incomplete installations - it's a major pet annoyance of mine (right up there with peeps not acknowledging me for my work ROFL)
Mitsuko Aninikkou wrote:Thanks for all your work on this! ^_^
Thanks for the acknowledgement