DataStore.edb and Windows Vista

This here is not so much an instruction, but a use case.

So I got me to look at a Windows Vista system that has been running for quite a long time. With just 1 (one) gigabyte of RAM.

At every operating system start, it would search for updates and the hard disk would thrash alot.

With Resource Monitor I discovered that the oft-accessed file was DataStore.edb, located at
%WINDIR%\SoftwareDistribution\DataStore\

DataStore.edb had ballooned to was the size of 325 MB.

The file is a log file in database format listing the history of all updates installed to the system, and also includes the current status of updates waiting to install.

Now, the typical solution^{[Yes, Citation needed]} to this that I had been looking at on the interwebs has been to create a backup of this file and then delete it. After that, Windows Update won't list the history of all updates installed to the system, and that would be that. < Well, there's more than that :>

Before manipulating DataStore.edb, turn off the Windows Update service, because when that service is active, the DataStore file is in use.

esentutl

For a short while I thought that defagmenting this one file with a command-line tool called esentutl would be the solution, so I wanted to go on with it. The catch was that the tool would not be able to copy the defragmented file to its original location and yielding an error about it, saying that the defragmented TEMP file could still manually be taken to its original location, with the original file replaced. I didn't do it and left it at that.

By the way, the esentutl tool does not list where the .TMP file is located. I eventually found out that it was at the main user data folder of a logged-in user:
C:\Users\username

For a long time I couldn't put my finger on what it was that was not working, and then a month or two later it turned out that I had not been running the esentutl command in Administrator mode.

The full command for defragmenting the file went on like this:
esentutl /d %windir%\SoftwareDistribution\DataStore\DataStore.edb

So I launched Command Prompt as Administrator and the tool did its job as expected. So that was that.

But checking for updates in Windows Update took a lot of time anyway, and the hard disk still kept thrashing when checking for updates.

What happens when removing datastore.edb

Note that you will still have to back up the file, just in case...

Well, Windows Update then knows no history of previous updates and takes a lot of time to check for them. Maybe an hour. Or so, because I assume it will check updates file-by-file for nearly all present Microsoft software. Before, when the still-large datastore.edb file was there, it seemed that the check for updates actually took much, much less time. Since I didn't measure the actual minutes and did not compare, then I can't tell with any reliable numbers as to what the effect was with regards to differences in update checking times.

Anyways, after installing the updates, DataStore.edb was recreated and sported about the same size as before (over 315 MB). So, there is really no point in deleting the file.

Worse is, that there doesn't seem to be any built-in way to merge two separate DataStore.edb files into one cohesive database, if the older database were absent for a short while and another one created anew.

Then I just moved the recently backed-up datastore.edb back, and checking for updates in Windows Update took about ten minutes, including a reasonably minor database refresh on account of the May updates installed in the interim, which was not reflected there.

To avoid Windows Update thrashing the hard drive anyway, it's then best not to have the Windows Update service run with such a low RAM count at all (1 GB); perhaps with the exception of every second Tuesday each month.

So much for now.

28.04.2014 update:

I don't have that Vista computer at hand, or any other Vista computer in any useful proximity, so it's impossible to tell with precision where to optimize wrt Windows Update.

Point being that it's possible to keep Windows Update from checking updates at every startup by making changes in scheduling.

• I remember there being a scheduler snap-in module in Windows Management Console, which feature-wise in Windows Vista replaced the Scheduled Tasks folder in Windows xp. The Task Scheduler snap-in is alot more complex and allows very granular configuration options.
• Turning off automatic updates is useful for very experienced users. If the computer has behaved well, then I've usually set the Windows Update service to delayed start. Attempt this at your own risk. Even if the risk is low, it doesn't account for unintended behaviour, especially when making large updates, such as upgrades to Windows service packs.

I also hazily remember a separate update not advertised on Windows Update itself, that also must have improved the situation, if only a bit. The overall result was that the DataStore file was touched only when I launched the Windows Update program.

27.01.2016 update:

I recently got my hands on a snappy Windows 7 machine with 4 Gb of RAM.

