Tuesday, December 11, 2007

Visual SourceSafe 2005 Update is available

Today Microsoft released the GDR/Update build (kind of ServicePack 1) for SourceSafe 2005.

The update targets improving the compatibility with VisualStudio 2008, Windows Vista and fixes a couple of bugs affecting performance, stability and reliability (most important, IMHO), plus a few customer annoyances.

You can download the update from this Visual SourceSafe 2005 Update MSDN page. If you're running Visual SourceSafe 2005, it is strongly recommended to upgrade your build.

Richard Berg maintains in his blog a more detailed list of the bugs fixed.

Sunday, October 14, 2007

Fixing the red menu_HelpPopup_reportertoolmenu error in Netscape Navigator

A friend told me today his Netscape Navigator is screwed. The main window showed in the bottom a red error message <menuitem id="menu_HelpPopup_reportertoolmenu"

menu_HelpPopup_reportertoolmenu

I was about to tell him to disable his Navigator Add-Ons, when Netscape downloaded and upgraded my Navigator from build 9.0b3 to 9.0rc1, and I started seeing the same problem.

I searched a bit the net and found out the menu_HelpPopUp_reportertoolmenu is related to a Reporter add-on that ships with SeaMonkey (who came up with this name anyway?!). The Website Reporter Tool [Help-->Report Broken Web Site] that is used by Netscape and Firefox does not select correctly its language sometimes and cause this error to appear.

There were a couple of solutions proposed:
- delete a file chrome.cdf in your profile (more info)
- switch to another language and back (more info)
- uninstall the extension (more info) either by manually messing with the same chrome.cdf or using Chrome Manager

