Site Navigation
Microsoft has often delivered software with performance and quality that could be described as "underwelming". Considering their past record, the W7 (or Server 2008) release seems to contain many improvements. Whether this came from the goodness of Microsoft's corporate heart and a desire to give their user base the very best software possible or the realisation that they have to lift their game if they are going to compete effectively with the growing base of Apple and Google products, Windows users can still enjoy the benefits since most of these improvements were long over-due. In truth many of these improvements were available with Vista. But the Vista release received such wide-spread disapprobation that very few people noticed them. These enhancements include:
Logical Links . It is now possible to create soft and hard links. The Windows mklink command is roughly similar to the Unix ln command ... You will need the -d option for folders ... Initial testing indicates that Windows logical links are as robust and reliable as the Unix equivalent. It only took thirty years ... Was it worth the wait?
Multi-user support. Finally genuine multi-user processing has come to Windows. It is now possible to switch to another user login and to have multi-user functions actually work. In addition to this standard user folders are now C:\Users\username ... Which is easier and simpler for scripting purposes. There also seems to be an attempt at a rational unified approach for the "Administrators" group which more closely resembles the Unix approach to "Run as administrator".
Enhanced Task Scheduler and Background Processes. You won't find much discussion about this bug. But anyone who is familiar with the Unix cron and Windows "Task Scheduler" knows that the previous versions of the Task Scheduler had a few (ahem) undocumented features. Chief among them being the inability to handle termio. Unix had this solved last century. And now it seems that Microsoft have figured out how to run background processes without an attached console. There was an attempt made earlier (Server 2003) to fix this bug, but it lingered on though less flaky than it was with Server 2000, and would be exposed by high volumes of background tasks ... Now, initial testing seems to indicate that it is "sorted" ... Along with this (and probably related) Console 0 no longer has the same significance as it did for Server 2003 and Server 2000. The mstsc command no longer supports the /admin switch (Although it's probably not required now that this shortcoming and the previous one have been addressed). If you used to get around this bug by using either the Activestate or Strawberry WPERL shell ... You may no longer need to ... On the downside the GUI interface to the Task scheduler has become dense, labyrinthine, non-intuitive and rather difficult to use ... However the schtasks command has been improved ... Although it is not possible to load multiple schedules with the schtasks command (unless you use the XML switch ... But then you have to build some XML --- Which is almost as complex as the GUI).
Support for NFS. The penny has dropped ... Microsoft have realised that refusing to support NFS won't make it "go away". NFS is a moving target however ... There have been numerous improvements (mostly due to security requirements) ... But then again NTFS is also a moving target. This won't make life easier for SysAdmins ... As they must now manage compatibility between NFS version, NTFS version, Samba version etc ...
A windows "find" command. Although not as powerful and flexible as the Unix find command, the "forfiles" command can be a powerful addition to CMD scripts.
Unix-like options for some commands Some common Windows Commands now read options with a "-" qualifier as well as "/". This means that without thinking too hard you could find out your time zone with a command like this:
systeminfo | findstr -i zone
Which is not all that different from "grep -i".New commands to give information on system. The query command will give information regarding processes, sessions and users ... Add the /? option for more info on how to use any of these options.
Improved pipes and redirection. This started with Server 2003. Now pipes and re-direction are robust and reliable. And the nul file behaves more like the Unix /dev/null and can be used to silently truncate files in .cmd scripts. For example:
type nul > foo.bar
(Must use /y the '-' operator does not work with shell built-ins like copy)
copy /y nul foo.bar >nul 2>&1
Microsoft have also made attempts at improving and extending the powershell ... Although I remain unconvinced by the powershell, which was introduced several years ago. Microsoft certainly is doing a lot to promote its use ... For example, in an effort to encourage users of CMD and Unix shell, there is an impressive array of aliases ... Some of these are as follows:
- cat (Unix)
- cd (CMD/Unix)
- chdir (CMD)
- clear (Unix)
- cls (cmd)
- copy (CMD)
- cp (Unix)
- del (CMD)
- diff (Unix)
- dir (CMD)
- echo (CMD/Unix)
- fc (CMD)
- ls (Unix)
- man (Unix)
- mv (Unix)
Anyone who regularly uses the command line would be very familiar with at least half of the commands in the above list (depending on which side of the Windows/Unix fence you sit) ... So there is some rationale behind including these aliases in the powershell ... For example the aliases "dir", "ls" and "gci" are all aliases for the powershell command "Get-ChildItem" ... Which kinda makes sense for folks who just type "ls" or "dir" by force of habit. But the alias "gci" is the only one that makes any sense. Because any veteran user from either side of the Unix/Windows divide would be more likely to type something like the following:
:: Windows:
dir /a:d
dir /o:d /p
# unix shell:
ls -l
ls -alr
However, when the above commands are entered into the powershell it will return a weird back-handed message that reflects the cold hard reality that the powershell alias is nothing like the Unix "ls" command or the "dir" command built in to the Windows CMD shell ... The powershell "Get-ChildItem" cmdlet is meant to be a universal command line API to the file structure, the registry and Certificates. And like all powershell cmdlets the default output is unicode, so if you use redirection (without extra options to set the encoding) you should be careful only to include the windows unicode ready commands ... Otherwise you will get a surprise ... Shell users who are used to using pipes, re-direction will soon discover that the powershell does not really handle pipes and redirection at all. It merely substitutes it's own rather arcane set of commands for redirection and pipe operators. If you want to change the character set you need to add a parameter (-encoding).
Apart from simple commands like "echo" and (arguably) "man" (for "Get-Help"), the aliases are nugatory. And a dedicated powershell user would be more likely to use aliases for the long-winded powershell cmdlets.
And now that the CMD shell has been fixed and enhanced there actually seems little benefit from learning all of the powershell cmdlets. Microsoft have shown in the past that they are quick to drop support for products that are not "popular" ... And before making the considerable investment in learning the new commands, most programmers would want a clear demonstration of the benefits and Microsoft's commitment to long term support of the powershell.
Note: To make Windows 7 display folder extensions:
- Control Panel->Appearance->Folder Options
- Click on "View"
- Clear the check box that says "Hide extensions for known file types"