After making a large number of updates through Windows Update, one of the recent updates was KB3102810 (installed on 18.01.2016). While it apparently does not directly concern the use of the DataStore file, I noticed some performance improvement after applying that update.

12.11.2016 update:

A comment from a linkback contains more information about the innards of datastore.edb.

Installing NoScript to Mozilla in Windows Vista

This blog post describes how to install NoScript to Mozilla Application Suite in Windows Vista.
In all actuality, this should also apply to other compatible Mozilla extensions.

Conditions:

• Windows Vista SP2
• Mozilla Application Suite 1.7.13 (released 21.04.2006)
• NoScript 1.1.4.7

To install NoScript in an account with administrator rights,

• you must run Mozilla as administrator.
  For how to properly install NoScript in a guest account, see below.

  Attempting to install in any other way won't work. Yes, I've tried it myself before I found the solution.

• I chose NoScript 1.1.4.7, because it's the last version for Firefox 1.0.x.

  The reason is that Firefox 1.0.8 uses version 1.7.13 of the Gecko layout engine, which also matches the last version of Mozilla Application Suite. Any newer version might be incompatible, and I haven't tested NoScript 1.10, which is the last version for SeaMonkey 1.1.

• Since Mozilla 1.7.13 is eight years old and does not support modern web standards, installing any extension from addons.mozilla.org requires more steps:
  To download version 1.1.4.7 of NoScript from addons.mozilla.org,
  • go to its version section there and hover over the 1.1.4.7 section so that the Download Now link which looks like a button becomes visible.
  • Right-click on the Download Now link, choose to "Save Link Target As..." from the context menu, then save the extension into a folder of your choice. The Mozilla extension is saved with the .xpi file extension (but not installed.)
  • 01.03.2014 update:
    If that does not work (because of design changes at a.m.o), go instead to Mozilla's relevant addons folder for NoScript at ftp://ftp.mozilla.org/pub/addons/722/, and scroll down to the chosen version.

    Firefox addons developers, either by tradition and culture or requirements from a.m.o, append their addons' XPI files with product acronyms as markers of compatibility with a client program in such a way that amongst browsers, fx stands for Firefox, sm for SeaMonkey, and mz for Mozilla. This should inform users of older client versions as to which extension version is still compatible.
    
    As I skimmed over Mozilla's NoScript FTP folder with above knowledge, I noticed that the most recent NoScript version marked with mz is actually 1.8.2.1. I don't remember having tested that version with Mozilla in Windows Vista before, but I hope other adventurous users might be lucky. Maybe in the future I will get to test that version, too.

  • in Mozilla, browse to the on-disk location of the saved extension, and click on it to install. The filename should be noscript-1.1.4.7-fx+mz+sm+fl.xpi
• Given the circumstances, always install NoScript and any other extension into the user profile and not the general installation folder, because it may be rather difficult to remove it afterwards.
• Once the extension reports it's installed, exit Mozilla.
• Then start Mozilla again as Administrator to finish the install process, then exit Mozilla again.
• Start Mozilla normally.

Added L., 01.03.2014.:

Installing NoScript in a normal/guest account.

Now, in a normal or guest account, it needs more work, mainly because of the differing designs of Windows Vista and Mozilla. We should remember that Mozilla 1.7.13 was made to run in Windows 95...

It won't be necessary to run Mozilla as administrator, because it will launch the instance with administrator credentials, which then brings its own settings as set in the administrator account.

Installing NoScript into Mozilla in a non-admin account mostly follows the steps of installing in the user profile space. After that, restarting Mozilla fails with this error:

"The program must close to allow a previous installation attempt to complete. Please restart."

The result in the background is that Mozilla starts, and starts xpicleanup.exe.

The following is an assumption: xpicleanup.exe wants to delete xpicleanup.dat, and unlike in Windows xp and older, the latter file is placed not where xpicleanup.exe anticipates it to be. xpicleanup.exe then fails to delete the file, Mozilla exits, and renders xpicleanup.exe an orphan process, hanging in memory. Trying to start Mozilla several times leaves more instances of xpicleanup.exe in memory. These processes must be ended either from Task Manager or Process Explorer.