None of the proposed solutions worked for me (I don't have a chrome.cdf file in my profile or at least I didn't find it, I have no idea how to switch languages or at least what I've tried had no effect, I had no add-ons installed for Netscape that I could uninstall, and the Chrome Manager part of Mnenhy installed but was hanging up on opening the manager window).

What worked eventually for me was:
- Close Netscape Navigator
- Go to C:\Program Files\Netscape\Navigator 9\chrome folder (or the Chrome subfolder of your Navigator install folder)
- Locate 2 files reporter.jar and Reporter.manifest and delete them
- Restart Netscape Navigator and the red <menuitem id="menu_HelpPoppp_reportertoolmenu" error message should be now gone.

Saturday, October 6, 2007

"Service CyberLink Background Capture Service (CBCS) hung on starting" and slow Vista logon on HP tx1000

A couple of days ago I bought a HP tx1000 laptop, and I noticed something weird: everytime I was logging on to Vista the screen become black, and the computer appeared to do nothing for a very long period of time; eventually the desktop appeared and things got back to normal.

I knew something was wrong and I was planning to run eventually some monitoring software to track this down. Fortunately, it was not necessary: Vista came to rescue. When I woke today the laptop from sleep the "Problem Reports and Solutions" dialog popped up, asking to send Microsoft a "Service hung report" for a "ClCapSvc" program. I had 7 of these reports to send, so I set to investigate further.

Service CyberLink Background Capture Service (CBCS) hung on starting

I looked in EventViewer, and the error there was reported as:
"The CyberLink Background Capture Service (CBCS) service is marked as an interactive service. However, the system is configured to not allow interactive services. This service may not function properly."

The service was registered in Services as:
    CyberLink Background Capture Service (CBCS)
Provides background buffering, recording and burning functionality for CyberLink Capturing
"C:\Program Files\HP\QuickPlay\Kernel\TV\CLCapSvc.exe"


I also noticed another related service, that was failing, too:
    CyberLink Task Scheduler (CTS)
Enables a user to configure and schedule a automated task for CyberLink Scheduling
"C:\Program Files\HP\QuickPlay\Kernel\TV\CLSched.exe"


So, the mystery was solved.
For me the service was installed as part of HP QuickPlay application, and it's used most likely for recording TV shows (and the other service for scheduling TV shows to be recorded as specific times). It's unclear to me why these services were intalled and automatically started, as I don't even have a TV tuner card!

It looks like the service comes with other software like Cyberlink PowerCinema, that was probably licensed by HP and repackaged into QuickPlay. Other users had similar problems... http://www.vistax64.com/vista-hardware-devices/78245-cyberlink-background-capture-service.html.

Solution 1: Disable the service. In Start menu, type and run Computer Management, select the Services node in the tree, and in the right pane select "CyberLink Background Capture Service (CBCS)". Right click the service, use Properties dialog to set the service to Disabled (Setting to Manual doesn't help, as during the boot some other crappy application will attempt to use the service causing it to start again). Ok the Properties dialog and repeat the procedure for the second service, CyberLink Task Scheduler (CTS).

Solution 2: The version of the CLCapSvc.exe file on my machine was 5.0.2510, and it was part of Hp QuickPlay 3.2. HP offers on its website an updated version of the program, HP QuickPlay Web Update 3.20A. Uninstalling the old version and installing the new one upgraded the file to version 5.0.2819, which doesn't seem to hangup on boot.

Since I don't need TV capture, I choose to apply both solutions...

Friday, September 28, 2007

Translation engines

Microsoft has recently released an update to its search engine. Aside from the advertised improvements I was pleased to discover the addition of a translator tool as an alternative to Google Translate; it also has a URL that for me seems easier to remeber.

I've played a bit with French-English translation and to me the Live Translator seems better than Google's version.
For other languages, Google wins (e.g. try translating with both engines from Chinese "用部落格分享照片、影音、趣味小工具和最愛清單,盡情秀出你自己" describing Windows Live Spaces :-))

The translation of a webpage is really interesting. I like the side-by-side comparison, with phrase hightlighting. See for instance the translation of CNN's home page.



For me it's not going to be an immediate bye-bye Google, but from now on I'll check both engines when I'll need a translation...

Try it out for yourself at http://translator.live.com

Tuesday, September 25, 2007

Implementing custom source control glyphs for VSIP scc providers

It's the second time in the last month when someone asked me how to implement correctly the IVsSccGlyphs.GetCustomGlyphList function in their source control provider so they can expose custom source control glyphs.

So, this time I though I should implement the function myself and see what's going on...

Of course, on first try I've hit the same problems reported by the customers :-). It turned out quickly that the problems come either from not setting up correctly the image size in the imagelist, from not setting correctly the transparency color, or not declaring the interface on the correct service.

If you're interested, I've put the sample for download on my website: Visual Studio Source Control Provider with Custom Glyphs.

The sample is based on the SccProvider sample in VisualStudio SDK, so you can Windiff the 2 solutions and easily see the code additions.

Here is how to test the new code:
1. Build the solution in VS2005 and run it.
2. In Tools/Options set the Sample Source Control Provider as the active provider (at this point the shell should call you on IVsSccGlyphs.GetCustomGlyphList to get the custom glyphs suported by your scc provider).
3. Create a new solution, e.g. a ConsoleApplication C# project.
4. Add the solution to source control
5. Add a new file to the project or to the solution
6. The new file should appear in SolutionExplorer with the new "pending add" icon exposed by the package, like in the picture below.

Custom glyph exposed by the sample scc provider

Wednesday, September 19, 2007

The day Google became irrelevant

I keep reading posts and articles claiming that "Google is the best search engine".

The way I see it, it may still be the most popular search engine, but it's no longer "the best".
It has been beaten a while ago at usability by live.com for image search; it has been beaten in maps quality and features by local.live.com/VEarth, and recently it's not even longer "the best" for relevance of simple web searches...

You want the proof?

Here's a comparative search for a product mentioned in my previous blog post.



There's been more than 10 days since the post was created and google hasn't indexed it yet. To me this is even more unexplicable when I remember that blogger.com is also a Google-owned site. You'd think they'd index first the information on their own servers...

You may argue that Google's indexes have grown too big when compared with other search engines, that it has to make less frequent passes over the already indexed sites. Let's go with this theory and see what "less frequent" means.
Here's a comparative search for my wife's name.



There are now 2 month since my wife has changed jobs and Google still hasn't realized it. Flavia's contact info has been my site for at least 2 years now, yet it doesn't show up on Google in the top 50 results...

I'm sorry for those Microsoft haters out there who repeat ad nauseam "Google is the best", but at least to me, Google has lost its search relevance. I guess it's time for other search engines to step up and take the leadership.

Saturday, September 8, 2007

Cross Flow fan replacement for Infrant ReadyNAS 600

For safe(r) storage of my data I use an Infrant ReadyNAS 600 in RAID mode 1.

The model A of the device uses for cooling a cross-flow fan, which is silent, speed adjustable, and seemed cool looking at the time. While I kept good care of it (blowing it of dust every couple of weeks), after 2 years of use it showed fatigue signs (noise), and in one week it stopped working completely. The device can't work without the fan - the hard drives get easily to 60 degrees Celsius and the device powers itself down for protection.

Unfortunately, it isn't very easy to get a replacement for this fan. Newer ReadyNAS models use regular fans which are cheaper (and easier to buy, I'd add).

Infrant calls the cross flow fan for ReadyNAS 600 model RN06-FAN1 and a replacement should have been easily bought from their site http://www.shop-infrant.com/RN06-FAN1.htm. However, Infrant is now Netgear, and while the stock transitions the fan is no longer available for buying.

So I tried to buy the fan from other sources.

Looking on the fan in my device, it shows on its label:
Cross Flow Fan
JDH-03009A12
Jin Yin Shyang Ent.Co., Ltd.,Taiwan

A net search shows the JDH03009A12 fan is only available on http://www.x-cool.biz/product_info.php/products_id/1118 which is a Chinese-only site. I tried buying the fan from the site with the help of 2 Chinese-speaking coworkers, but the site has such a bad design I didn't succeed placing an oder (also the site is not secure - doesn't use SSL, and buying from here is a bit shady). The site is owned by Li Yahuiy (yahuiyli AT hotmail.com and yahuiyli AT yahoo.com) which has other auctions for the JDH-03009A12/RN06-FAN1 fan on yahoo site. However, the guy doesn't seem to speeak English, and at least for me, using Google beta translations for every mail is not an option.

Fortunately, I obtained a temporary fan replacement from Infrant (more on this later). The new fan has this info on its label:
Chiefly
CCB13898S12L
Sleeve Bearing
Chiefly Choice Co., Ltd

See here both fans (old and temporary replacement):


