These can be changed from Control Panel, in Regional and Language Options, Keyboard and Languages tab, "Change keyboards...", Advanced Key Settings tab. Alternatively, right-click the Language Bar and select "Settings...".
Japanese IME Shortcuts (summary)
Normal Mode (not in the middle of entering a word/phrase)
<Control> + <Caps Lock>
Switch to Hiragana input
<Alt> + <Caps Lock>
Switch to full-width Katakana input
<Shift> + <Caps Lock>
Toggle half-width alphanumeric (English) input and Hiragana input
<Alt> + <`>
<Control> + <Shift> + <Caps Lock>
Toggle kana and romanji input
<Shift> + <Space>
Enter half-width alphanumeric (English) space
Conversion Mode (when entering word/phrase via IME)
<Shift> + <Left>
Use less characters for conversion
<Shift> + <Right>
Use more characters for conversion
Convert to Hiragana
Each of these will flip through a number of possibilities on each press.
Convert to Katakana
Convert to half-width Katakana
Convert to alphanumeric
Convert to half-width alphanumeric (English)
These can be changed from the Japanese IME itself, which can be accessed from the Language Bar (right-click and select "Settings...", then select the IME and click "Properties..."). On the Editing tab, there is a drop-down of key templates and the option to edit. The above keys are all for the default key template ("Microsoft IME").
One thing which has been irritating me for a while is how it was using the "shrink-to-fit" method of sizing local video playback instead of "expand-to-fit". This results in any wide-screen videos losing the left and right edges, as I only have a 4:3 monitor (shame on me). I believe it'd be causing equal problems with non-wide-screen videos if I had a wide-screen monitor, though.
Until a few days ago, I'd been using ffdshow's capable suite of options to force output into 4:3 (while preserving the aspect ratio, i.e. adding evil black bars). This really eats CPU, even on the fastest resize mode, increasing usage by approximately 30%, which was actually causing my AMD64 3200+ (2.0GHz) to run out of cycles on some videos.
What I found a few days ago, though, was the real solution: time to start the Registry Editor, folks. Locate the following key:
Under this key there are a large set of options, most of which you don't want to touch. In this case, however, one particular one is crucial - ZoomMode_Video. Set that to "0". Done.
Footnote: There are 3 other ZoomMode_ options (ATSC, DVD, TV) and all 3 were already set to "0" here. ZoomMode_Video, however, was set to "1". I'd be very interested to hear how many, if any, other people have any of these ZoomMode_ options not set to "0" and which ones.
"Every time you want to leave your computer, you have to choose between nine, count them, nine options: two icons and seven menu items."
Ignoring the fact that I only have six menu items (no Hibernate), he has entirely missed the fact you only need the two buttons in all normal circumstances.
Sleep (left button)
By default, the left button is sleep, and it is the new hybrid sleep added in Vista. This does a combination of hibernate and suspend from previous versions - saving your work to disk, but only putting the computer into a low power state. This lets you resume work really fast and protects from power-loss.
Lock (right button)
The right button locks the computer. But wait, it also gives you access to switch user - using that giant blue button labeled "Switch User" on the locked screen. You can even shut down (or restart, or sleep - again) from the Switch User screen.
In his rant, Joel suggests that you don't need these at all:
While they are not usually useful, it's still useful sometimes to log off or manually restart, and switch user is a shortcut to lock+switch user which you might not remember or know.
In fact, there is only one option you might regularly need: shutdown. If you need this often, you're unlikely to need sleep, so the obvious thing to do is replace the sleep button with a shutdown one:
Control Panel > Hardware and Sound > Power Options.
Change when to turn off the display.
Change advanced power settings.
Power buttons and lid > Start menu power button > Setting.
Permalink | Author:Silver | Tags:Vista, Windows | Posted: 08:04PM on Tuesday, 15 January, 2008 | Comments: 0
Compatibility Administrator Meets Train Simulator
The original Microsoft Train Simulator was a great game at the time, and continues to be good fun (I'll save why it's better than Kuju's newer Rail Simulator for another time). It does, however, not entirely work by default on Windows Vista. There are a couple of issues:
Resolution changes cause windows to be rearranged.
On exit, it tries to create C:\FileIn.cns and C:\FileOut.cns and gets stuck in a loop because it can't.
You could work around the latter problem by running it as administrator, but that's clearly a substandard "fix". However, a much better solution which can solve both issues is the Compatibility Administrator in the Microsoft Application Compatibility Toolkit.
The Compatibility Administrator lets you tap in to a powerful collection of fixes already written by Microsoft for making other applications compatible with new versions of Windows. It also lets you view the fixes applied to each and every application in its system AppCompat database.
After installing the Application Compatibility Toolkit, you can launch the Compatibility Administrator as a standard user. For the purposes of this post, I'll create an AppCompat database just for fixing Train Simulator, but you can fix any number of programs with a single database, which simplifies deployment and installation.
Since it starts with a new database by default, just rename it by right-clicking and select "Rename". It really doesn't matter what you call it; I called mine "James Ross" in case I ever fix anything else with it.
Select the database, select the "Database" menu, "Create New", "Application fix...". This opens the wizard which will configure all the fixes we want for a single application.
Enter the details on the first page:
Name of the program to be fixed: "Train Simulator" (it's only for display).
Name of the vendor for this program: "Microsoft" (also only for display).
Program file location: browse to "train.exe" (e.g. "C:\Program Files\Microsoft Games\Train Simulator\train.exe"). This will be used later.
Now we get to pick from some standard fixes, including the commonly-used version lies. We don't want to select anything here, so ensure "None" is selected for the "Operating System Modes" and move on.
This is where the fun happens! There is a long list of possible fixes here, many of which can also take a command-line with options to control or limit the code that applies the individual fix. For the relatively simple problems with Train Simulator, we want to use two fixes:
With this, we can redirect CreateFile API calls (among other file APIs) to actually access somewhere other than where the program passes. We use the following command-line:
The -b (bare) turns off the standard mapping (which covers some system files that have moved over Windows versions), and then we specify two file corrections. Important to note that the double-quotes go outside the semi-colon separated pair of file paths. Also, we make use of one of the replacements (%UserAppData%), but note that these are not environment variables. There is a good weblog post about using CorrectFilePaths as well as some TechNet documentation.
This one is much simpler, and probably obvious from its name! It simply ensures that any resolution change is flagged as temporary, which prevents the window manager from shuffling things around.
As you may have noticed, the wizard has "Test Run..." buttons on each page of options. You need to be an administrator to use them (as it installs an AppCompat database temporarily to do it), but they can be very handy in some cases.
Now we must tell Windows how it is supposed to identify that this set of fixes should be applied to a launching application. The wizard will automatically add the executable selected at the start, and tick some properties. In our case, there's no need for most of them and I unselected everything except PRODUCT_NAME.
You could, if needed, add references to other files and decide which properties from them matter too; the fixes will still only be for the original executable, but it provides finer control over when to apply the fixes.
That's the AppCompat database created. You should now save it somewhere you'll remember (and be able to access from your administrator account).
Close Compatibility Administrator, and re-open it as administrator.
Open your AppCompat database, right-click it and select "Install".
Now, any time you run Train Simulator, the two fixes will be applied and joy will ensue.
I'm sure most people know that Microsoft designates the second Tuesday of each month as "Patch Tuesday" - the standard day for releasing all kinds of updates (both security and non-security) to Windows and other Microsoft products and technologies. Marking this in Windows Calendar is a trivial operation:
However, less well known is that on the Thursday before Patch Tuesday, Microsoft release an "Advance Notification" which indicates how many security patches are planned for release on the following Tuesday, what products they affect, and their severity. But how would you add that to Windows Calendar?
You can't do it via the GUI - it's simply too complex a rule. Wait, how would you describe it in any calendar anyway? Windows Calendar, like the majority of calendaring applications, uses the iCalendar format (RFC 2445). You can't specify that an event is positioned relative to another event, but iCalendar is still very flexible, as it allows you to combine restrictions on a repetition rule (see section 4.3.10 of the RFC for the gory details).
The simplest way I found to get the correct Thursday is to restrict the event using two criteria: month day must be 3 - 9 inclusive and it must be a Thursday. This works because only one day in the range 3 - 9 can be a Thursday each month, and it is five days ahead of the range of possible Patch Tuesday days (8 - 14). The rule is thus: "RRULE:FREQ=MONTHLY;BYMONTHDAY=3,4,5,6,7,8,9;BYDAY=TH".
To add such an event:
Start by adding a normal monthly repeating event and give it a unique summary.
Close Windows Calendar.
Find all the calendars in C:\Users\<username>\AppData\Local\Microsoft\Windows Calendar\Calendars.
Open the correct calendar file (they use the name set in the GUI).
Find the correct event by searching for the summary of the event.
Just above the summary is the "RRULE", which should be replaced with "RRULE:FREQ=MONTHLY;BYMONTHDAY=3,4,5,6,7,8,9;BYDAY=TH".
Re-open Windows Calendar, and it should appear on the Thursday before the 2nd Tuesday of every month.
Done! You can even edit anything about the event (except the recurring) from the GUI. Windows Calendar even knows it can't edit the more advanced recurrence rule:
It's well-known that the \Windows\winsxs directory in Windows Vista is large and can take up a significant portion of disk space on smaller devices. Less well-known is what it actually does, why it is huge or why it's not entirely a waste of space. I'll try and answer all three of these today.
To help dig in to this, I've written a small C++ application that will report certain information about the files in a particular directory - or individual files - and will use this to help explain the answers. Binaries and source code will be provided at the end.
What does winsxs do?
At the highest level, it is a collection of "packages" - lots of small groups of files. Each package (group of files) is identified by:
Architecture ("x86", "amd64", "ia64", "wow64" (32bit on 64bit) and "msil")
Locale ("none", "en-us", etc.)
It does more than just store the packages, though; applications can bind themselves to particular packages and specify what versions are acceptable. This is most evident with the Microsoft Visual C++ runtime files which, along with the Common Controls version 6 package, are more or less all you'll find in \Windows\winsxs on Windows XP. There are other features, like package redirections, which are in Windows XP as well.
Why is winsxs huge?
For Windows Vista, however, the main change is not so much how it works (although that was improved and made more robust as well) but in what it's used to store. In Windows Vista, all the operating system components are in packages inside \Windows\winsxs. That's all the core features (like Explorer) and everything you can enable in "Turn windows features on or off" (like IIS). That's a lot of stuff!
A consequence of putting system components in \Windows\winsxs is that they can be uninstalled reliably and with less dependence on order in Windows Vista - Windows XP keeps a load of \Windows\$NtUninstall... directories to manage it, but it has issues on ordering of installs and uninstalls.
Back in Windows 2000, you could install all the data from the CD-ROM onto the hard disk to avoid needing the CD when turning features on or off. I used it, but few people knew about it as you had to set it all up by hand (some OEMs did bother, though). This was a much simpler version of what \Windows\winsxs is in Windows Vista today. If you've ever turned on East-Asian support in Windows XP, you'll probably know how annoying it is to go and find the CD just to copy some fonts and locale support - this is just one of many places where Windows Vista already has the data available and it will never need you to rummage for the install DVD.
Why is winsxs not entirely a waste of space?
I'm sure you can appreciate that not needing to rummage for a DVD when changing features is good, but you probably don't do that often. Windows Vista might have a lot of data in \Windows\winsxs, but what about the features that are enabled? Don't they use up twice their size in disk space?
Here's the clever bit.
Installed features only consume space for their data, if they have any, but not for any of the code. How does that work? Hardlinks, a little-known feature of NTFS since Windows 2000 that allow the same file (and the same data) to be available from multiple locations in the directory hierarchy. The important part of measuring disk usage is that the vast majority of tools - Windows Explorer included - don't know or don't bother to know about hardlinks, which is partially why I wrote my own tool to explore this further.
Let's look at an example, C:\Windows\system32\shell32.dll ("Hardlink Scanner.exe" /F C:\Windows\system32\shell32.dll):
Breakdown for "C:\Windows\system32\shell32.dll" =============================================== Unique ID: 8e0000000a1534 Hardlink count: 2 Naive file size: 25,794,560 bytes Unique file size: 12,897,280 bytes Kind of file: normal Filenames: \Windows\winsxs\amd64_microsoft-windows-shell32_31bf3856ad364e35_6.0.6001.18062_none_c808e76dca883949\shell32.dll \Windows\System32\shell32.dll
In this example, it's clear this is a 64bit system as it is the "amd64" architecture that is linked into \Windows\system32. More important is that although both locations appear to have their own 12MB shell32.dll, using nearly 25MB in total, there is actually only one file and only 12MB of disk space is used.
Another example, the entire directory C:\Windows\SysWOW64 ("Hardlink Scanner.exe" C:\Windows\SysWOW64):
Here, about 90% of the files in the directory have at least one other hardlink that is outside this directory (you can work this out by comparing the "Files" and "Unique Files"; if the hardlinks were all inside this directory, the unique counts would be significantly lower). The higher-than-2 hardlink counts also bring up another clever feature of the Windows Vista \Windows\winsxs directory. Let's have a look at the 32bit MPEG 2 decoder ("Hardlink Scanner.exe" /F C:\Windows\SysWOW64\Mpeg2Data.ax):
Breakdown for "C:\Windows\SysWOW64\Mpeg2Data.ax" ================================================ Unique ID: 100000004f2ab Hardlink count: 4 Naive file size: 278,528 bytes Unique file size: 69,632 bytes Kind of file: normal Filenames: \Windows\winsxs\x86_microsoft-windows-v..e-filters-tvdigital_31bf3856ad364e35_6.0.6001.18061_none_dbbd58ec573f657a\Mpeg2Data.ax \Windows\winsxs\x86_microsoft-windows-v..e-filters-tvdigital_31bf3856ad364e35_6.0.6001.18000_none_dbfd382a570fa47d\Mpeg2Data.ax \Windows\SysWOW64\Mpeg2Data.ax \Windows\winsxs\x86_microsoft-windows-v..e-filters-tvdigital_31bf3856ad364e35_6.0.6001.18115_none_dbf76b9657133c48\Mpeg2Data.ax
Although there are three different versions of this package, Mpeg2Data.ax didn't change between versions and so \Windows\winsxs has used hardlinks between the packages as well as to the final destination. That's reduced the space consumption to just 25% for this file.
What does the saving look like for the whole of \Windows? ("Hardlink Scanner.exe" C:\Windows):
That's more than 5GB saved by using hardlinks within \Windows. Scanning my entire drive ("Hardlink Scanner.exe" C:), to include \Program Files (Internet Explorer and Media Player, for example) gives an overall difference of 5.9GB.
So, just takes those computed sizes from Windows Explorer (and other apps) with a little pinch of salt when dealing with Windows Vista's system files.
Unfortunately, you can't search this folder directly from the Start Menu. While this is an annoying problem, it's not insurmountable. In fact, it's pretty easy to manually rectify with a short bit of scripting.
Update Games Explorer is a short Command Script to enumerate the contents of your Games Explorer and copy the shortcuts into the Games folder in the Start Menu, thus rendering them indexed and searchable. The script can be run directly or as a scheduled task, whichever suits best.