Finding xpicleanup.dat within your profile, deleting or renaming it to xpicleanup.bak does the trick, and Mozilla will start again, with NoScript installed and functioning. (I usually rename such files as filename.ext.bak in order to preserve its extension, might I ever need the original and now renamed file again.)

xpicleanup.dat for a normal/Guest account (yours might be named differently) is located at —

C:\Users\Guest\AppData\Local\VirtualStore\Program Files\mozilla.org\Mozilla\

^ to browse there, enable viewing of hidden files at folder options (Alt or F10 > Menu > Tools > Folder Options)

Useful instructions from a post by Alice at MozillaZine Forums.

---

A little bit of background information and history

Mozilla Application Suite (Mozilla) was not designed with Windows Vista in mind, so using it in a modern operating system is not without obstacles. Yes, it does run, but this post about installing extensions sort of shows where some of the caveats lie.

Mozilla was at the time the open source base for Netscape, and version 1.0 of Mozilla was released on 05.06.2002, which is roughly 11 years ago as of 2013. I mean, wow, eleven years. Anyways, Mozilla was released to a wide variety of operating systems and for just as wide a variety of versions of each, including Windows 95, Windows 98, Windows 98 SE, Windows Me, Windows 2000 (released 17.02.2000) and Windows XP (itself released on 25.10.2001).

After version 1.0, Mozilla progressed to have quick developments over its lifetime by getting new features added, but not too much by way of changes to its baseline architecture.

	Longevity
Mozilla's penultimate 1.7.13 version came out on 21.04.2006, just five and a half months before the RTM version of Windows Vista was finalized on 08.11.2006. Windows Vista was released to general availability on 30.01.2007.	Mozilla 1.7 Alpha is dated 23.02.2004, and 1.7 itself came out on 17.06.2004, so there is two years and about two months of time between 1.7 Alpha and 1.7.13, and exactly two years between 1.7 RC1 (21.04.2004) and 1.7.13.
After mozilla.org ceased development of Mozilla Application Suite, another team took over development and renamed the project SeaMonkey. Windows Vista was not released yet by the time SeaMonkey 1.0 arrived on 30.01.2006, but beta versions of Vista had to have been available already.
SeaMonkey 1.1.xx (18.01.2007 and on) was thereafter developed to accommodate Windows Vista, with SeaMonkey 1.1.19 (16.03.2010) being the last version of the 1.1 line, and the last for Windows 98/Me. Note that Windows 7 was released on 22.10.2009, so there's a great possibility that SeaMonkey 1.1.19 should run well on that operating system, too.	Three years and nearly two months between SeaMonkey 1.1 and 1.1.19. Overall, if I discount layout engine changes, then Mozilla and SeaMonkey are essentially the same product and programmatically the same infrastructure. When taking into account the release dates of Mozilla 0.8/0.8.1 (14.02.–26.03.2001), when it finally became reasonably stable and usable, and SeaMonkey 1.1.19 (16.03.2010), then that whole architecture has lasted for about nine years. Ten when factoring in development time, but that's a stretch considering official titles. If I were, on the other hand, to also consider Classilla, a browser for Mac OS 9, and the latest version of which was released on 19.10.2012, then all in all, Mozilla's run could certainly be timed to ten years from Mozilla 1.0, eleven years from Mozilla 0.9.5 (12.10.2001), and almost twelve years since Netscape 6 (06.12.2000). Such a long lifetime for one branch of development is a testament to its quality and reliability over a long span of time.

Future

The reason to have NoScript in Mozilla is that the browser is just so old and can easily crash with a piece of JavaScript newer than what Mozilla can support. It should be of relevant help that the post that follows this one, is a tutorial on installing extension uninstallers in Mozilla and SeaMonkey.

Updates information not visible in Windows Vista

So here's a scenario: When using Windows Update in Windows Vista, and the Windows Update front page shows an x number of critical updates and an x number of regular updates, and you click on either of them, the detailed updates listing is all blank; a user doesn't know then which updates should he choose (or not) to download and install.

