One of the commands I've found more useful in PowerShell is the resolve-path command, which "interprets the wildcard characters in a path and displays the items and containers at the location specified by the path, such as the files and folders or registry keys and subkeys. The names appear just as they are represented in the drive, including capitalization".

It's the first part of the description states what I found to be most useful about it. Here's an example: I keep a Tools folder around in my E:\ drive which contains a large and assorted set of tools and executables I use everyday. Everything in this folder is stuff I can simply copy over to another machine and it will work right away, meaning that I don't need to care about installing or synchronizing any of them when I switch machines.

This folder also includes a few open source tools, like NUnit, NAnt or Subversion, which are updated every once in a while. I don't care about keeping multiple version of them around, but I do care about knowing which version I have in my system so that I can easily check if updates are available. For example, I might keep SVN in "$Tools\svn-win32-1.4.2\".

The last thing I want, however, is to have to keep updating my profile and other scripts where I use SVN so that the path matches the folder I have it installed with. With PowerShell, however, I can simply do stuff like this:

Here, I'm simply adding these folders to my path. If I download a new version of the tools, I can simply install it in it's own named folder (with the version number) and delete the old one, and my scripts (and my PATH!) will still be valid thanks to Resolve-Path. Sweet!

PowerShell

I'm a heavy user of the command line on Windows, and for a number of years I've used the open source Console application instead of running plain cmd.exe as my console of choice.

I currently have mine setup to host both cmd.exe as well as powershell, and do make heavy use of the Tabbed interface when I need to keep multiple prompts open.

It's a really cool utility and you can certainly configure it with a lot more eye candy if you like, like alpha transparency, custom backgrounds and so on. Me, I like my setup pretty minimal.

I've been trying to keep more up to date with the releases of some of the utilities I run on a daily basis, and Console is no exception. I'm currently running build 2.00.138, which was recently released.

If you're using older releases of the Console 2.0 beta set, then I highly recommend updating to this latest one. A few of the previous builds had some repainting issues that sometimes caused the console display to be corrupted or missing characters, but this latest build has been working great for me and the display update actually seems a bit faster for me.

Console, Tools

After a long time of procrastinating about it, I finally sat down and started putting together a simple profile script for PowerShell to make it a usable alternative for everyday tasks. It's an excellent shell, but without tweaking it a bit, it can be a bit painful to use at times.

One of the things I wanted to do was modify the global $HOME variable so that it points to my real home folder: one I've configured in the HOME environment variable and that bears no relationship to my user's windows profile directory.

I also wanted PowerShell to use this other folder when resolving filesystem paths starting with "~\", which can be very convenient. Here's what I came up:

