Nikon FDUtility
in [Scanners]
|
From: Marjolein Katsma on 24 Jan 2006 16:00 Don (phoney.email(a)yahoo.com) wrote in news:i0kct1hf9gapha8lcc8mftf2caievue8qd(a)4ax.com: > The trouble is most of them don't even try. They just use the original > log when the program was installed which is just not enough. Once more: standard installation software CANNOT do this. "Trying" doesn't come into it - it's *logically* impossible: the installation program cannot know *how* an application stores its data. The only alternative is to develop an (un)installer that contains much of the same logic as the actual application. No software developer will do that, since it would make the product far too expensive for very little added value. And they'd lose customers. > Windows bloat referrers not only to the Windows' directory but to the > installation as a whole. Sure. But that's totally irrelevant when we are talking about *user data*. The same application running on two or three different OSs will store the same amount of user data on each. > Bingo! And "bad programming" is where MS shines! ;o) MS also shines at good programming. MS is *BIG* and what one department does well, another department does extremely badly. I refuse to generalize about MS except by saying they're BIG. And MS doesn't develop installer utilities - so that statement is irrelevant, too. (They do provide a framework - but that's something else again: that's just to make writing installers easier (read: with higher-level logic).) > I know, and that's exactly the problem. The installer that comes with > various MS tools is appalling and that's just to package the > application in the first place, never mind the uninstall later! Installer and uninstaller are the same program, only in a different mode of operation. The quality of the installer depends on the quality of the generating tool, and the quality of the parameters provided to build the installer. What remains is that some things are *impossible* to know for an installer. Installers cannot know how an application operates or how or where it stores user data. >>The *application* knows where they are - the *installer* does not! An >>installer has absolutely no idea how a program functions or what it >>may store where. > > And that's exactly the problem! See alternative above. You wouldn't be complaining about uninstalling because you wouldn't be able to afford the program in the first place. ;) > I don't agree that would be a huge and expensive program. It's just a > question of standardization. LOL! >>it does *not* know how an application works or how an application >>stores its settings. > > Which can be standardized very easily. ROFL! Explain to me, please, how a dictionary, a GIS application, and a printer driver can be standardized so they all store their (user) data in the same format in the same way? Just for example? > I don't think so. Installers (as they are now) are not that > complicated to write. It's exactly that simplicity which is the > problem. They get very complicated very quickly. It's a specialized sort of software with endless decision trees of ifs and buts and elses that an application - once installed - doesn't need to worry about. But as I said - installers aren't "written" any more - they're generated with the help of tools that know how to take care of all these ifs and buts and elses. -- Marjolein Katsma *Help with HomeSite/Studio: http://hshelp.com/ *Travel blog: http://blog.iamback.com/ *Spam reporting addresses: http://banspam.javawoman.com/report3.html
From: Don on 25 Jan 2006 12:17 On 24 Jan 2006 21:00:19 GMT, Marjolein Katsma <nobody(a)example.net> wrote: >> The trouble is most of them don't even try. They just use the original >> log when the program was installed which is just not enough. > >Once more: standard installation software CANNOT do this. "Trying" >doesn't come into it - it's *logically* impossible: the installation >program cannot know *how* an application stores its data. Which is why standardization is needed to abstract the location of user *settings* (not *data*!) so installers know where it is. >> Bingo! And "bad programming" is where MS shines! ;o) > >MS also shines at good programming. MS is *BIG* and what one department >does well, another department does extremely badly. I refuse to >generalize about MS That's where we definitely differ. MS does things extremely badly and is forced kicking and screaming to make any improvements. As I said, their mentality is to develop what is the easiest for their programmers to do, second is to suffocate any inkling of competition, and 3rd... well, there is no third. Users don't enter into this equation at all. Why? Because MS is a monopoly. Just like IBM before them. And IBM behaved in exactly the same way. In any monopoly situation there are no users or customers, there are only hostages. >Explain to me, please, how a dictionary, a GIS application, and a >printer driver can be standardized so they all store their (user) data >in the same format in the same way? Just for example? I think you're missing what I'm saying. We are talking about user *settings* not generic user *data*. As in NikonScan *settings* not any images you may have scanned. In more generic terms, *everything* can be standardized. The question is only when you reach the case of diminishing returns. And due to the simplicity of Windows installers there is a long way to go before such a point is reached. In the most primitive/elementary form all that's needed is a single *standardized* registry entry to point to a directory where user settings are stored. Indeed, the same approach can even be used to also note where user data is stored should one be so inclined. Don.
From: Marjolein Katsma on 25 Jan 2006 15:58 Don (phoney.email(a)yahoo.com) wrote in news:fdcft1t8cbi67hqhkoqrvlm3eutsu3cotj(a)4ax.com: >>Explain to me, please, how a dictionary, a GIS application, and a >>printer driver can be standardized so they all store their (user) data >>in the same format in the same way? Just for example? > > I think you're missing what I'm saying. We are talking about user > *settings* not generic user *data*. As in NikonScan *settings* not any > images you may have scanned. Settings *are* user data. But let me rephrase: So explain to me how you would standardize how and where the settings for a dictionary, a GIS application, and a printer driver can be standardized so they all store their settings data in the same format in the same way? > In more generic terms, *everything* can be standardized. I think you're still missing my point. Both bikes and motor cars have steering mechanisms, as do boats. How would you standardize them? More to the point, why would you? Get it? > And due to the simplicity of Windows installers (...) Only very simple applications can have simple installers. For most non- trvial application installation is non-trivial either, and far from simple. > In the most primitive/elementary form all that's needed is a single > *standardized* registry entry to point to a directory where user > settings are stored. Indeed, the same approach can even be used to > also note where user data is stored should one be so inclined. Let's just stick to settings - as the locations for other user data can be endless, and (hopefully!) not fixed (and hence not possible to be registered); the most applications do is keep track of the last path(s) used. Settings must be stored somewhere - but why should it be a directory? Settings can be stored in the Registry as well. There are reasons for choosing one or the other - some applications even store settings in several places (often for good reasons). Then there's the matter of different users, each of which have their own settings, as well as default settings the application might want to keep track of so the user can restore to a known starting point. How would you standardize this? -- Marjolein Katsma *Help with HomeSite/Studio: http://hshelp.com/ *Travel blog: http://blog.iamback.com/ *Spam reporting addresses: http://banspam.javawoman.com/report3.html
From: Don on 26 Jan 2006 09:40 On 25 Jan 2006 20:58:59 GMT, Marjolein Katsma <nobody(a)example.net> wrote: >>>Explain to me, please, how a dictionary, a GIS application, and a >>>printer driver can be standardized so they all store their (user) data >>>in the same format in the same way? Just for example? >> >> I think you're missing what I'm saying. We are talking about user >> *settings* not generic user *data*. As in NikonScan *settings* not any >> images you may have scanned. > >Settings *are* user data. But let me rephrase: > >So explain to me how you would standardize how and where the settings >for a dictionary, a GIS application, and a printer driver can be >standardized so they all store their settings data in the same format in >the same way? There are literally dozens of ways to reconcile heterogeneous data. Let's take the latest fad: XML for starters! I'm not a big fan because it has it's own many problems. But all that is a distraction... The important point is this: Forget MS, forget everything and ask yourself: What does a user want from an (un)installer? The answer is, an automatic install so the user doesn't have to copy any files manually or twiddle any OS settings (e.g. add registry entries by hand). Then, when the time comes to uninstall, automatic removal of all files *including* any files the program has generated because it needs them to operate! That does not include user *data*, of course, but it does include user *settings*, temp files, OS settings, etc. Conceptually and physically those settings are a part of the program and you don't want them lingering on after uninstalling. What good are those settings or temp files (the preview) etc. after you uninstall the program? You want them gone! In short, an uninstaller should *fully* restore to "status quo ante", (not a *partial* restore with bits left all over the place). Only when everything program-related is removed can that be called a clean uninstall. Everything else is a mess. >> In more generic terms, *everything* can be standardized. > >I think you're still missing my point. Both bikes and motor cars have >steering mechanisms, as do boats. How would you standardize them? More >to the point, why would you? Get it? Yes, but you didn't get it, because you missed the very next sentence which is key: On Wed, 25 Jan 2006 18:17:09 +0100, Don <phoney.email(a)yahoo.com> wrote: >The question is only when you reach the case of diminishing returns. So, of course, you can standardize all those steering mechanisms but that would be "solving" a non-existent problem and would be counter productive because it would only create inconveniences without getting much back. Which is another way of saying "diminishing returns". By contrast, removing all program related files (whether they existed at the time of initial installation or not) is meaningful and a real problem especially if you don't know where they all are? And, to get specific again, NikonScan sprinkles them all over the place. Not necessary Nikon's fault, it's just the way Windows works. Which gets us back to poor MS programming! >> In the most primitive/elementary form all that's needed is a single >> *standardized* registry entry to point to a directory where user >> settings are stored. Indeed, the same approach can even be used to >> also note where user data is stored should one be so inclined. > >Let's just stick to settings - as the locations for other user data can >be endless, and (hopefully!) not fixed (and hence not possible to be >registered); the most applications do is keep track of the last path(s) >used. Which is why I said at the beginning that (at the very least) an uninstaller should be able to delete any settings in the program's default location and the last user-selected location. >Settings must be stored somewhere - but why should it be a directory? >Settings can be stored in the Registry as well. There are reasons for >choosing one or the other - some applications even store settings in >several places (often for good reasons). Then there's the matter of >different users, each of which have their own settings, as well as >default settings the application might want to keep track of so the user >can restore to a known starting point. How would you standardize this? The program and the OS need discipline. That's what standardization is all about! Standardization means: Instead of a free for all, both the program and the OS agree to observe certain established rules so they can work together. For example, abstracting a directory (via indirection) for user settings instead of hard-coding it. Etc. Windows has traditionally had very little discipline. That's why there are so many problems even when MS tries to retrofit discipline. And also why MS programmers are anything but good. The fact that there are so many *uncontrolled* places to store all those settings is a prime example of all of that. It's also a prime example of sloppy OS design. And so on... Don.
From: Marjolein Katsma on 26 Jan 2006 11:07
Don (phoney.email(a)yahoo.com) wrote in news:senht1homrov9slq8m1v6f7cn8717imejb(a)4ax.com: >>So explain to me how you would standardize how and where the settings >>for a dictionary, a GIS application, and a printer driver can be >>standardized so they all store their settings data in the same format >>in the same way? > > There are literally dozens of ways to reconcile heterogeneous data. > Let's take the latest fad: XML for starters! XML is no better or worse than .ini files or Registry entries (well, maybe a little better in some respects, and owrse in others ;)) - what matters is *semantics* of the data. XML doesn't solve anything in that respect. The problem with standardizing is in the kinds and types of data necessary: semantics. This is a BIG problem. And once you have (theoretically only, since it's not even feasible) standardized the types of data needed for all existing apps, a new one comes along that needs different data yet again. What do we need: a world- wide repository of user settings semantics? Accessible over the Internet? What if a computer user doesn't have Internet access? > What does a user want from an (un)installer? 1. Easy installation with enough choices to let an installation adapt to *my* system rather than adapt my system to an installer (that means both a "standard" instaland a "custom" install, at least. 2. Uninstallation of everything that was *installed* 3. Tell me about any user data left in directories create by the installer or subdirectories of that Given that, it's 1) The application's responsibility to store any settings that are not directly editable by the user in the Registry *below* a branch that was created by the installer - so an uninstaller is able to remove those 2) The application's responsibility to store any settings that *are* directly editable by the user in the file system *in* or *below* the application's installation directory, or in a standard "Application data" subdirectory - so the installer can warn the user not all data have been removed (OR use a single .ini file in the %windows% directory created at install time so the uninstaller can find it - but this is deprecated, not least because it doen't handle different settings for different users) 3) The *users* resposibility to take care of any user data stored in a location *they* decided in the first place - no uninstaller can know about those and no installer should touch them anyway BUT that ignores the multi-user situation - which makes the simplified 1- 2-3 lists above a whole lot more complicated. > The answer is, an automatic install so the user doesn't have to copy > any files manually or twiddle any OS settings (e.g. add registry > entries by hand). > > Then, when the time comes to uninstall, automatic removal of all > files *including* any files the program has generated because it needs > them to operate! That does not include user *data*, of course, but it > does include user *settings*, temp files, OS settings, etc. A user may *want* that - but I've already explained that it's just not possible. Maybe I should say, only naive users want that - users who understand a little how applications and the OS they're running on work will not wish for the impossible - and will not be prepared to pay the price of a dedicated uninstaller which duplicates half the program's logic. > Conceptually and physically those settings are a part of the program > and you don't want them lingering on after uninstalling. What good are > those settings or temp files (the preview) etc. after you uninstall > the program? You want them gone! They're NOT part of the program. Very often, I *don't* want them uninstalled, so a newer version of the software can use them (directly, or by importing them). Temporary files are the user's responsibility anyway - who decides *how long* they should be kept? Only the user. > In short, an uninstaller should *fully* restore to "status quo ante", > (not a *partial* restore with bits left all over the place). It should bloody NOT! An uninstaller that does that to me will mean I will never, ever even consider another version of that software, unless I'm reassured it's bettered its life. An uninstaller should NOT touch *my* data (or at most ask me friendly whether to remove what it knows how to find). Anything else is just not well-behaved. Sure, remove the *program* and anything it needs to start up. But do NOT touch ANY data. > By contrast, removing all program related files (whether they existed > at the time of initial installation or not) is meaningful No, it's impolite, to say the least. Hands off MY data! And not feasible anyway. Your "just standardize" completely misses the reality of an infinite set of semantics to describe all those data. See above. > And, to get specific again, NikonScan sprinkles them all over the > place. Such as where? > Not necessary Nikon's fault, it's just the way Windows works. Which > gets us back to poor MS programming! No, it's not "just the way windows works". Where data are stored depends on two things: the application (its own data) and the user's choice (user data). An application that deosn't allow a user to choose where to store their data is badly programmed. Nothing to do with how Windows works, Windows makes these choices possible for responsible programmers. > Which is why I said at the beginning that (at the very least) an > uninstaller should be able to delete any settings in the program's > default location and the last user-selected location. Of course, we only need to "just standardize" how the last user-selected location of all the possible somethings for all possible users are recorded. For all possible applications used anywhere on the world. > Standardization means: Instead of a free for all, both the > program and the OS agree to observe certain established rules so they > can work together. And don't forget those semantics. ;-) They come before establishing rules. See above. > Windows has traditionally had very little discipline. In the sense that Windows is an application, yes; it's a tad sloppy - but that is mostly because of backwards-compatibility with original bad choices. In the sense that Windows does not *enforce* any specific locations for anything, true as well. Both of these apply equally to *nix though. Mac OS is only partly an exception in that OS X is built on top of *nix and you can do all *nix things in it, as well. (Conveniently ignoring other OSs for a moment.) > That's why there are so many problems even when MS tries to retrofit > discipline. Do they try that? Try to retrofit dicsipline? Only in the sense that some deprecated (and insecure) approaches are no longer possible (such as direct access to hardware). Otherwise backwards compatibility rules, which has its disadvantages but huge advantages as well. The real responsibility is with application programmers; an OS only provides a framework to make responsible applications happen. > And also why MS programmers are anything but good. Some MS programmers are *very* good. I've said it before: MS is BIG. Then again, some MS programmers are indeed bad. > The fact that there are so many *uncontrolled* places to store all > those settings is a prime example of all of that. It's a result of flexibility. ;) > It's also a prime example of sloppy OS design. No - where settings and user data are stored is not a result of whatever kind of OS design, merely of programmer and user choice. I intensily dislike any application that *doesn't* give me a choice where to store my data (including my settings). Most programs that don't won't ever make it past trial install and are quickly removed. Especially a program that insists on storing user data (as opposed to settings here) below the installation directory: I keep a strict separation between programs and my data, they go on different physical drives. It's MY system, after all. *I* decide what goes where. A program that doesn't respect that doesn't deserve my respect. .... Enough of that, I've explained enough now. If you still don't get it, I give up. So, tell me: what are all those places where Nikon Scan stores data during operation (i.e., after installation)? Places that weren't set or accepted by you in the first place? -- Marjolein Katsma *Help with HomeSite/Studio: http://hshelp.com/ *Travel blog: http://blog.iamback.com/ *Spam reporting addresses: http://banspam.javawoman.com/report3.html |