A search for the new model/company finds it on another Taiwanese site http://www.chiefly-choice.com.tw/DCB13898-SPECIFICATION-DATA.htm, but they don't seem to sell it either.

Anyway, this gave me more confidence I'll be able to find similar fans in the future. It looks like I'll just have to find another cross flow fan, 12V, with dimension 130X45X40.6mm (overall) and 108X32mm(mounting holes). Preferably, this should use 0.12-1.13A.

I did a quick search and it looks like there are other models that fit the description:
CRHD-030 Series on www.camyork.com.tw (still Taiwan)
DF30098V12 models on www.sofasco.com (Finally a site in U.S.)

While the connector is not the same, the voltage/amperage and dimentions match, so I guess that after changing the connector these fans can be used as replacement without problem.

Hopefully the fan will also be available again from Netgear site, after the stock transfer...

Friday, August 17, 2007

About SourceSafe physical file names and file numbers

If you worked long enough with SourceSafe, you probably heard by now about the physical file names associated with files and projects from a SourceSafe database. The SourceSafe command line ss physical can be used to display the physical file name associated with a logical file or folder from the VSS database.

If you look at the the free SourceSafe tools from the www.ezds.com site you'll find a SSNPL utility whose description says that every SourceSafe file has a number, a physical file name, and a logical file name; ssnpl converts from one to the other.

If you asked yourself why is the number good for, the answer is simple: when storing a reference to a physical file in another database file, VSS will use the file number instead of the physical file name, because it requires less space on disk.

So, the question that remains is how does VSS generate these physical file names, and what is this file number calculated?

Let's start our investigation by creating a new database ("mkss.exe C:\temp\vss"). The database is initially empty, and in the data folder there is only one file, data\a\aaaaaaaa. If you use the "ss.exe physical $/" command you'll find out that AAAAAAAA physical name is used by the database root.

From this MSDN article you'll find that the content of the data\aaaaaaaa.cnt file in the SourceSafe database reflects the physical name of the last file added to the database. Indeed, the initial content of this file is 'AAAAAAAA' - sign that last created file or folder was the database root.

Let's add a file into the database. You'll see that the content of the aaaaaaaa.cnt file is now BAAAAAAA, and SourceSafe has created a new file on disk, data\b\baaaaaaa.

Let's continue adding one-by-one new files into the database and each time look at the content of the aaaaaaaa.cnt to see how the new physical files are named. It's easy to see the files are named BAAAAAAA, CAAAAAAA, DAAAAAAA, etc., each file ending up in the data subfolder identified by the first letter of the filename - (data\b\baaaaaaa, data\c\caaaaaaa, data\d\daaaaaaa), etc. After the last letter of the alphabet is reached (ZAAAAAAA), the filenames wrap back, using the second letter: ABAAAAAA, BBAAAAAA, CBAAAAAAA, etc., with files being created on disk in data\a\abaaaaaaa, data\b\bbaaaaaa, data\c\cbaaaaaa, etc.
So, the SourceSafe naming scheme and location of physical files uses a 26-way hashtable to distribute the files on disk in the a-z subfolders of the data folder.

If you run the SSNPLtool on the files added into the database ("ssnpl.exe $/ C:\temp\vss\data", etc.) you'll see their numbers are incremental: 0 (the database root), then 1, 2, 3, 25, 26, 27, .... etc. for each added file.

It's failry easy now to deduce how the numbering scheme works:

  • each file added into the database gets next available number in sequence: 0, 1, 2, etc.
  • the physical file names are composed of 8 letter characters, using letters A-Z: [L0][L1][L2][L3][L4][L5][L6][L7]
  • the number associated with a file is: (L0 - 'A') + 26 * (L1 -'A') + 26^2 * (L2 - 'A') + 26^3 * (L3 - 'A') + ....

Basically the physical file name is a base-26 representation of the file number, with each base-26-digit represented in A-Z range instead of 0-9A-P.

You should be now able to convert easily between the file numbers and physical file names.

As for the mapping between physical file names and logical paths in the database, that is a bit more complex, so I'll leave it for another time...

Thursday, August 16, 2007

Terminal Service client not using saved credentials

I had this problem for quite a while now, and it finally bothered me enough to go and search for a solution...

I use TS client to connect with smartcard from my home Vista machine to various machines at work through a Terminal Services Gateway.

When I'm connecting to Windows 2003 or Longhorn machines I am only required to input my smartcard pin and this is enough to authenticate me. However, when connecting to my alinc02 Vista machine, things are not that smooth. On this machine, TS asks my smartcard pin, after that it fails with the following message: "Your credentials did not work. Your system administrator does not allow the use of saved credentials to log on to the remote computer because its identity is not fully verified. Please enter new credentials."

'Your credentials did not work. Your system administrator does not allow the use of saved credentials to log on to the remote computer' error message

Of course, after typing my domain user and password the connection succeeded, but why was this dialog necessary?

I've searched the net for the exact error message but I could not find a solution. So I ended up asking the experts...

It turned out that my issue was described in this article from Terminal Services Team Blog, under Scenario 1 (Problems using saved credentials with Vista RDP clients - Connecting from home to a TS server through a TS Gateway server). There was also a solution proposed, too. However, since I was connecting to a Vista machine, I could not use the recommended solution (tsconfig.msc is only available on servers and I could not get to work on my Vista machine the applet copied from a Longhorn machine).

