Drive letters

Everybody knows that Windows has mapped letters for drives and partitions. c:\windows or c:\program files are familiar notions to Windows users.

There is a big probability that you have only two drives on your computer, C: as hard drive and D: as DVD/Blu-Ray drive. The days when one had A: and/or B: drive are long gone. A: and B: were reserved for floppy disk drives. These drive letters can be reused if ones goes to „Administrative Tools -> Computer Management -> Storage -> Disk Management”.

Here is one for you: Why doesn't Windows use A: and B: for USB flash drives? It doesn't do that even if it doesn't have other letters at disposal! This has proven to be a very effective way of disabling USB flash drives from being mounted, as seen below:

The USB flash drive was insterted but Windows couldn't mount it! No error message is being given to the user either. Nothing happens!

Starting with Windows Vista by default one cannot simply create files and directories on drive C:, you either disable the UAC (User Access Control) or comply with this rule.

I used to have my hard disk partitioned as C: for Windows and other programs and D: for my projects / files. But at times I would have less space on D: and I was forced to move data to C: drive. This was a bit annoying.

After installing Windows 8 on a fresh SSD drive I've decided to have only one partition and one fake one. I've substituted a directory for a drive letter. "subst c:\users\cristian\D d:" was the magic line.

In order to change the label of my new D: drive I had to create a registry key (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\DriveIcons\D\DefaultLabel) and then I had the label "Data" for D: as I used with my Windows 7 system:

Unfortunately Total Commander doesn't know about this trick and it displays the same drive label for D: as it does for C:

Soon I've noticed that my emulated D: drive was visible just for me, it was not usable for programs ran as Administrator. This turned to be a letdown, I had to run "subst c:\users\cristian\D d:" from a cmd.exe shell ran as Administrator. Couldn't be a way to run this script for both users?

Fortunately "Andres" had published on stackoverflow a solution to run a cmd.exe shell script as Administrator. His solution uses a hybrid shell script which is a valid cmd.exe shell script and also a WSH JScript.

Now I had a script which runs "subst c:\users\cristian\D d:" from my user and also from the Administrator user. Cool! I've put this script in the "Start Up" and now I have a fully functional D: drive!

@if (1==1) @if(1==0) @ELSE
@echo off&SETLOCAL ENABLEEXTENSIONS
>nul 2>&1 "%SYSTEMROOT%\system32\cacls.exe" "%SYSTEMROOT%\system32\config\system"||(
    @subst d: %USERPROFILE%\D
    cscript //E:JScript //nologo "%~f0"
    @goto :EOF
)
@subst d: %USERPROFILE%\D
@goto :EOF
@end @ELSE
ShA=new ActiveXObject("Shell.Application")
ShA.ShellExecute("cmd.exe","/c \""+WScript.ScriptFullName+"\"","","runas",5);
@end 

I like this solution. Now when I boot my machine I see UAC prompting me to run this script, which is also a nice way to inform me that my D: drive is mounted.

MSI + Unicode ≠ Love

I was upgrading my Libre Office installation to version 3.6.1 when I've noticed the question marks in the installer UI:

How can this be? Ș and ț (s and t comma below) characters are present in the Microsoft Sans Serif and Tahoma fonts since Windows 2000.

The only explanation is: ANSI installation program. No way! You would think that Windows Installer would be Unicode, but it's not! Michael Kaplan wrote about this weirdness seven years ago: MSI Databases and Unicode?

WiX also states on their help page: „Top-level elements like Product, Module, Patch, and PatchCreation support a Codepage attribute. You can set this to a valid Windows code page by integer like 1252, or by web name like Windows-1252. UTF-7 and UTF-8 are not officially supported because of user interface issues. Unicode is not supported.”

Programs like 7-zip use MSI for x64 target because NSIS installer did not have support for x64. NSIS officially doesn't support Unicode and x64, but there are forks which do (Unicode fork, x64 fork).

I've filed a bug (#54232) for LibreOffice. I guess they will use the old ş and ţ (s and t cedilla) characters to fix this problem.

Windows 95 End of Life was 1st of January 2003, Windows 98, Windows 98 Second Edition, and Windows ME End of Life was 1st of April 2007.

They haven't fixed this problem even though is has been five years since they do not support any ANSI operating system.

Windows 8 Consumer Preview and the Romanian Language

In this blog entry I will present a few issues gathered in a short test drive of Windows 8 Consumer Preview. If you are not interested in these Romanian issues, please stop reading here :)

The fonts

In the blog entry named Windows 7 and the Romanian Language I've did a bit of nit picking regarding the font families found on Windows 7.

As it turns out, Microsoft didn't fix the font family problems in Windows 8 Consumer Preview. Bad.

The language shortened name

Windows 7 had the Romanian language shortened to "RO", which was perfectly fine. Windows 8 has the Romanian language shortened to "RUM". This came a bit of a shock even though I knew the German translation, namely "Rumänisch".

