Where is Windows Calendar?

One of the useful applications removed in Windows 7/Server 2008 R2 is the Windows Calendar. I especially missed it because I never want any email/calendar bundle like Windows Live Mail. Here is how to get it back:

• Copy the Windows Calendar program folder from an earlier Windows installation to your new Windows 7/Server 2008 R2
• Optionally import your existing iCalendar (.ics) file.

Easy! Isn't it? Now to get the reminder feature to work:

• Create a WindowsCalendar folder in C:\Windows\System32\Tasks\Microsoft\Windows (or whereever that is in your install)
• Set the security on that folder to NOT inherit but add existing parent permissions, and to allow Authenticated Users to create files/folders, write attributes/extended attributes, and read permissions.
• Optionally remove the permissions for Local Service and Network Service, and to change the owner to SYSTEM

Done!

What's up with the Server 2008 desktop graphics bugs?

When Desktop Experience is installed, Server 2008 provides similar visuals as Vista. One thing I noticed though, is that the desktop doesn't act the same as in Vista:

1. The drop shadow on icon text may disappear on hover.
2. The selection rectangle has dotted outline as in Windows XP* instead of translucent.
3. The selected icons don't have translucent background.

It turns out that the desktop SysListView32 control is styled differently. So now I have a simple startup program that finds the Progman window, then the SHELLDLL_DefView window, then the SysListView32 window, and adds the missing extended styles LVS_EX_DOUBLEBUFFER, LVS_EX_TRANSPARENTBKGND, and LVS_EX_TRANSPARENTSHADOWTEXT.

A more robust solution would create a message-only window in the background, listen for the TaskbarCreated message, and reapply the styles to the recreated SysListView32.

These would take care of 1 and 2, but not 3. May be a call to SetWindowTheme would work, but I haven't tried.

* Similar techniques can be used on XP to get the translucent selection rectangle, but will clear the wallpaper.

Why doesn't WTSConnectSession work when I first tried it?

Because the MSDN documentation on WTSConnectSession is wrong.

If you follow it:

Parameters

LogonId [in]

The logon ID of the current session, where the user of that session has permissions to connect to an existing session.

TargetLogonId [in]

The logon ID of the session that you want to connect to.

And call the function this way, your program will merely disconnect your current session with ERROR_NOT_CONNECTED, leaving you to wonder if the execution of the program stops in the middle of the call.

Once you find out that WTSConnectSession is just a wrapper for the undocumented WinStationConnect, which exists in earlier versions of Windows than its wrapper, you should realize that the first two parameters as documented are swapped.

How to get the Security tab in XP Home?

Option 1:
How to add the Security tab to Explorer in XP Home (Download link of SCM)

Option 2:
Press F8 and boot to Safe Mode.

Option 3:
XP Home File System Hacks, See security tab and run with WFP disabled like in safe mode! or Security tab, ACLs in XP Home! Yeah!

Other Options:
Use the command line cacls or write your own GUI wrapper.

What's the scope of window handles?

Someone stated (though I've yet to find any supporting MSDN documents) that window handles are global to all processes belonging to the same window station. Yet, if you somehow obtain a handle to a window belonging to another desktop, and try to send messages to it, SendMessage may fail with ERROR_INVALID_WINDOW_HANDLE. Why?

If window handles are truly global, then, say, thread 'a' on desktop 'A' should be able to use handles from thread 'b' on desktop 'B', assuming that both desktops belong to the same window station, right? It seems that some magic needs to happen for the handle table to be visible to other desktops, that is, thread 'a' needs to obtain a handle to desktop 'B' with read access.

It appears logical, but needs to be clearly documented!

Where is the caret?

Carefully minded will spot at least one subtle difference between the Visual Studio editor, and the RichEdit control: the caret in selection. Why oh why I can get this cute blinking cursor when I select some text in Visual Studio, but not in WordPad or in RichTextBox?

Maybe it's hidden for some bizarre reasons, I'll just call ShowCaret to bring it back. Argh, doesn't work? OK, may be HideCaret is called multiple times, so I'll just call ShowCaret a zillion times to see what gives. What? The caret is actually destroyed, and I have to call CreateCaret?

How am I supposed to know the height of the caret? It's not exactly Font.Height, and I can't always get the position of two lines and take the difference.

Text Object Model (TOM) comes into rescue. It's implemented by RichEdit (not Edit, so no hope there, yet). Get an IRichEditOle with EM_GETOLEINTERFACE, then an ITextDocument, then an ITextRange from ITextDocument::Range, and finally the coordinates from ITextRange::GetPoint.

I'll leave it as an exercise to declare the TOM interfaces for .net. Yea this whole thing is purely artistic...

MSDN Documentation. Follow or Not Follow?

When reading MSDN, often time there are sentences like "do not do XXX" or "you have to do YYY" without further explanation. This time it is on the OFNHookProc page:

Do not call the EndDialog function from the hook procedure.

It happened that I also came across the HookProc implementation in FileDialog, using the .Net Reflector:

[SecurityPermission(SecurityAction.LinkDemand, Flags = SecurityPermissionFlag.UnmanagedCode)]
protected override IntPtr HookProc(IntPtr hWnd, int msg, IntPtr wparam, IntPtr lparam) {
    // ......
    } catch {
        if (this.dialogHWnd != IntPtr.Zero) {
            UnsafeNativeMethods.EndDialog(new HandleRef(this, this.dialogHWnd), IntPtr.Zero);
        }
        throw;
    }
    // ......
}

May be the .net team know win32 in and out that outsider rules don't apply to them; or may be sometimes it is acceptable to ignore MSDN.