Fortunately there is a solution by altering the TS settings on the client side (this solution is not as secure as using certificates on server for server authentication).
In Vista, the Credential Security Support Provider protocol (CredSSP) adds a couple of group policy settings that are described in detail in MSDN CredSSP group policy settings page.

What I needed to do was:

1. Log on to your local machine as an administrator.
2. Start Group Policy Editor - "gpedit.msc" and accept the UAC prompt.
3. Navigate to "Computer Configuration\Administrative Templates\System\Credentials Delegation".
4. Double-click the "Allow Saved Credentials with NTLM-only Server Authentication" policy.
5. Enable the policy and then click on the "Show" button to get to the server list.
6. Add "TERMSRV/" to the server list, in my case TERMSRV/alinc02.redmond.corp.microsoft.com. Using one wildcard (*) in a name is allowed. For example to enable the setting on all servers in "microsoft.com" domain you can type "TERMSRV/*.microsoft.com".
7. Confirm the changes by clicking on the "OK" button until you return back to the main Group Policy Object Editor dialog.
8. At a command prompt, run "gpupdate" to force the policy to be refreshed immediately on the local machine (although this changed for me after a while)

Modify the 'Allow Saved Credentials with NTLM-only Server Authentication' TS Client group policy

With this policy enabled, the login to my alinc02 machine now requires only the smartcard pin, same as the other machines.

(I was told that if I'm not an admin then I may need to set in the rdp file
enablecredsspsupport:i:0, but this was not necessary in my case - setting it just got rid of the error message and replaced it with a regular Vista logon prompt)

Since we're speaking of group policies, it worth mentioning another setting here, "Allow Delegating Default Credentials", which helps making TS connections to a remote server (in the same domain) without being prompted at all for credentials (current Windows user's credentials are used for the remote server). For more information on this see Mahadev Alladi's blog article which inspired the settings in my case, too.

Wednesday, August 1, 2007

Visual Source Safe 2005 GDR CTP is available

Yesterday Microsoft released the Visual Source Safe 2005 GDR CTP.
(GDR stands for "General Distribution Release" and is a single, cumulative package composed of one or more files used to address a problem in a product - much like a Service Pack. GDRs are intended for public consumption and are made available on external websites)

You can read the KnowledgeBase article detailing the release and download the CTP from this address
http://www.microsoft.com/downloads/details.aspx?FamilyID=faf41edd-924d-449f-aefc-9c86dd499720&displaylang=en

Richard Berg has published in his blog a better list of the bugs fixed with this GDR.

Continuing education

I read today a blog post about the Linux's success in China. Instructive reading, I learned today a couple of new words:

Borg - an "assimilated" Windows user (or drone, with Microsoft probably viewed as Borg Collective)
Maclot - a Mac zealot user (refine definition on google, define:clot)
Freetard - a Linux user or free software zealot (refine definition on google, define:tard)

In this sense I'm a Borg. Prepare to be assimilated, resistance is futile! :-)

Wednesday, July 25, 2007

About Visual SourceSafe 6.0 build numbers

Ok, I wrote some of this info so many times that I've decided to write a page where I could point users to read it directly...

Here are the SourceSafe 6.0 versions available:

VSS 6.0 RTM - This build is what shipped back in 1998 in the Visual Studio 6.0 box and as standalone product. It's a combination of binaries from builds 8169 and 8163.
The VSS 6.0 build numbers are 4-digits numbers equal to (8000 + number of days since beginning of 1998). E.g. 8001 is 1/1/1998 and 8169 is 6/18/1998.

VSS 6.0 builds before 6.0b - There are a couple of builds shipped between 1998 and 2001 on which I was not able to get too much information.
8383 - Shipped with Visual Studio 6.0 SP3 (some flavor of original 6.0)
8790 - SourceSafe 6.0a (my guess is that it shipped as standalone product)
8835 - Shipped with Visual Studio 6.0 SP4 (some flavor of 6.0a)
8987 - Shipped with Visual Studio 6.0 SP5 (some flavor of 6.0a)

VSS 6.0b - This build shipped in 2001, but I don't remember the occasion; my guess is that it shipped with a beta version of VS2002. It's a combination of binaries from builds 9119 and 8163.

VSS 6.0c - This build shipped in 2002 in Visual Studio .NET 2002 Enterprise box (VS7.0) and as standalone product. It's a combination of binaries from builds 9447 and 9350. Later, Microsoft included the same build into Visual SourceSafe 6 Service Pack 6 (VSS6SP6). Users of the older builds can upgrade for free to VSS 6.0c by installing VSS6SP6 (a 5.2MB download) from this MSDN page. Users of VS2002 and later are strongly advised to upgrade at least to this build (older builds don't recognize all VS2002 project types, the source control integration experience is worse, there are also 4 years worth of bug fixes)

VSS 6.0d build 9848 - This build shipped in 2003 in Visual Studio .NET 2003 Enterprise box (VS7.1) and as standalone product. It's the original VSS 6.0d release. 6.0d builds address various security issues with older builds, are built using VC7 instead of VC5, etc.