The specimen in question was Windows Vista Home Basic Service Pack 2 in a Dell Studio 1535 notebook.

I tried and searched for many solutions, and somehow got the thing to work normally again, but I can't exactly put a finger on what it is that I did, partly because I was too lazy to restart after every move or document too diligently. #tired

Assuming everything else is more or less in order, then —

Services started in-between:
1. COM+ System Application, but didn't set it to start automatically.
2. Microsoft .NET Framework NGEN v2.0.50727_X86 (Delayed Start).

I had read somewhere that in Windows Vista, Windows Update for some reason required .NET Framework 2.0 to run.
So, if memory serves me correctly, I did install it one day, but at the time it didn't yield the required effect and I had to let it be...

And yes, there were regsvr32 things started and re-started from the command line, but that didn't quite help.

After a few hours of searching for a solution, with many a discussion thread suggesting starting and stopping services, registering and unregistering system files, I stumbled upon a set of suggestions that matched the conditions that I had. See the forum thread here.

Since there was a match in error conditions registering Windows Update files, I was confident about the solution as much as the tech guys were on the forum.

So the solution was to run

SFC /scannow

in a Command Prompt window run as Administrator. If you decide to do the same, then beforehand, create a system restore point or rely on a very recent one, for example one made just a few days ago.

SFC is the System File Checker command-line tool and its variant in modern Windows versions checks protected Windows system files against tampering and replaces those it that appear to be wrong.

I ran the tool, it took its while, but then it finished.
I also got to check out its logs (requires administrator mode to view in WordPad) and separated the most recent check into a new file for the sake of posterity. I couldn't see any substantial errors when changing files over, but there was a lot of movement going on.

Then did a restart, and lo and behold, details about individual updates in Windows Update were visible again! Yay!

Fun about Windows

The Guardian's Charlie Brooker:

“Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it.”

Source: Microsoft's grinning robots or the Brotherhood of the Mac. Which is worse?

ID-kaart ja Mozilla Firefox

Kuna ma väga palju ID-kaardi dokumentatsiooni lugenud pole, siis alles hiljuti selgus, et edukaks sisselogimiseks Internetipanka tuleb ID-kaart lugejasse pista veel enne lehitseja avamist.

Asja tuum seisneb nimelt selles, et inimese ID-kaardi sertifikaadid loetakse sisse veebilehitseja avamisel. Kui ID-kaart sisestada juba olemasoleva veebilehitseja sessiooni ajal, siis sertifikaate automaatselt sisse ei loeta. Imelik värk.

Selline olukord tekkis Mozilla Firefox 3.0.19-s Windows Vista SP2 all, kuid ei välista ka, et sama olukord on ka mujal (teistes modernsetes Windowsites ja Firefoxi versioonides. Teistsuguste lehitsejate ja opsüsteemidega ei tea veel). Kaardilugejaks oli OmniKey CardMan 1021.

Quick: Windows Vista, XP and 4 Gb of RAM and performance

Best explanations:
http://makfu.wordpress.com/2007/08/09/okay-one-more-time/

More here:
4sysops.com: Why Windows Vista only sees 3Gb [of] memory in a PC with 4Gb [of] RAM and how [Windows] Vista SP1 fools its users

What to tweak and what not to tweak on Windows XP/Vista:
Lifehacker: Debunking common Windows performance tweaking myths

Windows Vista Service Pack 2 improvement and caveats

When looking through all the Blogger posts about the release of Windows Vista SP2, I noticed that they regurgitated all of that information that has been provided on major sources anyway. How unimaginative.

Some stuff with issues has already seeped in.

For other stuff related to Windows Vista and ThinkPads, here's a relevant Google search.

Things to do

The Microsoft TechNet resource page on wVista SP2 is the best place to start, because it has all the information at a user's fingertips.

Avoiding automatic updating to SP2

The resource page features specific download links and a Service Pack Blocker Tool. The latter is useful if a user wants in due course to make a specific wVista computer ready for SP2 deployment by first getting all the necessary drivers and software updated. The postponement entails blocking automatic download and install of SP2 via Windows Update, in a similar manner to Internet Explorer 8 Blocker Tool.

