Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Osmium" Newsgroups: comp.programming Subject: Re: To all who write uninstallation programs for software you distribute Date: Sun, 24 Jul 2016 10:55:39 -0500 Lines: 75 Message-ID: References: <0hq7pblr580ec5n1sv05fapprarqc9ef9l@4ax.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=response Content-Transfer-Encoding: 7bit X-Trace: individual.net dLix6HBaE3WXwupcKCwrNwpb9OiJ2e8o27g6EccXZf+75JG65w Cancel-Lock: sha1:W8U3cfxaeergkypjiYCkUDuvmkg= X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Xref: csiph.com comp.programming:6783 "Richard Heathfield" wrote: > On 24/07/16 16:34, J. Clarke wrote: >> In article , rjh@cpax.org.uk says... >>> >>> On 24/07/16 16:00, Osmium wrote: >>>> "Richard Heathfield" wrote: >>>> >>>>> On 23/07/16 23:13, Wally W. wrote: >>>>>> To all who write uninstallation programs for software you distribute: >>>>> >>>>> Whenever possible, I prefer not to do this. To delete my software, you >>>>> just delete it, and you're done. Either >>>>> >>>>> cd where/did/you/put/it >>>>> rm * >>>>> >>>>> or maybe, just maybe, there are sub-directories, so: >>>>> >>>>> cd where/did/you/put/it >>>>> rm -rf * >>>>> >>>>> (careful!) >>>>> >>>>> or, if you're on Windows, one of the many Windows equivalents of doing >>>>> the same thing (such as dragging a pretty yellow box onto a picture of >>>>> a dustbin - alas, I can't promise sweeties to those who get this >>>>> right). >>>>> >>>>>> If your uninstallation program can't leave the machine in the >>>>>> condition you found it, then tell the user what is different. >>>>> >>>>> Hear, hear! But if your program /needs/ an uninstallation program, >>>>> there had better be an extraordinarily good reason. (And sometimes >>>>> there is. But it's rarer than many people think.) >>>> >>>> I long for the good old days too. >>>> >>>> But doesn't your approach fail in one of the most elementary cases on >>>> Windows? A new program with a new data file. You want to click on the >>>> data file and invoke the program. How can you do that without changing >>>> the data used by the OS? To me, that is SOP and not rare at all. >>> >>> But the /user/ is responsible for setting up that association. The user >>> double-clicks on "foo.bar", and Windows says "huh? You'd better choose a >>> program for that", and the user chooses my program, and that's the >>> user's choice, so it's the user's problem. >> >> And the tech support guys think badly of you when they have to remote- >> access 10,000 machines and set up that association that _should_ have >> been set up by the installer. > > I understand your point but I don't agree with it. File associations are a > pain in the neck, because they rely on a false premise - i.e. that the > file extension uniquely determines the type of the file. > > I once had to write a program to inspect the first few bytes of a PDF to > discover whether it was a Portable Document Format file (a document) or a > Program Description File (a format used by a screen layout descriptor > utility for COBOL programmers). The program had to decide which one it > was, and then call either Acrobat or the screen layout thing - and the > users associated .pdf with /my/ program, rather than Acrobat or the > utility. > > File extensions go at least as far back as VM/CMS, but they were never > designed to uniquely determine the type of file (even VM/CMS used file > mode descriptors rather than extensions to determine whether a file was > supposed to be executable). File associations were a badly-designed > overlay onto file extensions, and Microsoft has done little, if anything, > to address the problems that file associations cause. I probably agree with all that. But it's a bit like complaining about the way words are spelled in the English language. For the most part, it works, and people expect other people to honor the conventions.