"RO" short name was standardized by ISO 639-1. "RUM" short name was standardized by ISO 639-2, standard which was based on the MARC Code List for Language of the Library of Congress. There is also a ISO 639-3 standard which has Romanian shortened to "RON", but that's not good either, since the Romanian currency is also shortened to "RON".

If you ask any Romanian how should (s)he shorten the name of the Romanian language (limba Română), (s)he will say "ROM". As it turns out, "ROM" is also present in the ISO 639-2 standard, it marks the shortened form of Romany language.

This is not Microsoft's fault, but I think "RON" is better than "RUM". Baddish.

Retro translations

If you ask anybody from Microsoft which characters (şţ cedilla or șț comma below) should be used in Romanian translations, they will point you to this web page and they will correctly say that the comma below characters are to be used. I've seen such a discussion between Nokia and Microsoft.

But then why is the bing page above translated with the old cedilla characters? I can think of two possibilities:

1. They've outsourced the translation to a firm which uses the Windows Legacy Romanian keyboard layout (like since Windows 3.11)
2. The usage of the old cedilla characters was intentional because of problems on some operating systems which have problems displaying the new comma below characters (Android prior to version 3, Windows XP with IE6, WebOS etc)

I wish Microsoft would remove the Legacy keyboard layout in Windows 8. How long will it be supported? At least please change the şţ cedilla characters with the șț comma below characters in the Legacy keyboard layout

The latter problem can be fixed by using a small piece of Javascript code to detect if  the width of "stST" string is the same as the width of the "șțȘȚ" string. If they are the same width then the browser can display the new comma below characters. If not, then it means that the browser is using a different font to substitute the characters, or it is using empty square characters, in which casejust replace the correct comma below characters with the more portable cedilla characters.

I've presented this Javascript detection technique in this blog entry (Romanian): Diacriticele și Internetul. The MIT licensed Javascript code is located here.

Retro translations? Bad

Maps

Besides the fact that the old cedilla ţ is being used in "Constanţa", there is nothing wrong with the page. This is good, it used to be wrongly rendered a month ago. Fixed rendering? Good.

Thank you Microsoft, please correct the map data so that you are using the correct comma below characters. Old characters? Bad


We'll see how Windows 8 RTM will look like in a couple of months.

Windows 7 and the Romanian language

Starting with Windows Vista, Romanian language became properly supported on Windows: two new keyboard layouts were added, and font families were updated to include S comma below and T comma below characters.

Unfortunately some older fonts have some problems with S-comma below and T-comma below characters, comma is not below the S and T letter, is part of the letter. This happens also on Windows 7.

The two characters are part of Unicode's "Latin Extended-B":

I have done a simple test, to see how many fonts (from the Latin Windows fonts) have the S and T comma below characters with actual comma below symbol.

The simple test consists in a webpage rendered Internet Explorer 8 and 9 on Windows 7 with normal font size (96dpi) and with large font size (120dpi).

The test includes besides the Romanian characters (ĂÂÎȘȚăâîșț) also the "deprecated" S and T cedilla characters (ŞŢşţ) and S and T dot below characters (ṢṬṣṭ).

Test pages and screenshots for Internet Explorer 8, 9 and Firefox 5 can be found here. The results for 96dpi are presented below:

"Franklin Gothic Medium" is the only font which does not have S and T comma below characters.
"Tahoma", "Segoe UI" and "Microsoft Sans Serif" have S and T dot below characters which have the dot separated for the 9pt and 8pt font sizes, which is not true for S and T comma below characters.

The same test pages on Windows 7 with large fonts (120dpi) displayed correctly the comma for all fonts (except Franklin Gothic Medium).

Internet Explorer 9 comes with a new font renderer (using DirectWrite and Direct2D APIs) which reveals another problem with the S and T comma below characters. The comma below from S is different from the one under T, as seen in the images below:

Tahoma has a problem with A-Breve (ă), in the bold form, breve is slightly shifted to the right:

S and T cedilla characters, even tough not correct from the Romanian language point of view, are still heavily used in many documents / web pages etc. It is important that the cedilla should be drawn the same for S and T. This is not true for all Windows 7 fonts.

Firefox starting with version 4 includes locale dependent text rendering, which means that if you have the Romanian locale set the S and T cedilla characters will be automatically rendered with S and T comma below characters. Not all the Windows 7 fonts come with this locale information. Read more about this feature on Wikipedia.

The results for S and T cedilla are illustrated below:

As you have seen there is room for improvement when it comes to Romanian language support on Windows.

Corruption

Corruption is everywhere, even in Berliner subway :)

Hidden stream

If you wondered why does a security dialog pop up when you try to run the oggcodecs installer (or every executable for that matter) after downloading it from the Internet, this post is for you.

The security dialog looks like:



If you look at the file properties there is no checkbox like "this file came from the Internet" (CHM files have a check for this though), but this information is stored somewhere, in a NTFS Alternate Data Stream.

