I spent hours over the last couple weeks trying to make it so that one can get a browser add-in for IE that would auto-inject a reference to SLCanvas so that all web pages that use <canvas> would “just work” with IE 6/7/8. The good news is that I succeeded in the effort to get SLCanvas to simply show up on normal web pages. First I made SLCanvas fully accessible on the Internet without being site-deployed, by putting it on Google’s App Engine: http://silverlightcanvas.appspot.com/ (http://silverlightcanvas.appspot.com/static/slcanvas.js). I then tried GreaseMonkey for IE, but that turned out not to work worth crap. Then I started looking at making my own plug-in, but by the time I discovered SpicIE (which is, by the way, really handy), I discovered Trixie which was exactly what I originally had in mind. I wrote the Trixie script and it works fine: http://slcanvas.codeplex.com/SourceControl/changeset/view/38220#752961

The bad news is that SLCanvas might not be quite as completely implemented as I had hoped, and, worse, the web sites that use <canvas> in their demos are invoking the 2D context long before SLCanvas runs, or they are detecting IE and puking right off the bat. When they try, I’m getting a whole lot of “object doesn’t support this or that” errors:

Overall, this was a great idea that went a lot further south than I imagined.

I’ve been waiting for quite some time for my using.js project to pass all of its tests on Webkit and Opera. The last issue was the “retain context” issue, which wasn’t a using.js issue so much as a scenario issue, where if you declare a using block with using.js, the target object context for the “this” object was being retained in IE and in Firefox but not in Webkit nor in Opera. This issue revolved around the use of window.eval(), and I filed a bug report here:

https://bugs.webkit.org/show_bug.cgi?id=35722

.. as well as on Opera’s web site (no URL available as bug reports there are not public).

As is clearly observable in the history of the bug (bug title was changed by an Apple engineer) and in the comments of the bug, the scope and cause of the bug turned out to be more innocent than the browsers merely treating window.eval() differently. Although that remained true, it was irrelevant; I should have been using eval(), not window.eval().

The window.eval() function was the only eval() function I knew of. I had always assumed that eval() came about by way of the global window scope. But it appears that eval() is actually a standalone ECMAScript 5 operator now. This is interesting news! Who knew?!

So, note to self. From now on, never use window.eval()! Always use just eval().

And I’ve updated the using.js manual tests accordingly.

I really love Windows 7, but there are a few “features” that really annoy the living crap out of me.

1. Get your shared files back!

Microsoft apparently thought they were doing us a favor with “HomeGroups”, but for those of us who are able to comprehend the concepts of “yew-en-see file paths” and “aDvANcEd Sharing” (really just sharing), HomeGroups proved to be a genuine nuisance. First, HomeGroups flat disables traditional Windows sharing so that you can’t even access one home computer from another home computer using admin-rights-exposed UNC \\COMPUTERNAME\C$. It just doesn’t connect at all.

To bring back traditional file sharing, open up Network and Sharing Center, open up the HomeGroup section, and kill it. I also found in “Change advanced sharing settings…”

HomeGroup connections

Typically, Windows manages the connections to other homegroup computers. But if you have the same user accounts and passwords on all of your computers, you can have HomeGroup use your account instead.

[ ] Allow Windows to manage homegroup connections (recommended)
[X] Use user accounts and passwords to connect to other computers

Generally, both here and in Windows Explorer View Settings, if you are a Windows veteran, you can pretty much always avoid the “recommended” option. Thanks Microsoft. *sigh*

UPDATE: Not sure why I thought this would fix it. I recall that you also have to go into Explorer –> Tools –> Folder Options –> View –> (Uncheck) [ ] Use Sharing Wizard.(Some sites say that you’re supposed to check it. Unchecking it restores the classic Windows NT behavior.) But even after a reboot, I still get “Access Denied”.

Turns out you have to hack the registry to get C$ back.

http://support.microsoft.com/kb/951016

To disable UAC remote restrictions, follow these steps:

1. Click Start, click Run, type regedit, and then press ENTER.
2. Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
3. If the LocalAccountTokenFilterPolicy registry entry does not exist, follow these steps:
   1. On the Edit menu, point to New, and then click DWORD Value.
   2. Type LocalAccountTokenFilterPolicy, and then press ENTER.
4. Right-click LocalAccountTokenFilterPolicy, and then click Modify.
5. In the Value data box, type 1, and then click OK.
6. Exit Registry Editor.

2. Get rid of pesky background apps that want to stay in the taskbar.

The new Windows 7 taskbar is nice, but it should not take the place of the Quick Launch nor does it do away with the value of the system notification area (“sys tray”). Instant messaging apps whose windows have been closed but are still running in the background have no business filling up the task bar. They belong in the system tray, with icons no bigger than 16x16 so that they are not filling up the screen.

So, for both Live Messenger and for Skype, the simple solution to get around this ridiculously stupid new feature and bring back the old behavior of these IM clients running in the system notification area instead of filling up the taskbar is to navigate to the EXE file (in the program files directory), right-click on it, choose Properties, then click on the Compatibility tab, and select the option to run the program as if running on Windows Vista Service Pack 2.