VSS 6.0d build 31222 - This later VSS 6.0d build was included in Visual Studio 6.0 Service Pack 6 (VS6SP6). Do not confuse this with VSS6SP6 that contained VSS 6.0c! Users of older builds can upgrade to this VSS 6.0d build by installing VS6SP6 (a 62MB download) from this MSDN page. You can upgrade your SourceSafe install for free to this build even if you already have VSS 6.0d 9848, and even if you don't have VS6 installed on the machine. You'll notice the build numbering scheme has changed from the incremental 4-digits numbers to 5-digits numbers representing year-month-day when the build was created.

Of course, there are newer VSS 6.0d builds available (as of writing this post, 61101 is the last build) that are addressing various specific problems some customers encountered. If you think you have a problem one of these builds may fix you can obtain them by calling product support (or request a QFE and have a new build created if the QFE is approved).

Thursday, July 12, 2007

Really Right Stuff (RRS) clamp for Bogen/Manfrotto 484RC2 on a Velbon ULTRA-MAXi tripod

I just found my travel tripod in the closet and I remembered the hard time I had last year searching the Internet for information on replacing the Velbon ULTRA-MAXi's default head with a more sturdy ballhead.
Now that I have a blog I guess it's the right time to post here my solution...

I decided to replace the head with a Bogen/Manfrotto 484RC2 ballhead and mount a RRS clamp on it.

The original 3-way pan-head of Velbon ULTRA-MAXi comes off easily by twisting it; it reveals a 1/4" screw. The 484RC2 head has a 3/8"-16 hole in its bottom, and to mount it on the tripod base you'll need a Reducer Bushing 7.5mm (3/8"-16 to 1/4"-20).