Predeployment work is very important

Before performing the update process itself, I did alot of predeployment work beforehand on a ThinkPad R60e.

Users are recommended to download and run the System Update Readiness Tool to see if there are any inconsistencies.

Doing all this work is laboriously recommended by Microsoft itself. It's best to wade through all of the article, so as not to miss important tips.

Unable to change HTML and HTM file icons

I found the solution at MozillaZine Forums.

I didn't do all of the things that were described in the second instruction set, as I only had to go as far as delete the IconHandler key from the registry, re-access the Tools > Folder Options > File types dialog and click OK for both file types, after which the filetypes' correct icon finally appeared.

Multiple instances of Skype in Windows Vista

Multiple instances of Skype 3.x in Windows Vista won't work because of different Runas behaviour. Skype 4 fixes that issue in version 4, which is in beta, using the /secondary command.

For Skype 3.x, some of the runas functionality does work, when the user specified is not part of an Administrators group, but rather that of Power Users.

More in-depth information here.

L., 04.04.2008. Update:
Skype 4.0 has now been released and it does indeed support the /secondary command when using the Runas command:

runas /user:Mart "\"C:\Program Files\Skype\Phone\Skype.exe\" /secondary"

Note that nested quotes (quotes inside quotes) must be escaped with a backslash, as seen above.

gimp-win-remote and Windows Vista

In Windows Vista, opening a file in the same instance of GIMP (2.4.6 is currently the latest) appears to be much trickier than in Windows XP (well, I have yet to try that out there..).

R., 28.09.2012. update:

Turns out that it can be just as tricky on Windows XP, so the same solution applies.

First off, I used to try opening a file through the Open With... command, but that didn't work, because it yielded an error message. Nevertheless, the program was added to the registry and the Open With list, so it was easier to tweak it after that.

To access the Windows Registry, click the Windows button and then the Run... command, type regedit, press Enter, give permission to continue. You can also launch Regedit from the Command Prompt; the principle is the same.

The key that you need to navigate to is

HKEY_CLASSES_ROOT\Applications\gimp-win-remote.exe\shell\open\command

The (Default) string in the right-side view of the key's contents already has the non-working command in it (the format of which usually works with most other apps to open files). Double-click (Default) to modify, and then between the app path and "%1" add with quotes and separate with one space on either size:

"gimp-2.4.exe"

The resulting command should look like this:

"C:\Program Files\GIMP-2.0\bin\gimp-win-remote.exe" "gimp-2.4.exe" "%1"

Click OK, quit the Registry Editor, and now try opening an image file with gimp-win-remote, if an instance of GIMP is open already.

I got the tip from here.

R., 28.09.2012. update

In addition, here's a registry solution to change the gimp-win-remote.exe program name in the Open With list (both in the shortcut menu and the dialog) to something less cryptic, once you're already using the registry to resolve the above situation.

(I tried this out in Windows XP, and I don't know if it will work the same in Windows Vista.)

Move up to

HKEY_CLASSES_ROOT\Applications\gimp-win-remote.exe\shell\open\

— and create a FriendlyAppName string in it:

right-click in empty space of the right pane for the shortcut menu,
choose New > String Value, then write FriendlyAppName for the new value.

Now, that's only a parameter. To change it, double-click on it or press the Enter/Return key for it and write the friendly app name.

Because the Open With dialog sorts programs alphabetically, then GIMP and GNU Image Manipulation Program will appear near the top of the list. The GIMP, which sounds cooler, will then be near the bottom of the list, and reaching it when choosing a program to open a file may require scrolling (at least for the first time). In any way, GIMP 2.6 should already allow adding the Edit with GIMP command to an image file's context menu upon installation or when editing preferences.

In a computer that is used by an average user who understands English, I chose GNU Image Manipulation Program (GIMP) as the friendly app name.

The simple reason was the the long name is self-explanatory and (GIMP) in parentheses is there for future name recognition.