Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming > #6775 > unrolled thread
| Started by | Wally W. <ww84wa@aim.com> |
|---|---|
| First post | 2016-07-23 18:13 -0400 |
| Last post | 2016-07-31 03:19 -0700 |
| Articles | 20 on this page of 45 — 9 participants |
Back to article view | Back to comp.programming
To all who write uninstallation programs for software you distribute Wally W. <ww84wa@aim.com> - 2016-07-23 18:13 -0400
Re: To all who write uninstallation programs for software you distribute Kaz Kylheku <349-534-5780@kylheku.com> - 2016-07-24 06:44 +0000
Re: To all who write uninstallation programs for software you distribute Julio Di Egidio <julio@diegidio.name> - 2016-07-24 04:53 -0700
Re: To all who write uninstallation programs for software you distribute Kaz Kylheku <349-534-5780@kylheku.com> - 2016-07-25 04:13 +0000
Re: To all who write uninstallation programs for software you distribute Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 08:28 +0100
Re: To all who write uninstallation programs for software you distribute Richard Heathfield <rjh@cpax.org.uk> - 2016-07-24 09:40 +0100
Re: To all who write uninstallation programs for software you distribute "Osmium" <r124c4u102@comcast.net> - 2016-07-24 10:00 -0500
Re: To all who write uninstallation programs for software you distribute Richard Heathfield <rjh@cpax.org.uk> - 2016-07-24 16:18 +0100
Re: To all who write uninstallation programs for software you distribute "J. Clarke" <j.clarke.873638@gmail.com> - 2016-07-24 11:34 -0400
Re: To all who write uninstallation programs for software you distribute Richard Heathfield <rjh@cpax.org.uk> - 2016-07-24 16:46 +0100
Re: To all who write uninstallation programs for software you distribute "Osmium" <r124c4u102@comcast.net> - 2016-07-24 10:55 -0500
Re: To all who write uninstallation programs for software you distribute Richard Heathfield <rjh@cpax.org.uk> - 2016-07-24 17:08 +0100
Re: To all who write uninstallation programs for software you distribute "J. Clarke" <j.clarke.873638@gmail.com> - 2016-07-24 12:24 -0400
Re: To all who write uninstallation programs for software you distribute Richard Heathfield <rjh@cpax.org.uk> - 2016-07-24 17:37 +0100
Re: To all who write uninstallation programs for software you distribute "J. Clarke" <j.clarke.873638@gmail.com> - 2016-07-24 13:16 -0400
Re: To all who write uninstallation programs for software you distribute Richard Heathfield <rjh@cpax.org.uk> - 2016-07-24 18:53 +0100
Re: To all who write uninstallation programs for software you distribute "J. Clarke" <j.clarke.873638@gmail.com> - 2016-07-24 15:11 -0400
Re: To all who write uninstallation programs for software you distribute "Osmium" <r124c4u102@comcast.net> - 2016-07-24 14:45 -0500
Re: To all who write uninstallation programs for software you distribute Richard Heathfield <rjh@cpax.org.uk> - 2016-07-24 21:31 +0100
Re: To all who write uninstallation programs for software you distribute "J. Clarke" <j.clarke.873638@gmail.com> - 2016-07-24 18:06 -0400
Re: To all who write uninstallation programs for software you distribute Richard Heathfield <rjh@cpax.org.uk> - 2016-07-24 23:53 +0100
Re: To all who write uninstallation programs for software you distribute "J. Clarke" <j.clarke.873638@gmail.com> - 2016-07-24 18:04 -0400
Re: To all who write uninstallation programs for software you distribute Richard Heathfield <rjh@cpax.org.uk> - 2016-07-24 23:47 +0100
Re: To all who write uninstallation programs for software you distribute Wally W. <ww84wa@aim.com> - 2016-07-24 19:34 -0400
Re: To all who write uninstallation programs for software you distribute Wally W. <ww84wa@aim.com> - 2016-07-24 14:03 -0400
Re: To all who write uninstallation programs for software you distribute "J. Clarke" <j.clarke.873638@gmail.com> - 2016-07-24 12:10 -0400
Re: To all who write uninstallation programs for software you distribute Richard Heathfield <rjh@cpax.org.uk> - 2016-07-24 17:36 +0100
Re: To all who write uninstallation programs for software you distribute "Osmium" <r124c4u102@comcast.net> - 2016-07-24 11:37 -0500
Re: To all who write uninstallation programs for software you distribute "J. Clarke" <j.clarke.873638@gmail.com> - 2016-07-24 13:24 -0400
Re: To all who write uninstallation programs for software you distribute "Osmium" <r124c4u102@comcast.net> - 2016-07-24 18:29 -0500
Re: To all who write uninstallation programs for software you distribute Wally W. <ww84wa@aim.com> - 2016-07-24 20:34 -0400
Re: To all who write uninstallation programs for software you distribute Mark Storkamp <mstorkamp@yahoo.com> - 2016-07-25 10:00 -0500
Re: To all who write uninstallation programs for software you distribute "Osmium" <r124c4u102@comcast.net> - 2016-07-25 11:22 -0500
Re: To all who write uninstallation programs for software you distribute Kaz Kylheku <349-534-5780@kylheku.com> - 2016-07-25 18:55 +0000
Re: To all who write uninstallation programs for software you distribute Wally W. <ww84wa@aim.com> - 2016-07-26 00:19 -0400
Re: To all who write uninstallation programs for software you distribute Kaz Kylheku <349-534-5780@kylheku.com> - 2016-07-26 04:24 +0000
Re: To all who write uninstallation programs for software you distribute "Osmium" <r124c4u102@comcast.net> - 2016-07-26 09:13 -0500
Re: To all who write uninstallation programs for software you distribute Öö Tiib <ootiib@hot.ee> - 2016-07-26 14:11 -0700
Re: To all who write uninstallation programs for software you distribute Wally W. <ww84wa@aim.com> - 2016-07-27 02:58 -0400
Re: To all who write uninstallation programs for software you distribute Kaz Kylheku <349-534-5780@kylheku.com> - 2016-07-27 13:47 +0000
Re: To all who write uninstallation programs for software you distribute Wally W. <ww84wa@aim.com> - 2016-07-24 13:24 -0400
Re: To all who write uninstallation programs for software you distribute Wally W. <ww84wa@aim.com> - 2016-07-24 13:40 -0400
Re: To all who write uninstallation programs for software you distribute Wally W. <ww84wa@aim.com> - 2016-07-24 13:42 -0400
Re: To all who write uninstallation programs for software you distribute Kaz Kylheku <349-534-5780@kylheku.com> - 2016-07-24 18:29 +0000
Re: To all who write uninstallation programs for software you distribute SIKDER EMRAN <sikderemran4321@gmail.com> - 2016-07-31 03:19 -0700
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-24 23:53 +0100 |
| Message-ID | <nn3gu0$m3l$1@dont-email.me> |
| In reply to | #6802 |
On 24/07/16 23:06, J. Clarke wrote: > In article <nn38ib$omn$2@dont-email.me>, rjh@cpax.org.uk says... >> >> On 24/07/16 20:45, Osmium wrote: >>> "J. Clarke" <j.clarke.873638@gmail.com> wrote in message >>> news:MPG.31fedcfe5aa7cb6298a3b8@news.eternal-september.org... >>>> In article <nn2vbj$o1h$1@dont-email.me>, rjh@cpax.org.uk says... >>>>> >>>>> On 24/07/16 18:16, J. Clarke wrote: >>>>>> In article <nn2qsj$8er$2@dont-email.me>, rjh@cpax.org.uk says... >>>>>>> >>>>>>> On 24/07/16 17:24, J. Clarke wrote: >>>>>>>> In article <nn2p5s$2j1$1@dont-email.me>, rjh@cpax.org.uk says... >>>>>>>>> >>>>>>>>> On 24/07/16 16:55, Osmium wrote: >>>>>>>>>> "Richard Heathfield" wrote: >>>>>>>>>> >>>>>>>>>>> On 24/07/16 16:34, J. Clarke wrote: >>>>>>>>>>>> In article <nn2m7t$o38$2@dont-email.me>, 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. >>>>>>>>> >>>>>>>>> If it's in the program spec, fair enough, but there'd better be >>>>> a >>>> way to >>>>>>>>> remove it, also in the program spec. >>>>>>>>> >>>>>>>>> If it's not in the program spec, then it's just extra work for >>>>> no >>>> benefit. >>>>>>>>> >>>>>>>>> And that's true for pretty much any "it", not just file >>>> >>>>> associations. >>>>>>>> >>>>>>>> Are you one of those guys who can't figure out what features are >>>>>>>> needed >>>>>>>> until someone else writes a spec and then you do the bare minimum >>>>>>>> necessary to meet the spec? >>>>>>> >>>>>>> Yup. I guess you're one of those guys who keeps adding features until >>>>>>> the machine crashes under the weight of them, and then removes the >>>>>>> last one. >>>>>>> >>>>>>> It's /so/ easy to denigrate other people's design choices, isn't it? >>>>>> >>>>>> In other words you're a programmer who has never held nor aspired >>>>> to > the >>>>>> systems analyst role. >>>>> >>>>> And it's also very easy to jump to incorrect conclusions. >>>> >>>> You expect someone else to do the design and when it comes acropper you >>>> point the finger at them instead of yourself, so it is difficult to draw >>>> any other conclusion. >>> >>> That's not what he said at all - he said he wanted someone else to write >>> the specification. >> >> I didn't even say /that/. > > Your argument seems to be that you code to the specification Yes. Your argument seems to be that you think it's a stupid idea to observe the program specification. Interesting. > and that the specification is not your responsibility. Whether the specification is my responsibility depends on whether I wrote the specification. Sometimes I write the program spec, and sometimes I don't. That's par for the course, surely? -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | "J. Clarke" <j.clarke.873638@gmail.com> |
|---|---|
| Date | 2016-07-24 18:04 -0400 |
| Message-ID | <MPG.31ff058632dcb41c98a3bb@news.eternal-september.org> |
| In reply to | #6799 |
In article <dvkk6aF6prjU1@mid.individual.net>, r124c4u102@comcast.net says... > > "J. Clarke" <j.clarke.873638@gmail.com> wrote in message > news:MPG.31fedcfe5aa7cb6298a3b8@news.eternal-september.org... > > In article <nn2vbj$o1h$1@dont-email.me>, rjh@cpax.org.uk says... > >> > >> On 24/07/16 18:16, J. Clarke wrote: > >> > In article <nn2qsj$8er$2@dont-email.me>, rjh@cpax.org.uk says... > >> >> > >> >> On 24/07/16 17:24, J. Clarke wrote: > >> >>> In article <nn2p5s$2j1$1@dont-email.me>, rjh@cpax.org.uk says... > >> >>>> > >> >>>> On 24/07/16 16:55, Osmium wrote: > >> >>>>> "Richard Heathfield" wrote: > >> >>>>> > >> >>>>>> On 24/07/16 16:34, J. Clarke wrote: > >> >>>>>>> In article <nn2m7t$o38$2@dont-email.me>, 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. > >> >>>> > >> >>>> If it's in the program spec, fair enough, but there'd better be a > >> >>>> way to > >> >>>> remove it, also in the program spec. > >> >>>> > >> >>>> If it's not in the program spec, then it's just extra work for no > >> >>>> benefit. > >> >>>> > >> >>>> And that's true for pretty much any "it", not just file > >> >>>> associations. > >> >>> > >> >>> Are you one of those guys who can't figure out what features are > >> >>> needed > >> >>> until someone else writes a spec and then you do the bare minimum > >> >>> necessary to meet the spec? > >> >> > >> >> Yup. I guess you're one of those guys who keeps adding features until > >> >> the machine crashes under the weight of them, and then removes the > >> >> last one. > >> >> > >> >> It's /so/ easy to denigrate other people's design choices, isn't it? > >> > > >> > In other words you're a programmer who has never held nor aspired to > >> > the > >> > systems analyst role. > >> > >> And it's also very easy to jump to incorrect conclusions. > > > > You expect someone else to do the design and when it comes acropper you > > point the finger at them instead of yourself, so it is difficult to draw > > any other conclusion. > > That's not what he said at all - he said he wanted someone else to write the > specification. Yes, he said that and so in his opinion it's the spec writer's fault that there was no installer or uninstaller, he bears no responsibility or blame at all. Just obeying orders . . .
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-24 23:47 +0100 |
| Message-ID | <nn3gie$kp0$3@dont-email.me> |
| In reply to | #6801 |
On 24/07/16 23:04, J. Clarke wrote: > In article <dvkk6aF6prjU1@mid.individual.net>, r124c4u102@comcast.net > says... >> >> "J. Clarke" <j.clarke.873638@gmail.com> wrote in message >> news:MPG.31fedcfe5aa7cb6298a3b8@news.eternal-september.org... >>> In article <nn2vbj$o1h$1@dont-email.me>, rjh@cpax.org.uk says... >>>> >>>> On 24/07/16 18:16, J. Clarke wrote: >>>>> In article <nn2qsj$8er$2@dont-email.me>, rjh@cpax.org.uk says... >>>>>> >>>>>> On 24/07/16 17:24, J. Clarke wrote: >>>>>>> In article <nn2p5s$2j1$1@dont-email.me>, rjh@cpax.org.uk says... >>>>>>>> >>>>>>>> On 24/07/16 16:55, Osmium wrote: >>>>>>>>> "Richard Heathfield" wrote: >>>>>>>>> >>>>>>>>>> On 24/07/16 16:34, J. Clarke wrote: >>>>>>>>>>> In article <nn2m7t$o38$2@dont-email.me>, 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. >>>>>>>> >>>>>>>> If it's in the program spec, fair enough, but there'd better be a >>>>>>>> way to >>>>>>>> remove it, also in the program spec. >>>>>>>> >>>>>>>> If it's not in the program spec, then it's just extra work for no >>>>>>>> benefit. >>>>>>>> >>>>>>>> And that's true for pretty much any "it", not just file >>>>>>>> associations. >>>>>>> >>>>>>> Are you one of those guys who can't figure out what features are >>>>>>> needed >>>>>>> until someone else writes a spec and then you do the bare minimum >>>>>>> necessary to meet the spec? >>>>>> >>>>>> Yup. I guess you're one of those guys who keeps adding features until >>>>>> the machine crashes under the weight of them, and then removes the >>>>>> last one. >>>>>> >>>>>> It's /so/ easy to denigrate other people's design choices, isn't it? >>>>> >>>>> In other words you're a programmer who has never held nor aspired to >>>>> the >>>>> systems analyst role. >>>> >>>> And it's also very easy to jump to incorrect conclusions. >>> >>> You expect someone else to do the design and when it comes acropper you >>> point the finger at them instead of yourself, so it is difficult to draw >>> any other conclusion. >> >> That's not what he said at all - he said he wanted someone else to write the >> specification. > > Yes, he said that No, I didn't. This could have been a polite and interesting conversation, but you turned it into a pissing match. Why? -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Wally W. <ww84wa@aim.com> |
|---|---|
| Date | 2016-07-24 19:34 -0400 |
| Message-ID | <hkjapb5jo0v0h41p8ufb6082kerrajgrta@4ax.com> |
| In reply to | #6801 |
On Sun, 24 Jul 2016 18:04:45 -0400, J. Clarke wrote: >In article <dvkk6aF6prjU1@mid.individual.net>, r124c4u102@comcast.net >says... >> >> "J. Clarke" <j.clarke.873638@gmail.com> wrote in message >> news:MPG.31fedcfe5aa7cb6298a3b8@news.eternal-september.org... >> > In article <nn2vbj$o1h$1@dont-email.me>, rjh@cpax.org.uk says... >> >> >> >> On 24/07/16 18:16, J. Clarke wrote: >> >> > In article <nn2qsj$8er$2@dont-email.me>, rjh@cpax.org.uk says... >> >> >> >> >> >> On 24/07/16 17:24, J. Clarke wrote: >> >> >>> In article <nn2p5s$2j1$1@dont-email.me>, rjh@cpax.org.uk says... >> >> >>>> >> >> >>>> On 24/07/16 16:55, Osmium wrote: >> >> >>>>> "Richard Heathfield" wrote: >> >> >>>>> >> >> >>>>>> On 24/07/16 16:34, J. Clarke wrote: >> >> >>>>>>> In article <nn2m7t$o38$2@dont-email.me>, 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. >> >> >>>> >> >> >>>> If it's in the program spec, fair enough, but there'd better be a >> >> >>>> way to >> >> >>>> remove it, also in the program spec. >> >> >>>> >> >> >>>> If it's not in the program spec, then it's just extra work for no >> >> >>>> benefit. >> >> >>>> >> >> >>>> And that's true for pretty much any "it", not just file >> >> >>>> associations. >> >> >>> >> >> >>> Are you one of those guys who can't figure out what features are >> >> >>> needed >> >> >>> until someone else writes a spec and then you do the bare minimum >> >> >>> necessary to meet the spec? >> >> >> >> >> >> Yup. I guess you're one of those guys who keeps adding features until >> >> >> the machine crashes under the weight of them, and then removes the >> >> >> last one. >> >> >> >> >> >> It's /so/ easy to denigrate other people's design choices, isn't it? >> >> > >> >> > In other words you're a programmer who has never held nor aspired to >> >> > the >> >> > systems analyst role. >> >> >> >> And it's also very easy to jump to incorrect conclusions. >> > >> > You expect someone else to do the design and when it comes acropper you >> > point the finger at them instead of yourself, so it is difficult to draw >> > any other conclusion. >> >> That's not what he said at all - he said he wanted someone else to write the >> specification. > >Yes, he said that and so in his opinion it's the spec writer's fault >that there was no installer or uninstaller, he bears no responsibility >or blame at all. Just obeying orders . . . Is there no conversation with the client before the spec is finalized? It may be there the spec writer's *preference* that there was no installer or uninstaller. If all software were as well-behaved as Richard described in his first post, there would be no need for installers or uninstallers. A separate utility might be included to set/release the file associations. If the client doesn't want an installer, what is wrong with "Just obeying orders?"
[toc] | [prev] | [next] | [standalone]
| From | Wally W. <ww84wa@aim.com> |
|---|---|
| Date | 2016-07-24 14:03 -0400 |
| Message-ID | <bj0apb1s7s7a0q7v8j1uqldl6s9l3o5av1@4ax.com> |
| In reply to | #6790 |
On Sun, 24 Jul 2016 13:16:21 -0400, J. Clarke wrote: >In article <nn2qsj$8er$2@dont-email.me>, rjh@cpax.org.uk says... >> >> On 24/07/16 17:24, J. Clarke wrote: >> > In article <nn2p5s$2j1$1@dont-email.me>, rjh@cpax.org.uk says... >> >> >> >> On 24/07/16 16:55, Osmium wrote: >> >>> "Richard Heathfield" wrote: >> >>> >> >>>> On 24/07/16 16:34, J. Clarke wrote: >> >>>>> In article <nn2m7t$o38$2@dont-email.me>, 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. >> >> >> >> If it's in the program spec, fair enough, but there'd better be a way to >> >> remove it, also in the program spec. >> >> >> >> If it's not in the program spec, then it's just extra work for no benefit. >> >> >> >> And that's true for pretty much any "it", not just file associations. >> > >> > Are you one of those guys who can't figure out what features are needed >> > until someone else writes a spec and then you do the bare minimum >> > necessary to meet the spec? >> >> Yup. I guess you're one of those guys who keeps adding features until >> the machine crashes under the weight of them, and then removes the last one. >> >> It's /so/ easy to denigrate other people's design choices, isn't it? > >In other words you're a programmer who has never held nor aspired to the >systems analyst role. Is the role of a system analyst to beat users into submission? There seems to be a lot of that attitude in IT departments. What part of "support group" isn't understood by so many people with admin passwords?
[toc] | [prev] | [next] | [standalone]
| From | "J. Clarke" <j.clarke.873638@gmail.com> |
|---|---|
| Date | 2016-07-24 12:10 -0400 |
| Message-ID | <MPG.31feb28b4acda68298a3b3@news.eternal-september.org> |
| In reply to | #6782 |
In article <nn2nt0$u39$1@dont-email.me>, rjh@cpax.org.uk says... > > On 24/07/16 16:34, J. Clarke wrote: > > In article <nn2m7t$o38$2@dont-email.me>, 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. <Sound of world's smallest violin> We get it, you don't like Windows and resent being compelled by forces beyond your control to write for it. That doesn't justify doing a half- assed job.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-24 17:36 +0100 |
| Message-ID | <nn2qqj$8er$1@dont-email.me> |
| In reply to | #6785 |
On 24/07/16 17:10, J. Clarke wrote: > In article <nn2nt0$u39$1@dont-email.me>, rjh@cpax.org.uk says... >> >> On 24/07/16 16:34, J. Clarke wrote: >>> In article <nn2m7t$o38$2@dont-email.me>, 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. > > <Sound of world's smallest violin> > > We get it, you don't like Windows and resent being compelled by forces > beyond your control to write for it. That doesn't justify doing a half- > assed job. Oddly, as a /programmer/ I like Windows rather a lot. It's just as a user that I think it sucks. And file associations are a problem for users (or, at least, for /some/ users), not for programmers. As for a half-assed job, well, I write to the spec. If the spec says I have to set up file associations, then so be it. But if it doesn't, so be not it. If the spec is full-assed, then I do a full-assed job. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | "Osmium" <r124c4u102@comcast.net> |
|---|---|
| Date | 2016-07-24 11:37 -0500 |
| Message-ID | <dvk966F444gU1@mid.individual.net> |
| In reply to | #6785 |
"J. Clarke" wrote: > In article <nn2nt0$u39$1@dont-email.me>, rjh@cpax.org.uk says... >> >> On 24/07/16 16:34, J. Clarke wrote: >> > In article <nn2m7t$o38$2@dont-email.me>, 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. > > <Sound of world's smallest violin> > > We get it, you don't like Windows and resent being compelled by forces > beyond your control to write for it. That doesn't justify doing a half- > assed job. I probably dislike Windows as much as Richard does. If we could revert to the pre-install era I would be willing to pay the price by doing a manual file association. But I am not at all sure that is the only change in practices that would be needed, it was just the most obvious one that occurred to me. Perhaps someone that has actually written official install/uninstall code could give more insight. When Windows has a problem the cure is to add another layer of magic. But I never know what all is happening in the new layer. For example, I have a very old (and very bad) book on the registry. Despite its age, it already has over 300 pages. That's a lot of magic!
[toc] | [prev] | [next] | [standalone]
| From | "J. Clarke" <j.clarke.873638@gmail.com> |
|---|---|
| Date | 2016-07-24 13:24 -0400 |
| Message-ID | <MPG.31fec3c16c71043e98a3b6@news.eternal-september.org> |
| In reply to | #6788 |
In article <dvk966F444gU1@mid.individual.net>, r124c4u102@comcast.net says... > > "J. Clarke" wrote: > > > In article <nn2nt0$u39$1@dont-email.me>, rjh@cpax.org.uk says... > >> > >> On 24/07/16 16:34, J. Clarke wrote: > >> > In article <nn2m7t$o38$2@dont-email.me>, 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. > > > > <Sound of world's smallest violin> > > > > We get it, you don't like Windows and resent being compelled by forces > > beyond your control to write for it. That doesn't justify doing a half- > > assed job. > > I probably dislike Windows as much as Richard does. If we could revert to > the pre-install era I would be willing to pay the price by doing a manual > file association. But I am not at all sure that is the only change in > practices that would be needed, it was just the most obvious one that > occurred to me. Perhaps someone that has actually written official > install/uninstall code could give more insight. > > When Windows has a problem the cure is to add another layer of magic. But I > never know what all is happening in the new layer. For example, I have a > very old (and very bad) book on the registry. Despite its age, it already > has over 300 pages. That's a lot of magic! Get over the notion that the registry is any kind of magic. It's just a bunch of settings and references, all in one place. The more stuff gets installed, the more entries there are in the registry. Knowing that it's there and what it does and the general structure of it is useful. Knowing every entry is not. On the other hand, proper documentation, which is in horribly short supply, _should_ detail any uses that _your_ program makes of the registry.
[toc] | [prev] | [next] | [standalone]
| From | "Osmium" <r124c4u102@comcast.net> |
|---|---|
| Date | 2016-07-24 18:29 -0500 |
| Message-ID | <dvl1b9F9qifU1@mid.individual.net> |
| In reply to | #6788 |
"Osmium" wrote: > I probably dislike Windows as much as Richard does. If we could revert to > the pre-install era I would be willing to pay the price by doing a manual > file association. But I am not at all sure that is the only change in > practices that would be needed, it was just the most obvious one that > occurred to me. Perhaps someone that has actually written official > install/uninstall code could give more insight. I thought of another glitch when one bypasses the Windows install routine. A program should be visible via. the Start|all programs ... little dance. A program activated in Richard's way will not list the new program. Perhaps one could devise a patch. But you have started on the journey to make a user into a programmer - this is not a good trip.
[toc] | [prev] | [next] | [standalone]
| From | Wally W. <ww84wa@aim.com> |
|---|---|
| Date | 2016-07-24 20:34 -0400 |
| Message-ID | <u8napbt29nqsps1hpd5ckdgqpc66emi39j@4ax.com> |
| In reply to | #6805 |
On Sun, 24 Jul 2016 18:29:44 -0500, Osmium wrote: >"Osmium" wrote: > >> I probably dislike Windows as much as Richard does. If we could revert to >> the pre-install era I would be willing to pay the price by doing a manual >> file association. But I am not at all sure that is the only change in >> practices that would be needed, it was just the most obvious one that >> occurred to me. Perhaps someone that has actually written official >> install/uninstall code could give more insight. > >I thought of another glitch when one bypasses the Windows install routine. > >A program should be visible via. the Start|all programs ... little dance. A >program activated in Richard's way will not list the new program. Perhaps >one could devise a patch. But you have started on the journey to make a >user into a programmer - this is not a good trip. Making shortcuts and setting associations are not programming. The alternative makes the user a victim. Some incompetent programmer left trash on my machine. I don't know where it is or how dangerous it might be for it remain installed with admin priviliges.
[toc] | [prev] | [next] | [standalone]
| From | Mark Storkamp <mstorkamp@yahoo.com> |
|---|---|
| Date | 2016-07-25 10:00 -0500 |
| Message-ID | <mstorkamp-0A8BA5.10001825072016@88-209-239-213.giganet.hu> |
| In reply to | #6805 |
In article <dvl1b9F9qifU1@mid.individual.net>, "Osmium" <r124c4u102@comcast.net> wrote: > "Osmium" wrote: > > > I probably dislike Windows as much as Richard does. If we could revert to > > the pre-install era I would be willing to pay the price by doing a manual > > file association. But I am not at all sure that is the only change in > > practices that would be needed, it was just the most obvious one that > > occurred to me. Perhaps someone that has actually written official > > install/uninstall code could give more insight. > > I thought of another glitch when one bypasses the Windows install routine. > > A program should be visible via. the Start|all programs ... little dance. A > program activated in Richard's way will not list the new program. Perhaps > one could devise a patch. But you have started on the journey to make a > user into a programmer - this is not a good trip. Here's a thought. The OS knows when something is written into the file system. If that thing being written is an executable program, the OS could keep track of that location and make it visible via. the Start|all programs thing you're referring to. To make things even simpler, the entire bundle of files required by the application could look like a single file to the OS, and could be copied, moved or deleted by the user at any time by referring to a single entity in the file system.
[toc] | [prev] | [next] | [standalone]
| From | "Osmium" <r124c4u102@comcast.net> |
|---|---|
| Date | 2016-07-25 11:22 -0500 |
| Message-ID | <dvmsmvFnm3sU1@mid.individual.net> |
| In reply to | #6810 |
"Mark Storkamp" wrote: > In article <dvl1b9F9qifU1@mid.individual.net>, > "Osmium" <r124c4u102@comcast.net> wrote: > >> "Osmium" wrote: >> >> > I probably dislike Windows as much as Richard does. If we could revert >> > to >> > the pre-install era I would be willing to pay the price by doing a >> > manual >> > file association. But I am not at all sure that is the only change in >> > practices that would be needed, it was just the most obvious one that >> > occurred to me. Perhaps someone that has actually written official >> > install/uninstall code could give more insight. >> >> I thought of another glitch when one bypasses the Windows install >> routine. >> >> A program should be visible via. the Start|all programs ... little dance. >> A >> program activated in Richard's way will not list the new program. >> Perhaps >> one could devise a patch. But you have started on the journey to make a >> user into a programmer - this is not a good trip. > > Here's a thought. The OS knows when something is written into the file > system. If that thing being written is an executable program, the OS > could keep track of that location and make it visible via. the Start|all > programs thing you're referring to. To make things even simpler, the > entire bundle of files required by the application could look like a > single file to the OS, and could be copied, moved or deleted by the user > at any time by referring to a single entity in the file system. Somehow, I don't think Microsoft will buy it. After all, they have already provided an install/uninstall mechanism that usually, or at least oftentimes, works. This thread was about a case where the uninstall thingy told the invoker that it had failed to some degree. The implication was that the invoker had bottled up information he had instead of sharing it with the ultimate user. Then the thread deteriorated into lectures about good programming practices and business ethics and morals.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <349-534-5780@kylheku.com> |
|---|---|
| Date | 2016-07-25 18:55 +0000 |
| Message-ID | <20160725115231.545@kylheku.com> |
| In reply to | #6810 |
On 2016-07-25, Mark Storkamp <mstorkamp@yahoo.com> wrote: > In article <dvl1b9F9qifU1@mid.individual.net>, > "Osmium" <r124c4u102@comcast.net> wrote: > >> "Osmium" wrote: >> >> > I probably dislike Windows as much as Richard does. If we could revert to >> > the pre-install era I would be willing to pay the price by doing a manual >> > file association. But I am not at all sure that is the only change in >> > practices that would be needed, it was just the most obvious one that >> > occurred to me. Perhaps someone that has actually written official >> > install/uninstall code could give more insight. >> >> I thought of another glitch when one bypasses the Windows install routine. >> >> A program should be visible via. the Start|all programs ... little dance. A >> program activated in Richard's way will not list the new program. Perhaps >> one could devise a patch. But you have started on the journey to make a >> user into a programmer - this is not a good trip. > > Here's a thought. The OS knows when something is written into the file > system. If that thing being written is an executable program, the OS > could keep track of that location and make it visible via. the Start|all > programs thing you're referring to. To make things even simpler, the > entire bundle of files required by the application could look like a > single file to the OS, and could be copied, moved or deleted by the user > at any time by referring to a single entity in the file system. If you accumulate more of these thoughts, you will soon reinvent such things as system restore points, versioned directory tree clones with hard-linked common content, and containment of individual applications by virtual machines. -- TXR Programming Lanuage: http://nongnu.org/txr Music DIY Mailing List: http://www.kylheku.com/diy ADA MP-1 Mailing List: http://www.kylheku.com/mp1
[toc] | [prev] | [next] | [standalone]
| From | Wally W. <ww84wa@aim.com> |
|---|---|
| Date | 2016-07-26 00:19 -0400 |
| Message-ID | <o3pdpbl1turrmimene9lvb3s276oh52hgp@4ax.com> |
| In reply to | #6816 |
On Mon, 25 Jul 2016 18:55:22 +0000 (UTC), Kaz Kylheku wrote: >On 2016-07-25, Mark Storkamp <mstorkamp@yahoo.com> wrote: >> In article <dvl1b9F9qifU1@mid.individual.net>, >> "Osmium" <r124c4u102@comcast.net> wrote: >> >>> "Osmium" wrote: >>> >>> > I probably dislike Windows as much as Richard does. If we could revert to >>> > the pre-install era I would be willing to pay the price by doing a manual >>> > file association. But I am not at all sure that is the only change in >>> > practices that would be needed, it was just the most obvious one that >>> > occurred to me. Perhaps someone that has actually written official >>> > install/uninstall code could give more insight. >>> >>> I thought of another glitch when one bypasses the Windows install routine. >>> >>> A program should be visible via. the Start|all programs ... little dance. A >>> program activated in Richard's way will not list the new program. Perhaps >>> one could devise a patch. But you have started on the journey to make a >>> user into a programmer - this is not a good trip. >> >> Here's a thought. The OS knows when something is written into the file >> system. If that thing being written is an executable program, the OS >> could keep track of that location and make it visible via. the Start|all >> programs thing you're referring to. To make things even simpler, the >> entire bundle of files required by the application could look like a >> single file to the OS, and could be copied, moved or deleted by the user >> at any time by referring to a single entity in the file system. > >If you accumulate more of these thoughts, you will soon reinvent >such things as system restore points, versioned directory tree clones >with hard-linked common content, and containment of individual >applications by virtual machines. Or, better yet, standalone programs with INI files.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <349-534-5780@kylheku.com> |
|---|---|
| Date | 2016-07-26 04:24 +0000 |
| Message-ID | <20160725212236.807@kylheku.com> |
| In reply to | #6817 |
On 2016-07-26, Wally W <ww84wa@aim.com> wrote: > On Mon, 25 Jul 2016 18:55:22 +0000 (UTC), Kaz Kylheku wrote: > >>On 2016-07-25, Mark Storkamp <mstorkamp@yahoo.com> wrote: >>> In article <dvl1b9F9qifU1@mid.individual.net>, >>> "Osmium" <r124c4u102@comcast.net> wrote: >>> >>>> "Osmium" wrote: >>>> >>>> > I probably dislike Windows as much as Richard does. If we could revert to >>>> > the pre-install era I would be willing to pay the price by doing a manual >>>> > file association. But I am not at all sure that is the only change in >>>> > practices that would be needed, it was just the most obvious one that >>>> > occurred to me. Perhaps someone that has actually written official >>>> > install/uninstall code could give more insight. >>>> >>>> I thought of another glitch when one bypasses the Windows install routine. >>>> >>>> A program should be visible via. the Start|all programs ... little dance. A >>>> program activated in Richard's way will not list the new program. Perhaps >>>> one could devise a patch. But you have started on the journey to make a >>>> user into a programmer - this is not a good trip. >>> >>> Here's a thought. The OS knows when something is written into the file >>> system. If that thing being written is an executable program, the OS >>> could keep track of that location and make it visible via. the Start|all >>> programs thing you're referring to. To make things even simpler, the >>> entire bundle of files required by the application could look like a >>> single file to the OS, and could be copied, moved or deleted by the user >>> at any time by referring to a single entity in the file system. >> >>If you accumulate more of these thoughts, you will soon reinvent >>such things as system restore points, versioned directory tree clones >>with hard-linked common content, and containment of individual >>applications by virtual machines. > > Or, better yet, standalone programs with INI files. Sure, but that's not an isolation technique that doesn't involve controlling the behavior of the installed program itself. If we have so much control over the program that we can determine how it stores its configuration, then we can fix its uninstall mess, too.
[toc] | [prev] | [next] | [standalone]
| From | "Osmium" <r124c4u102@comcast.net> |
|---|---|
| Date | 2016-07-26 09:13 -0500 |
| Message-ID | <dvp9ggFapvbU1@mid.individual.net> |
| In reply to | #6817 |
"Wally W." wrote: > On Mon, 25 Jul 2016 18:55:22 +0000 (UTC), Kaz Kylheku wrote: > >>On 2016-07-25, Mark Storkamp <mstorkamp@yahoo.com> wrote: >>> In article <dvl1b9F9qifU1@mid.individual.net>, >>> "Osmium" <r124c4u102@comcast.net> wrote: >>> >>>> "Osmium" wrote: >>>> >>>> > I probably dislike Windows as much as Richard does. If we could >>>> > revert to >>>> > the pre-install era I would be willing to pay the price by doing a >>>> > manual >>>> > file association. But I am not at all sure that is the only change >>>> > in >>>> > practices that would be needed, it was just the most obvious one that >>>> > occurred to me. Perhaps someone that has actually written official >>>> > install/uninstall code could give more insight. >>>> >>>> I thought of another glitch when one bypasses the Windows install >>>> routine. >>>> >>>> A program should be visible via. the Start|all programs ... little >>>> dance. A >>>> program activated in Richard's way will not list the new program. >>>> Perhaps >>>> one could devise a patch. But you have started on the journey to make >>>> a >>>> user into a programmer - this is not a good trip. >>> >>> Here's a thought. The OS knows when something is written into the file >>> system. If that thing being written is an executable program, the OS >>> could keep track of that location and make it visible via. the Start|all >>> programs thing you're referring to. To make things even simpler, the >>> entire bundle of files required by the application could look like a >>> single file to the OS, and could be copied, moved or deleted by the user >>> at any time by referring to a single entity in the file system. >> >>If you accumulate more of these thoughts, you will soon reinvent >>such things as system restore points, versioned directory tree clones >>with hard-linked common content, and containment of individual >>applications by virtual machines. > > Or, better yet, standalone programs with INI files. That was one of the µsoft "magic" solutions I was thinking of. That was the solution in the Windows 3.1 era wasn't it?
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2016-07-26 14:11 -0700 |
| Message-ID | <19d9d5e2-fd70-403d-bb15-c55751054999@googlegroups.com> |
| In reply to | #6827 |
On Tuesday, 26 July 2016 17:13:39 UTC+3, Osmium wrote: > "Wally W." wrote: > > > On Mon, 25 Jul 2016 18:55:22 +0000 (UTC), Kaz Kylheku wrote: > > > >>On 2016-07-25, Mark Storkamp <mstorkamp@yahoo.com> wrote: > >>> In article <dvl1b9F9qifU1@mid.individual.net>, > >>> "Osmium" <r124c4u102@comcast.net> wrote: > >>> > >>>> "Osmium" wrote: > >>>> > >>>> > I probably dislike Windows as much as Richard does. If we could > >>>> > revert to > >>>> > the pre-install era I would be willing to pay the price by doing a > >>>> > manual > >>>> > file association. But I am not at all sure that is the only change > >>>> > in > >>>> > practices that would be needed, it was just the most obvious one that > >>>> > occurred to me. Perhaps someone that has actually written official > >>>> > install/uninstall code could give more insight. > >>>> > >>>> I thought of another glitch when one bypasses the Windows install > >>>> routine. > >>>> > >>>> A program should be visible via. the Start|all programs ... little > >>>> dance. A > >>>> program activated in Richard's way will not list the new program. > >>>> Perhaps > >>>> one could devise a patch. But you have started on the journey to make > >>>> a > >>>> user into a programmer - this is not a good trip. > >>> > >>> Here's a thought. The OS knows when something is written into the file > >>> system. If that thing being written is an executable program, the OS > >>> could keep track of that location and make it visible via. the Start|all > >>> programs thing you're referring to. To make things even simpler, the > >>> entire bundle of files required by the application could look like a > >>> single file to the OS, and could be copied, moved or deleted by the user > >>> at any time by referring to a single entity in the file system. > >> > >>If you accumulate more of these thoughts, you will soon reinvent > >>such things as system restore points, versioned directory tree clones > >>with hard-linked common content, and containment of individual > >>applications by virtual machines. > > > > Or, better yet, standalone programs with INI files. > > That was one of the "Soft "magic" solutions I was thinking of. That was the > solution in the Windows 3.1 era wasn't it? Yes, in Windows 3.1 it worked. From Windows NT however the several users and permissions of those users and some idiotic measures against malware caused issues with it that it ceased to work on general case.
[toc] | [prev] | [next] | [standalone]
| From | Wally W. <ww84wa@aim.com> |
|---|---|
| Date | 2016-07-27 02:58 -0400 |
| Message-ID | <clmgpb9teca68v4dhfj8hqtp4j2lutam3i@4ax.com> |
| In reply to | #6827 |
On Tue, 26 Jul 2016 09:13:36 -0500, Osmium wrote: >"Wally W." wrote: > >> On Mon, 25 Jul 2016 18:55:22 +0000 (UTC), Kaz Kylheku wrote: >> >>>On 2016-07-25, Mark Storkamp <mstorkamp@yahoo.com> wrote: >>>> In article <dvl1b9F9qifU1@mid.individual.net>, >>>> "Osmium" <r124c4u102@comcast.net> wrote: >>>> >>>>> "Osmium" wrote: >>>>> >>>>> > I probably dislike Windows as much as Richard does. If we could >>>>> > revert to >>>>> > the pre-install era I would be willing to pay the price by doing a >>>>> > manual >>>>> > file association. But I am not at all sure that is the only change >>>>> > in >>>>> > practices that would be needed, it was just the most obvious one that >>>>> > occurred to me. Perhaps someone that has actually written official >>>>> > install/uninstall code could give more insight. >>>>> >>>>> I thought of another glitch when one bypasses the Windows install >>>>> routine. >>>>> >>>>> A program should be visible via. the Start|all programs ... little >>>>> dance. A >>>>> program activated in Richard's way will not list the new program. >>>>> Perhaps >>>>> one could devise a patch. But you have started on the journey to make >>>>> a >>>>> user into a programmer - this is not a good trip. >>>> >>>> Here's a thought. The OS knows when something is written into the file >>>> system. If that thing being written is an executable program, the OS >>>> could keep track of that location and make it visible via. the Start|all >>>> programs thing you're referring to. To make things even simpler, the >>>> entire bundle of files required by the application could look like a >>>> single file to the OS, and could be copied, moved or deleted by the user >>>> at any time by referring to a single entity in the file system. >>> >>>If you accumulate more of these thoughts, you will soon reinvent >>>such things as system restore points, versioned directory tree clones >>>with hard-linked common content, and containment of individual >>>applications by virtual machines. >> >> Or, better yet, standalone programs with INI files. > >That was one of the µsoft "magic" solutions I was thinking of. That was the >solution in the Windows 3.1 era wasn't it? Software still got intertwined with the OS in Win3.1. A beautiful thing about DOS: no matter how badly a program behaved, it never affected the OS. Rebooting returned to a pristine operating system. Not so with WinCrap of any version.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <349-534-5780@kylheku.com> |
|---|---|
| Date | 2016-07-27 13:47 +0000 |
| Message-ID | <20160727064327.332@kylheku.com> |
| In reply to | #6837 |
On 2016-07-27, Wally W <ww84wa@aim.com> wrote: > A beautiful thing about DOS: no matter how badly a program behaved, it > never affected the OS. Rebooting returned to a pristine operating > system. Nonsense; only if you inserted a pristine DOS boot floppy into drive A: and booted into that. There were, like, viruses on DOS. Remember those? How did they exist, if a badly behaved program couldn't affect the OS? The DOS install on your C: hard drive, or an not-write-protected floppy could be altered or completely trashed.
[toc] | [prev] | [next] | [standalone]
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
Back to top | Article view | comp.programming
csiph-web