To check if a file has a NTFS Alternate Data Stream one can use the Streams utility made by By Mark Russinovich of Sysinternals fame.

Running streams oggcodecs_0.81.15562-win32.exe resulted: :Zone.Identifier:$DATA 46.

To view this "Zone.Identifier" stream I have used the more command like more < oggcodecs_0.81.15562-win32.exe:Zone.Identifier which resulted:

[ZoneTransfer]
ZoneId=3

Firefox is adding this extra information for every executable file downloaded. Does every web browser (I've tested only I few I know of) on Windows add this extra information?

• Mozilla Firefox 3.5.3 - yes (:Zone.Identifier:$DATA 46)
  
• Microsoft Internet Explorer 8.0 - yes (:Zone.Identifier:$DATA 26)
  
• Google Chrome 3.0 - yes (:Zone.Identifier:$DATA 24)
  
• Safari 4.0.3 - yes (:Zone.Identifier:$DATA 26)
  
• Opera 10.0 - no
  

Interesting how the size of the stream varies with every browser. I have submitted a bug report to Opera, because they should also add this extra information to the downloaded files.

Adding the Zone.Identifier stream can be done easily with a batch file
(from_internet.cmd)

@echo off
if [%1] == [] (

  echo Usage: from_internet.cmd executable_name

) else (

  echo [ZoneTransfer]> %1:Zone.Identifier
  echo ZoneId=3 >> %1:Zone.Identifier

)

Deleting a stream can be done by using streams -d.

They don't make'em as they used to...

Why does Thread.Sleep Method (Int32) have a signed parameter for the duration of time? Can you go back in time with a negative value? Is this an undocumented method of undoing things?

Compare this (System.Threading.Thread.Sleep) with this (Win32 Sleep).

Usually INFINITE is set to the maximum value. For Win32 API this would be 2^32 -1, for .NET that would be 2^31-1. The .NET INFINITE is half of the Win32 API INFINITE.

Instead of maximum sleep time of 49.71 days you get only 24.85 days... :)

Why Microsoft? Why?!

Take the cab file format. It's present on every windows from Windows 95. If you use the LZW compression algorithm you get small archives.

986.875 oggcodecs.7z
1.150.890 oggcodecs.cab
1.618.917 oggcodecs.zip

It's better than zip and a bit worse as 7-zip.

The problem with cab file format it's that it's hard to use it in command line.

For example here is what you need to code to compress one directory into a cab file:

for %%i in (oggcodecs\*.*) do echo "%cd%\%%i" >> files.ddf
makecab /L . /D CompresionMemory=21 /D CompressionType=LZX /D DestinationDir=oggcodecs /F files.ddf
del files.ddf
move disk1\1.cab oggcodecs.cab
rmdir disk1
del setup.inf
del setup.rpt

Pretty hard core. One might say that this is not a tool to be used from a command line as rar or other popular archiving programs. This is done only once by me in a script file, so I can live with it.

The problem is with the extraction method. I have created a folder inside that cab file, which I can see with Total Commander, 7-zip File Manager etc, but with Windows Explorer I see directly the files, without the directory. There is one command line program which handles cab archives - expand.exe. Expand.exe doesn't know about directories in cab files, there is no switch to instruct him to preserve the directory structure from the cab file.

Why Microsoft? Why?

The solution is simple, create the destination folder first, d'oh!

mkdir oggcodecs
expand oggcodecs.cab -F:* oggcodecs\

Why not use 7-zip and ignore all this trouble? A cab file I can digitally sign and you can see it's coming from me and you don't need a 3rd party program to unpack!

Why Microsoft? Why?!

I haven't mentioned here that I lost my fate in Microsoft that they can deliver good development tools a long time ago, I guess that was when I saw Visual Studio .NET 2002 for the first time. The .NET age fuc*ed it up real good.

At work I have Visual Studio 2003 and 2005 installed on D drive. Now I had to install Visual Studio 2008 on my system. I choose D drive, I verify every component that it should install on D drive and click Next, Next... Finish.

To my surprise the C++ component (VC directory) was installed on C drive, I said to myself... hmm, maybe I've forgot to install it on D, but it was working and I've ignored the issue.

The problem was when I've tried to compile something from the console. I've opened a console, setup the environment variables "c:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" and then hit nmake.

It complained that it could not find rc.exe, WTF. Then I found out that rc.exe is part of the Microsoft SDK which was on D (D:\Program Files\Microsoft SDKs\Windows\v6.1\Bin\). When I try to setup the environment variables for Microsoft SDK ("d:\Program Files\Microsoft SDKs\Windows\v6.1\Bin\SetEnv.Cmd" ) it complains that it can not find a compiler...

So now I'm installing everything on C drive, because for Microsoft, C++ should stay on C drive.

Edit: It works now (everything is on drive D), I've uninstalled all the programs that had a connection with Visual Studio 2008. If at first you don't succeed then try again, and again, and again.