The first line sets the $HOME variable, and needs the -force switch to do it since it is a read-only variable. The second line simply changes the Home property of the ProviderInfo object for the FileSystem provider (I don't care about how the home gets interpreted in other provider contexts).

On a side note, I also don't keep my real profile script in the default locations used by PowerShell. Instead, I keep my profile script in a file called "_profile.ps1" in, you guessed it, my home folder. Then I simply dot-source it from one of the real profile scripts recognized by PowerShell (such as "c:\users\<user>\Documents\WindowsPowerShell\profile.ps1"), like this:

Pretty cool stuff, and hopefully this will help me avoid procrastinating so much on making PowerShell my default shell on windows.

PowerShell

Recently I was writing a small script for Powershell and I needed to call an external program from my script. However, I wanted to be able to put keep the directory the executable was located in in a variable; you know, like one usually does in regular batch files.

After searching around using google, I found that you can execute the contents of a string as a command by prefixing it with '&', like this:

This is fine if you've got a simple literal string. However, if you want to use the value of one or more variables in it, you of course need to switch to using double quotes instead, like this:

Turns out you can actually execute the contents of a variable as a command, which I wasn't expecting to work at first:

Pretty nifty!

PowerShell

I just ran into Vimperator today. It's a Firefox add-on that enables VIM-like functionality directly info Firefox! I installed it to see what it's like and it seems pretty interesting (though not sure whether I'll get used to it or no).

By default, Vimperator hides the Firefox menu and toolbar, but many common Firefox keybindings still work.

As you would expect, you can open a site on the current tab using the :e command (tab will present a list of candidate URLs based on what you've typed so far). Using :open or o/O also works, and t/:tabopen can be used to open a URL in a new tab.

You can also close the current tab using :bd. Also, switching between tabs can either be done Ctrl+Tab/Ctrl+PgDown/Up or using :b[n]. where [n] is the tab number.

The usual Vim navigation keys (hjkl) can be used for scrolling around the page, among

Overall, seems like a pretty nifty add-on, so I'll try it for a while to see how it goes.

Update: Couple of things I've noticed to watch out for:

1. When completing URLs to open, the order of the entries in the list seems to be pretty random, instead of how Firefox usually does it (most used entries listed first). This can be a bit annoying.
2. The new modes do block out the GMail and Google Reader key shortcuts from working. To use them, you first need to press I and then they will work normally (press Esc to go back to normal mode).

Firefox, Vimperator

Yesterday I decided to go a bit on the bleeding edge and went ahead and installed KDE 4.0 on my machine running Kubuntu Gutsy Gibbon. I started installing kde4-core first, then went for the whole kde4 package.

For the most part, the installation went OK. There are many UI changes, and I'm not sure I like all of them, but it's nice enough for the most part. I did run into some issues, so maybe this might help others solve them.

Graphics Corruption

KDE 4.0 tends to use a bit more resources of your graphics card. Because of the sleep/hibernate issue I was running the open source Radeon driver (which doesn't do much acceleration), so it was very slow at first and I was experiencing some nasty graphics corruptions at times that forced me to restart the machine.

I then tried enabling again the restricted fxglr driver that Ubuntu can install automatically, and that felt a bit faster, but I was still suffering some heavy video corruption.

Finally, I tried ATI's (AMD's, really) latest linux driver, which I downloaded from here. This is actually working much better: I'm seeing no video corruption at all (as long as XComposite is disabled) and seems a bit snappier, though a few things in KDE4 (most notably, the shutdown screen) are just very sluggish overall regardless of which driver I was using.

Of course, now sleep/hibernate don't work again, so I need to try to find a workaround for that.

Update: I noticed that the fglrx driver wasn't loading properly, so I went in and removed all traces of the older ubuntu driver versions and reinstalled the ATI driver again, and now I've got both 2D and 3D acceleration (i.e. with DRI) working. Plus, it seems that sleep, at least is now working correctly again. Whoot!

Can't run with Elevated Privileges

The second problem I started to notice was that I couldn't run applications that required elevated privileges from the KDE menu. I could still run them using 'sudo' from the command line, but if I tried running them from the KDE menu, it would keep rejecting the password I was specifying. Sounds very like what other people reported here.

I was able to fix this by editing my ~/.kde4/share/config/kdeglobals file, and adding this at the bottom:

Wireless Networking

Whenever I boot directly into KDE4, I have no network right at the start, because the Wireless connection isn't configured.

Under KDE3, it still works right away because I have setup knetworkmanager already setup with my network details and it auto starts when I login. For now, I've added a script in ~./kde4/env/ that starts knetworkmanager when I login.

Unfortunately, it seems the KDE4 updates don't include a native KDE4 version of knetworkmanager so it seems it still runs as a KDE3 app.

The Shutdown Screen

The shutdown dialog in KDE4 just nags me, for two reasons:

1. The dimming on the screen while it is displayed takes forever in my machine; it's very slow, and the dialog itself takes quite a bit of time to paint correctly. I'm sure this has something to do with my video card settings, but I wish it wasn't quite so.
2. KDE4 asks you twice for the same information: Once you select the "leave"  option in the KDE menu, it asks you whether to logout/restart/shutdown, but all three options take you to the same dialog with the same choices again! Just dumb from an usability standpoint.

Other Problems

One issue I have not yet researched too much, but that is causing some issues is that kwalletmanager seems to crash right after I log in every other time, forcing a full reboot to get it to work again, which obviously breaks havoc with other things, including, for example, the wallpaper not getting painted on the desktop [1]. Hopefully this stuff will be fixed by the time Hardy Heron ships.

[1] Update: Looks like this isn't related to the other issue at all. KDE simply refuses to paint the wallpaper on many ocassions (but opening the dialog settings and clicking apply fixes it). No idea yet what the issue is.

KDE4, Ubuntu

I spent some time the last couple of days working on some C# code that used P/Invoke to interact with an unmanaged library consisting of several function calls and some callback procedures.

One of the issues I ran into was that I needed to pass to one of the library's functions a delegate for it to use as a callback procedure. Doing this is usually not much of a problem, but this time I'd get an AccessViolationException after my managed callback function returned, signaling that the stack was probably getting corrupted somewhere.

After looking around quite a bit I realized my mistake: The C API I was invoking used the C calling convention (__cdecl), instead of the __stdcall convention used in the Windows API.

I was correctly decorating my P/Invoke signatures with CallingConvention=CallingConvention.Cdecl in the [DllImport] attribute, but this only affect the APIs I called directly; the delegate instance I was passing as callback was getting marshaled as a __stdcall procedure, thus causing the problem.

I remembered that in the old days of .NET 1.0/1.1 there was nothing built into the .NET framework that you could directly use to signal the P/Invoke layer to marshal a delegate as a __cdecl function, so you usually had to resort to creating a little wrapper using Managed C++ or, even runtime code generation.

Fortunately, I discovered that .NET 2.0 had built-in support for this, though finding it took a while. Hopefully this post will make it easier to find in the future.

[UnmanagedFunctionPointer]

The .NET Framework 2.0 contains a the new UnmanagedFunctionPointerAttribute class, which can be used to decorate a delegate declaration. One of the fields of this attribute can be used to specify the calling convention you want to use when an instance of the delegate needs to be marshaled to unmanaged code as a callback function.

With this, I could simply declare my delegate like this:

Nifty and very useful stuff.

P/Invoke

Jeff Atwood has an interesting piece about applications polluting the user space, forcing their own folder and file structures and other crap into the user's home folder. He's right, but I think he stops too early.

Jeff's right that the classical Unix practice is a bit better than what Windows has always provided (even on Vista). In a lot of ways, Unix is in a better position because of things that are not directly related, but that do end up helping the issue in the end, like a better (simpler!) overall file system layout, and not having to deal with drive letters (or the stupid registry, for that matter).

However, even Unix suffers from user space pollution quite a bit, though in a different way than Windows user suffer. On Unix, the issue is mostly applications storing temporary and configuration data all over the user's home folder in hidden directories.

Different Kinds of Data

There are several problems that affect how Windows and Windows Applications handle the users directory. For me, however, the lack of good, clear guidelines and the way that application developers abuse the user's home folder are secondary issues.

The real problem to me is that very few developers (or the OS providers, for that matter) realize that there's different kinds of user-specific data, each one with different requirements and storage needs.

I see at least three different kinds of data you might want to store in some user-specific location:

1. The user's own data (documents, videos, music, projects, etc.). Applications will produce and manipulate this data but they should not dictate where and how it has to be stored; that's the user's problem.

   I hate it when applications insist on forcing a specific folder structure on me or on creating their own folders in my documents folder. Exactly because of this is that I've completely given up on using the "My Documents" folder on windows; and consider it pretty much a storage for temporary or throw-away data I don't care about (too many applications putting their crap there).

   I should point out that this category, for me, is, for the most part, about data the user is explicitly aware he is creating, not about other crap the application might be producing as a side effect. In other words, if you're thinking about saving a new file without asking me for a location, don't even dream about storing it here.

   Everything in this location is stuff I want to backup easily, without having to go around excluding folders created by tyrant applications.

2. Application configuration data: This is basically your typical application user-specific settings. To me, data belonging here should be, unless something extraordinary is required, machine independent. This is the settings I simply want to take with me when I switch machines, or that I want to keep synchronized between machines to keep my applications working the same everywhere. Again, this is stuff I want to be able to backup easily without carrying extra loads of crap, but at the same time I don't want to have to deal with it (like navigate through it) unless I explicitly want to modify something here.

   I very much prefer applications store their settings in the Unix-fashion: using simple text files (whatever the format). Even though windows stores the user registry hive file inside the user's profile directory, backing it up is mostly an exercise in futility and it is non-portable for the most part.

3. Other stuff: This will be mostly temporary or cache data used by applications, that I should never have to backup or care about. If it's gone, the application should be able to recreate it as needed or simply work without it. Classical example: a browser's cache and history files.

   Some Unix applications, for example, intermingle this data with their applications settings, which is a big no-no. You don't want to have to worry about backing up your browser settings and ending up with 200MB of its cache in it.

There are probably other kinds of data I'm missing, but the key point is that they are different and should be stored separately. I really wish more application and OS developers started using something like the above discrimination. It would make our lives oh, so much simpler.

Operating Systems