If you drag a file over Windows Live Messenger‘s My Sharing Folders shell name space item, it would immediately interrupt dragging with an error message box, even if you never planned to drop onto this folder:

This should definitely be rather implemented a different way. If you ever tried to drag something using slow PC touchpad, you probably have an idea of how annoying such an interruption could be.

Windows Live Messenger was pre-installed. To disable shared folders feature, I wanted to find a proper setting in options, but it did not appear to be easy enough: Help button, Show the menu bar, Tools, Options, Sharing Folders on the left, oops! it was not helpful.

Going another way of finding DLL that hosts the shell extension revealed file named: C:\Program Files\Windows Live\Messenger\fsshext.8.5.1302.1018.dll. Once unregistered, the folder went away from the shell (process restart needed, typically logoff/logon):

C:\>regsvr32 /u "C:\Program Files\Windows Live\Messenger\fsshext.8.5.1302.1018.dll"

While new NTFS Links propery page is looking for contained junction points, it shows an animated picture to indicate opertation in progress. The picture is a stock resource and is taken from shell32.dll resource type “AVI” name 150. It is an Audio Video Interleave (AVI) file embedded into binary resources as is.

What is however interesting is that being saved as a file and double-clicked, it appeared to be crashing the player process. What might go wrong with a stock resource, is it FFDShow again? This was the first guess and yes, it was FFDShow again. This is a “video only” file with video encoded with MS-RLE compression, FOURCC ‘RLE ‘. Microsoft provides a VCM codec for the format through msrle32.dll.

However, as already discovered, FFDShow register itself under extremely high merit and for this reason is preferred as a video decoder and attempts to handle the decompression itself. But it fails, and miserably enough to crash the hosting process.

The registration under unfairly high merit defeats the purpose of DirectShow’s powerful Intelligent Connect approach. “Why do you need a video decoder? You have FFDShow Video Decoder, forget about the others. Oops, sorry, I don’t like your file.”

Is there any way to stop the villain? Of course, there is.

To start, I tried to disable the decoder through FFDShow Video Decoder native interface and give it a last chance. Video decoder offers decoding properties to choose from, and it looked as if it can stop serving as decoder for the mentioned video format.

Still with the disabled settings, it kept unsuccessful attempts to decode and process crashes. So another workaround, and it is in fact a proper one, which should be done from the start (and I would also prefer that it was done by FFDShow itself), is to lower decoder’s merit to a level at which it would honor specialized decoders so that Intelligent Connect could fall back to FFDShow in case there is no bettter alternative. MERIT_UNLIKELY seems to be a good one for this codec:

This fixes the issue by letting DirectShow choose stock video decoder for MS RLE video encoding.

While NTFS junction points are powerful to relink files without duplicating data and/or moving between disks, they are treated as regular directories by most of software and it may unexpectedly result in conversion of a junction point into a regular directory with implied duplication of data and disk space waste.

This is a quick fix for the NTFS Links shell extension that allows to quickly list created junction points under certain directory, and delete if necessary. The update adds a property page Junction Points to NTFS non-UNC directory properties:

This is a quick update, so be aware (also my TO DO list):

• no Russian localization, sorry
• context menu should also be given another item Open Containing Directory
• does not work for root directories
• list items should be OLE draggable
• there should be a junction point validation feature that checks availability of substitution path and indicates result by an icon
• I should remove the mess between “soft link” and”junction point” in favor of the latter

Release information:

• Updated Version: 1.1.3
• Download Link: AlaxInfoNtfsLinksSetup.msi (275K)

I have been frequently troubleshooting remote systems and otherwise provide various temporary binary files to remote production sites with fixes or beta versions of new features etc. The software  is such that that customer sites have specific combination of hardware, configuration, hardware on LAN, software conflicts and there is a number of things that are very much easier troubleshooted directly on the production server, through remote connection. Typically I am using TightVNC and Windows Remote Desktop, sometimes LogMeIn, RAdmin and more rare alternatives (among such I would like to specially note TeamViewer).

Obviously except for released versions of binaries (which also exist in several versions from different configuration builds), there appear a number of intermediate files, DLLs and EXEs which are addressed to specific problems and fixes. The problem with multitude of different versions of the same DLL is widely known as DLL hell.

It is not actually a big hell since we are trying to follow simple rules:

• DLLs should be backward compatible, or if the compatibility is ever broken, DLL version mismatch scenario should be handled as gracefully as possible
• DLLs and other binaries should have VERSIONINFO resource
• version information file version’s least significant number is incremented with each and every build; in particular this allows to keep privately program databases (PDB) and immediately find the corresponding database by file version
• newer binaries should always have greated file version than older ones

The problem however has been that the typical process of building a temporary build of a library and uploading it to remote location required too many clicks. Considering a number of times I have been through these operations, an automation and a productivity tool should have appeared long ago. Finally this is solved by a shell extension that compresses binaries into a transferrable archive in two clicks:

Compression formats of 7-Zip (.7z), 7-ZIP SFX (.exe) and ZIP (.zip) are at user’s choice.

Because of great number of versions it is very useful to have file version as a part of file name (actual binary name won’t have the version because typically DLL name does not change through versions and creating copies such as for example using hard links is possible but not quite convenient) in order to be able to locate a file and/or version of interest using file search.

The shell extension locates an installed copy of 7-Zip and uses its command line interface to create archives.

If a binary with VERSIONINFO resource is found among selected files (undefined behavior is multiple binaries selected), its name and version is used for archive name. If there is also a program database (.pdb) file selected, archive name will receive and additional suffix “-pdb”.

A partial Visual C++ .NET 2008 source code is available from SVN, release binary included [Win32, x64].