Now onto the RRS clamp... At the time I bought my clamp, the Really Right Stuff page listed B2 LR II or B2-Pro clamps suitable for Bogen/Manfrotto 484RC2, which was wrong (those clamps have a threaded hole to be installed on a ballhead with exposed 3/8"-16 threaded post, and they will not work on the 484RC2 ballhead, whose post has a hole after removing the original clamp and screw). I see that now the page was corrected to list B2 AS II and B2 Pro II. Anyway, I got the B2 AS II RRS clamp.

To screw the clamp on 484RC2 you'll need a M6 screw (RRS kindly provided me both with M6 and 1/4" screws). The screw that came with the 484RC2 head and the original Bogen clamp is also an M6 screw and fits the B2 AS II, too.

The clamp will not fit perfectly by default on the 484RC2's post because the post has two anti-twist tabs which are wider than the recessed "cross" on the back of the clamp (see the picture below).



The clamp will stay better if you rotate it 90 degrees.
For a perfect fit the tabs on 484RC2 have to be cut off completely or adjusted by thinning them with a small file. It's not hard to do it; it took me 10-15 minutes to thin the tabs and now the clamp fits perfectly; the original ballhead clamp continues to work fine, too.

Tuesday, June 12, 2007

Apple releases Safari web browser for Windows

Apple's Safari 3 beta web browser is now available for Windows. You can download it from http://www.apple.com/safari/

I downloaded yeterday the beta version of the browser, and at a first look I was not impressed. Feature-wise I haven't seen anything that other browsers like Firefox, IE7, Netscape or Opera don't already have: tab browsing, phishing filter, rss reader, etc.

In fact, comparing with IE7, Safari was worse:
  • I got a first crash in the browser in less than 3 minutes of using it
  • Font smooting on LCD monitors was making text worse to read, at least to my eyes
  • Resizing the windows or zooming, caused elements in page to overlap, making the text impossible to read
  • Sometimes the scripting was not working
See for comparison the rendering of the MSDN scripting page where the left tree is not rendered at all, etc. I guess the Apple developpers have to fix a couple more issues before realeasing the final version of the browser...
Safari rendering the MSDN Scripting pageIE7 rendering the MSDN Scripting page
And the issues don't stop here. There are reported crashing issues with non-English web pages, and a couple of security holes, too. For daily browsing I wouldn't be in hurry to switch to Safari just because it comes from Apple.


So then why is this release a good news?

Well, Safari seems to be the first browser on Windows platform supporting color-managed web browsing for photo viewing. If you don't know what I'm talking about, download the beta and view this Web Browser Color Management Tutorial with both Safari and IE. With a color-managed enabled browser, the color of the photo in the right column won't change when hovering the mouse cursor over it or when clicking the picture. Safari will display correctly the pictures.

If you are viewing photos on web that have embedded color profiles (e.g. created with Photoshop), you might consider doing these tasks with Safari, at least until IE or the other browsers will support color management.

Tuesday, May 22, 2007

Blogger.com feeds showing in Outlook 12 with 12/31/2006 dates

I've noticed that for a while all the posts on blogs hosted by blogger.com appear in Outlook 12 with incorrect dates, all equal to 12/31/2006.

It looks like Outlook has a problem parsing the ATOM XML feeds from Blogger. Fortunately, there is a workaround (until the bug is fixed): resubscribe to the blog using an RSS 2.0 feed.

If you didn't know about this, all site feeds on blogger are published by default in Atom 1.0 format. However, if you add ?alt=rss to the end of any site feed URL, you can get the same feed in RSS 2.0 format.

Instead of using the atom subscription feed like http://alinconstantin.blogspot.com/atom.xml , you can (re)subscribe to a blogger feed using an Uri like http://alinconstantin.blogspot.com/atom.xml?alt=rss or http://alinconstantin.blogspot.com/feeds/posts/default?alt=rss and the posts will appear in Outlook 12 with correct dates....

Saturday, May 19, 2007

Cannot Print or Print Preview from IE7 on Vista

Whenever I tried to print or Print Preview with Internet Explorer 7 on Vista I was getting an error message like this:

"Cannot find 'file:///C:/Temp/Low/GAG0N40P.htm'. Make sure the path or Internet address is correct."



followed by another script error message talking about an error in like 2069 in preview.dlg:


Of course, this happens because I changed the TEMP folder on my machine to C:\Temp.

When I try to print or print preview, IE7 creates a subfolder C:\Temp\Low, but this inherits the security settings from the parent folder, and the print fails when IE is not run elevated.

The solution is to open a Command Prompt in elevated mode (Run as Administrator), and in that window to run the following command

icacls C:\Temp\Low /setintegritylevel (OI)(CI)Low

If everything is ok you should get an output like this

processed file: C:\Temp\Low

Successfully processed 1 files; Failed processing 0 files

and after that the Print Preview should work fine.

(Make sure you recreate the Low folder before running the command in case you accidentally deleted the folder)

Tuesday, May 1, 2007

SourceSafe Internet configuration guide

Today I've updated my webpage on WinISP and I've duplicated there the source control-related articles for the unfortunate case when my website is down.

You'll find the guide for configuring Visual SourceSafe 2005 for Internet usage at:

Friday, April 13, 2007

How to open a HTC3600 to install the battery and SIM

I got yesterday a new toy, a HTC 3600 smartphone, and I've hit the first problem with it when I tried to remove the cover and install the battery and SIM card.
At a glance I couldn't figure it out; I read the manuals but I still couldn't understand how to open the HTC3600.

Here is where I think the problem is:

  • the HTC3600 quick guide only make a reference about "sliding" the cover, but doesn't tell you in which direction
  • "sliding" the cover doesn't seem like an option because it looks like the camera in the back won't allow such motion
  • the cover could be really tight on some units (at least until you open it a couple of times and it gets loose) and you're afraid of using the force and risk breaking a 600$ phone

Sounds a bit stupid, doesn't it? Well, I've search the net and so I've discovered I'm not a complete idiot, as many other people had the same issue...

Eventually, one post pointed me in the right direction. Now that I know how, it's easy to open it (it even opened by itself when I dropped it on the carpet :-))

Anyway, since many people looking for a solution asked for pictures, I decided to post this blog note.

The manual is right, the cover does slide in the direction indicated by the arrow.

To open HTC3600 phone, slide the cover in this direction



However, it will only move for 3-4 mm in this direction, and then it will stop.

HTC 3600 cover slides just a bit, then it can be removed


After that, the cover can be lifted and set aside. Notice the disk around the camera lens is just a cover (not the real lens), and slide together with the HPC3600 cover.

HTC3600 and cover


To open the phone you may need to use a bit of force. Here is how I think you can open the phone easier:

  1. remove the stylus from the phone (the stylus doesn't slide, and it will make it harder for you to grab just the cover and slide it)
  2. take the phone in your left hand as indicated in the picture below (with Call/Cancel buttons towards the palm, and left wrist)

    Hold the HTC 3600 phone with left hand to open it
  3. use the right hand index and thumb fingers on the upper/bottom and apply presure towards the right side while holding the phone in left palm

    Slide HTC3600 cover towards right to remove it
  4. the cover should slide 3mm with a click, then stop
  5. you can now lift the cover

Thursday, March 22, 2007

.old and .new files used by Visual SourceSafe

I was asked today what are the .old files SourceSafe may leave in the VSS database.

I had no idea what these files were and initially I mistook them for the .org files created by SourceSafe during the merge process. (If you're interested what the .org and .mrg files are you can find an explanation in this MSDN page http://msdn2.microsoft.com/en-us/library/ek8hk7e2(VS.80).aspx.)

I then realized the org/mrg files are created locally, on the client machines, and they have the same name with the sources files involved with the merge, while the .old files were reportedly created in the VSS database. And so I realized my mistake and started to search again...

It turned out that SourceSafe does create .old files in the VSS database.

Analyze.exe may create such files when it is run with -f flag (fix mode). When Analyze -f finds a corrupt file, it places a copy of that file in the backup directory, then rewrites the fixed file in the appropriate data\ directory. In some cases, after the original rewrite, another rewrite is necessary. Analyze does not overwrite the copy in the backup directory, but creates a file with the .old extension in the same directory as the original file. Under normal operations, this file should be deleted by the Analyze process. However, in some cases it is not. This KB article describes the problem http://support.microsoft.com/kb/167258
I believe this is the main cause why orphaned .old files may exist in the VSS database. The old files are likely safe to delete in this case (after making sure that fixes made by analyze are correct).

DdConv.exe tool may also create .old files (when converting a VSS4 database format to VSS5 database and it finds out duplicate file entries or mismatches in the parent projects, etc). I guess this was most common back in 1997 but now it is probably less common to see .old files created because of ddconv (databases created by VSS6 should be already in VSS5 or VSS6 format; databases created by VSS2005 are in VSS6 format). Again, investigate the warnings displayed by ddconv, verify the database after conversion is what you expect to be, and it's probably safe to delete the .old files.

And I found out another case when SourceSafe uses .old files (in fact .new files may be created, too). During a Rollback operation, SourceSafe will create a .new file and will write in it only the entries that have a timestamp older than the date you rollback to. Then, it will rename the current physical file into a .old file, will rename the .new file into the current physical file and will delete the .old file. I suspect it's more likely to see .new files remaining on disk in this case if there is an error during the rollback process (while creating the .new files) - it should be safe to delete these orphaned .new files. I can see .old files remaining on disk in this case if VSS crashes or is killed during this rename process, or if another user writes a new physical file (VSS is not transactional!) causing the rename of .new -> physical to fail. If you have an .old file but not a physical file without extension you should probably rename the .old file back (discard the .old extension) and run analyze on the database. Otherwise just look in the file's history and see if you need/want to redo the rollback, delete the .old file and redo the rollback if necessary.

Monday, March 19, 2007

How to backup SourceSafe database

Why back up the SourceSafe databases?

People think that by adding their sources to a VSS database they are "safe" from losing their sources. They are wrong, and here are a couple of examples:
  • Often, the SourceSafe database is stored on the same machine where the project sources are. A hard drive failure will make you lose both the project sources and the VSS database! People discover this only when they try to restore the sources from the VSS database and realize this is gone, too. This is more of a problem for individual developers because in a team you can recover at least latest sources from a teammate's harddrive; however, you lose the source history in that case. Having a database backup on a different machine/tape/dvd will solve this problem
  • SourceSafe is not transactional. A crash of VSS application in the middle of a write operation in the database could cause database corruption. Analyze tool provided with VSS can fix some errors, but sometimes analyze.exe can't fix the corruption (and sometimes even analyze.exe can cause more corruption). Having a database backup can save you a call to product support and can restore the database to a known good state.

How often should I back up the SourceSafe database?

Well, that depends on you, but I'd recommend a daily backup. Thus, if something really bad happens you can restore the database to the previous day's backup and only lose a day's work...

Deciding the backup strategy

Before writing a backup script you have to decide on a backup strategy. First, decide what exactly are you trying to backup:

1) You can choose to back up only the latest version of the sources. You'll find on the Internet a lot of scripts that claim to do "SourceSafe backup"; they simply do a GetLatest in a folder. Personally I don't consider this a real backup solution: the reason you add the sources in a VSS database in the first place instead of creating daily archives is to have history of changes; this method does not preserve history. In case you're interested in latest sources only you can probably use directly Shadow Folders feature of SourceSafe instead of such "backup" process...

2) You can choose to backup only a portion of the database containing a project of interest. SourceSafe comes with two utilities, SSArc.exe and SSRestor.exe (Archive and Restore) that can help with this task. For their usage please see the MSDN documentation.
SSArc/SSRestor use for the backup file a binary proprietary format, and the archive size cannot be larger than 2GB (4GB in VSS2005). VSS6 does not warn when this limit is reached, causing silent corruption of the archive. Because of this limit I wouldn't recommend this method for backing up large amounts of data. A possible advantage of this method is that you can specify an option to archive tool to delete the old versions of the files that you just archived - this is nice to use to reduce the database size in case you don't care about files history. While you can specify the root of the database as the project to be backed up, when restoring such archive the files will end up in a subfolder. If you're interested in backing up the database root I'd strongly recommend using the 3rd method.

3) You can choose to backup the whole database. The VSS database is just a collection of files stored on your local disk or on a network share, so any file backup utility or directory replication service/program should work just fine.
The "poor man's solution" is to use "xcopy /s" command to simply copy the whole database in the backup target location.
However, as a single developer I prefer using robocopy.exe (Robust File Copy utility). For older operating systems this utility is distributed with Windows Resource Kitt; if you have Vista or later you already have this utility installed. robocopy will only copy newer/different files so it will save bandwidth when copying the database on a network machine. Robocopy will also retry the operation (in case you're backing up to a network location and the network goes down), and supports a /Mir parameter useful if you're using the same target location every day (it will also delete unnecessary files that would otherwise be orphaned).

Running Analyze.exe during backup

A good practice for a SourceSafe database administrator is to run regularly Analyze.exe (SourceSafe Analyze Tool) on the database to indentify and fix possible corruption. The sooner corruption is identified the easier will be to fix it; waiting more could only cause more things to become corrupted, too. Thus, it is a good practice to run analyze.exe at the same time you backup the database.
There is one catch though: sometimes analyze.exe may cause corruption, too, or may fix things but not in the way you'd expect. While analyze.exe creates backups of the files it touches, it is often easier to simply have the database copy before running analyze (so you can easily revert to it in case something bad happens with analyze).
I'd recommend that in your nightly script you first back up the VSS database location, then run analyze on the database.

Things to take care of before running backup/analyze

Before running backup or analyze you'd want to make sure no user accesses the VSS database. Letting users access and modifying the database during backup could cause the backup copy to be only half way updated. Letting users access and modify the database during analyze could cause analyze to fail, detect false-positive errors or fix errors that don't really exist.

You can prevent VSS users from opening new connections to the VSS database by locking the database. From a batch script this can be done easily by creating a 0-byte file data\loggedin\admin.lck in the database. (Don't forget to unlock the database by deleting this file when you're done with the backup).

However, closing existing connections to the database may be a tricky task. The best time to run backup/analyze is during the night, when the chance of someone having connections and writing in the VSS database is small. While you should remind your colleagues to close VS and VSS before leaving home, it is likely sooner or later someone will still leave applications opened with connections to the database.

If you have a shared VSS database you should worry about remote connections. Sourcesafe is a distributed client application, and remote machines will access the database network share directly. There is no good way of closing these connections. You can for instance delete and recreate the database network share (using net share /delete command), but then you'll have hard time restoring the user permissions on the share. A better way may be to close directly the shared opened files (use the "net file" command, parse its output and extract the file IDs then use "net file /close" for the IDs of the file in the VSS database). Of course, disconnecting opened files or file share can cause database corruption, too (again the need for running analyze frequently on the database). A small mitigation is disconnecting the files at night, when they are likely opened in read-mode rather than write, and when the chance of causing corruption is smaller.

And then you have to worry about processes running on the machine hosting the VSS database. These can be your own processes (e.g. VisualStudio, VSSExplorer, SSAdmin, SS.exe, etc) or other user's processes (if the machine is a Terminal Services server). Here you can choose to simply kill the applications (devenv.exe, ssexp.exe, ssadmin.exe, ss.exe, etc) using tools like pskill.exe from Sysinternal's/Microsoft's PsTools suite. Again, killing processes may introduce database corruption (or with VSS2005 you may see warning messages about possible corruption); try as much as possible to close manually the applications instead of killing them.

If you're running SourceSafe 2005 you may also have services on the database machine that keep connections to the database. The VSS Lan Service should be stopped before the backup (net stop ssservice) and restarted after backup is complete (net start ssservice). Also, if your database is enabled for Internet access, the IIS host process and VSS service may access the database so you should stop and restart IIS (net stop w3svc / net start w3svc) after locking the VSS database (such that further incoming VSS Internet connections will be denied).

Stopping and restarting IIS host process may be required even for SourceSafe 6.0 server installations if you're using VSS-controlled FrontPage web projects. On the server, FrontPage uses ssapi.dll to open connections to the local SourceSafe database, therefore you must restart the web server to force FrontPage to close his connections.

Similar considerations apply for 3rd party services and applications that provide remote/Internet access to the VSS database.

When you're done with the backup

Don't forget to restart any services you may have stopped during the backup. Also, don't forget to unlock the database by deleting the ssadmin.lck file.
You may also want to parse the Analyze's output and mail you a summary report, so you can review the next day any fixes analyze may have done to the database.

Backup scripts

Sorry, I won't provide you here with any backup scripts. Just search the Internet for "SourceSafe backup" and you'll find a couple of free scripts. Note however that not all these scripts will take care of all the situations described above, so you may need to tweak and improve them yourself to better suit your needs.

Saturday, March 10, 2007

No sound in Remote Desktop (Terminal Services) sessions to Windows 2003

I've hit this problem yesterday, and since it took me an hour to solve it I thought I should post the solution here...

Basically, I was connecting from work using Terminal Services / Remote Desktop to my home machine, a Windows 2003 Server, and I was trying to listen music.
Unfortunately, Windows Media Player was giving me the following error:
"Windows Media Player cannot play the file because there is a problem with your sound device. There might not be a sound device installed on your computer, it might be in use by another program, or it might not be functioning properly."

I knew a couple months ago I was listening to my music on the home machine, so why isn't it working now?

In the help page I found the error code C00D11BA: "Cannot play the file" but the description there was not very helpful. I checked all the drivers, all appeared to be installed correctlyand working. Since I recently switched my network from a workgroup to a domain configuration, I thought there might be a domain policy preventing audio playing in TS sessions. But I found no such setting. I then thought client's configuration might be the culprit (I only had Vista clients), especially because connecting to other servers at work and trying to play sound files produced the same error. But no, that wasn't it.
I spent an hour searching the Internet, browsing articles that talked about enabling/disabling sound in client RDP settings, reinstalling DirectX on server, etc., etc.

Eventually I came up upon the right solution ...

Windows 2003 Server allows disabling certain resources in Remote Desktop sessions, and guess what? The sound is by default disabled for Windows Terminal Services sessions...

So, here is how to re-enable audio in TS sessions on Win2003:
- Launch "Control Panel" (Start Menu / Settings / Control Panel)
- In "Administrative Tools", launch "Terminal Services Configuration"
- In the mmc applet, select the Connections node, select the RDP-Tcp session settings in the right pane, right click it and open the Properties page.
- Click the "Client Settings" tab
- In the bottom of this dialog where the "Disable the following:" section is, uncheck the "Audio mapping" which is checked by default.
- Ok the Properties dialog.

If you are connected already to a TS session, you'll have to LogOut first (no, Disconnect won't be enough!), then LogIn again to the server, and voila! Now your audio files should play fine.

It's obvious now that you know about this hidden setting, isn't it? ;-)