When I recently encountered the issue where an old version of ildasm.exe instead of the latest version was unexpectedly used when run from the command line, due to the folder of the older version being located in my machine's PATH first, I thought of the which utility for unix/linux, which returns the location of a file on the path. (The "path" in this context is the set of folders that the operating system will search for a program that the user has requested to run from the command prompt or Windows' Start | Run dialog.) The "which" utility would have allowed me to immediately verify that the copy of ildasm.exe that was being run was not located in the expected directory.
I wasn't aware of a similar command-line utility for Windows, and writing one seemed like a simple enough matter, so I decided to write one. The utility would just need to get the value of the PATH environment variable, parse the individual directories out of the path, then do a "file exists" check in each PATH folder, checking for the specified file name.
I was able to put the program together fairly quickly, and it seemed like something that people might find to be generally useful, so I spent a little bit more time to polish it, then added it to the utilities page on my homepage for download as PathFind.exe. The extra polish included automatic searching for the file with extensions from the PATHEXT environment variable (.com, .exe, .bat, and so on) for files for which no extension is specified (so the user can search for just "iisreset" instead of having to search for "iisreset.exe"), as well as things like input validation, error handling, and a help message.
As it turns out, Microsoft also has released a similar utility, where.exe, available for download with some of its resource kits and SDKs such as the Windows 2003 SP1 Platform SDK (but not apparently available as a stand-alone download). The where.exe utility supports wildcard searches and some other advanced options, but doesn't support automatic PATHEXT extension searching.
This issue is pretty easy to come up with a fix for using a Google search, but I thought I'd note it here anyway.
If you get the error message "error : Failed to open meta data" when trying to open a file with ildasm.exe (Microsoft's .Net intermediate language (IL) disassembler), check to make sure that the ildasm version you are using matches the .Net version that the target file was built with. I encountered this problem when I was trying to run ildasm from the command line targetting a .Net 2.0 assembly, but the first instance of ildasm.exe on my path was the 1.1 version.
Google recently integrated Google Talk (their IM client) with Gmail (their email service). (More info on this is available in this Official Google Blog Post). Now, when you open a browser window with your Gmail inbox, a Google Talk widget with your "buddy list" appears in the window. You can also chat directly in the Gmail browser window in "popup panes" that appear in that window.
At first, I wasn't sure about the utility of this new feature. The thing that made Google itself take off at first a few years back, aside from the generally excellent quality of their search results, is the fact that the search page presented a really clean interface -- the Google logo, a text field, a "Search" button, and not much else. This integration of Google Talk into the Gmail window makes the Gmail interface seem rather more cluttered. I'm happy to just use the separate Google Talk desktop app.
However, the Google Talk / Gmail integration has enabled me to do something I've haven't been able to do before -- chat with my wife Missy at work!
Missy works at a large corporation where all individual workstations are heavily locked down security-wise. Users cannot install new software of any kind without IT intervention, and most ports on the external firewall are closed, so Missy has never been able to get any IM application to work on her work machine, including the Google Talk desktop app.
However, at least so far, the Google Talk client integrated into the Gmail browser window works just fine! It's in the browser window so there's nothing to copy onto the local machine, and whatever port the app is using to communicate is apparently not blocked.
So the Gmail-integrated Google Talk has at least allowed Missy and I to chat via IM during the day, which is pretty cool. Even though email and phone were both available to us before, IM just provides another way for us to stay in touch while we're apart, which is a good thing! :-)
A reasonable response after reading my previous post about a Notepad.exe bug might be "So what? Just use a *real* text editor." However, despite its shortcomings, for simple text-editing tasks, I still use Notepad a lot. Some reasons for this are:
(1) It's lightweight and doesn't have features that I don't want. (Examples are Word's autoformatting of things like bullet points and emoticons.)
(2) It supports the basic set of text-editing shortcut keys that work in other common Microsoft apps like Word and Visual Studio. (For example, Ctrl+F = Find, Ctrl+H = Find and Replace.)
(3) It doesn't do anything unnecessary with the clipboard -- it both copies and pastes pure text only, without any formatting. (One method for stripping formatting from text on the clipboard is to Paste it into a Notepad window and then Copy the pasted text from Notepad.)
(4) I can jump to a specific line number (with Ctrl+G).
(5) Perhaps most importantly, it's on every Windows machine that I sit down at.
I'd like to use a more powerful text editor like vi or Emacs, but I think once I got used to those editors, I'd be too annoyed every time I sat down at someone else's machine (which I do with reasonable frequency) because the editor wouldn't be present, and my habitual keyboard shortcuts wouldn't be available. (I might access the editor from my own machine over the network or carry it around on a USB drive, but that's also annoying.)
I also haven't found a "Notepad Plus" application that I really like enough to make a point of using it instead of Notepad. I'm trying out Notepad2 currently, but there a couple of things I don't like about it, such as the "Recent Files" section of the File menu not being implemented in a standard way, and Alt+N not working to jump to the text field in the Find dialog (which I've found that I actually use a lot).
The feature that standard Notepad does not have which I most wish it did have is a "Reopen" feature. Oftentimes I have some log file open and I want to see the most recent version on the hard drive that has been updated with recent logged events, but to do this with Notepad I have to do through the File | Open dialog and retype or reclick the name of the current file, which is a hassle.
It would be really nice if some developer at Microsoft would ask for a week or two of development time to really "fix" notepad -- add the Reopen feature and some other basic features that most other modern text editors have, such as "smart tabbing" (selecting one or more entire lines of text and pressing Tab or Shift+Tab indents/unindents the text instead of replacing it with a tab character). They could package the updated Notepad with Vista as another reason for people to upgrade!
I hope the reason that Microsoft *hasn't* done this isn't something silly like they are concerned that it could adversely affect MS Word sales.
(1) Open a new instance of Notepad.exe (Start | Run | notepad). Turn on Word Wrap (from the Format menu) if it isn't enabled already.
(2) Type some text that includes spaces, enough that the text wraps onto a few lines. (Try typing "The quick brown fox jumped over the lazy dog. " and then copy and paste that same text into the window another few times.) At this point, the caret (insertion point) should be at the end of the text.
(3) Save the document (from the File menu, or just push Ctrl+S). After the save is finished, notice the position of the caret -- it has backed up a few spaces!
This seems to happen whenever you save after typing a new line of text that needed to wrap. I can reproduce this on both Windows XP and Windows 2003 Server machines. If I recall correctly, the bug exists on older Windows versions as well.
A very minor bug, but Notepad is a pretty simple and heavily-used application. I'm surprised that no one at Microsoft has taken a few minutes to fix it!
Last year, Microsoft briefly offered a deal where you could purchase and take an MCP exam (towards an MCSD certification, among others), and if you failed it, you could retake the exam.
I went ahead and took advantage of this offer to take exam 70-316 (C# and Windows applications, one of the MCSD requirements). I figured that I could just go in and take the exam without worrying about studying, and then if I failed the exam, *then* I could invest the time to study, and retake the exam for free. (I ended up passing the exam on my first try, so it ended up working out well for me!)
Now, Microsoft is extending this offer again. I'll have to take advantage of this and knock out another couple of exams towards the MSCD (or possibly the new MCPD).
Based on a suggestion from my brother Jeremy, I updated the BoundsTest utility to display the current size of the window in the window titlebar, making it more easily visible at a glance. Thanks Jer!
Has this ever happened to you? You've typed a large amount of text into a form on a web page (such as the "body" field of an email in a web-based email application), then you click the button to submit the form. At that point, something goes wrong; the server returns an error, or the browser crashes, or whatever. The end result is that all that text you typed is gone; there's no way to Undo, and clicking the Back button won't help because either the browser crashed, or when you get back to the page where the form was located, you're presented with just a fresh blank copy of the form. You're left with the choice of re-typing everything you had entered, or just abandoning whatever it was you were trying to do. I've been extremely frustrated by this issue on more than one occasion!
A quick preventative measure for this kind of thing is a quick press of Ctrl+A followed by Ctrl+C when you're finished typing, before you click the button to submit the form. Ctrl+A is a shortcut for "Select All", causing all of the text in the current field to become selected. Ctrl+C is a shortcut for "Clipboard Copy", copying the form text to the clipboard. Then, even if the form data ends up getting lost for whatever reason after you submit, at least you have a copy of your text tucked away on your local machine's clipboard, which you can just Paste back into the form to re-submit.
It would be nice if web browsers in the future would include this type of failsafe automatically by making a temporary copy somewhere of any text that gets submitted on a form. The user could then retrieve the data if necessary if something goes wrong after the form is submitted.
Update 4/16/2008: Looking back over this post, in the previous paragraph, there are obvious security implications locally caching data such as login credentials, a credit card number, or other sensitive data, especially since the user might on a public workstation. It might be overkill for this problem, but perhaps the HTML standard could be extended to allow a particular form field to be marked as non-sensitive, which would be an indicator to browsers that the submitted data could safely be locally cached in an insecure fashion?
Here's a quick tip on a command-line shortcut that I've found myself using a lot since discovering it.
At a command prompt, type:
start . This opens a new Windows Explorer window at the current directory location of the command prompt.
(This is usually better than typing explorer at the command prompt, which also opens a new Explorer window, but at the default directory location instead of the current location.)
I just added a Utilities page to my homepage, offering for download a couple of general-purpose Windows utilities that I'd written previously.
The first is vdf ("Virtual Directory Find"). This command-line utility returns the physical path location of a specified IIS virtual directory on the local machine.
The other is BoundsTest, a GUI utility useful for obtaining rough measurements in pixels for the size and location of on-screen items.
Earlier tonight, I was testing some C# 1.1 code that gets the physical path to an IIS virtual directory. I ran into a problem where for certain virtual directories on my test machine, a System.Runtime.InteropServices.COMException was thrown when trying to access the System.DirectoryServices.DirectoryEntry.Properties["path"] property for the directory's DirectoryEntry, whereas for other virtual directories, the code worked as expected.
After searching around using Google Groups briefly, I came across a microsoft.public.adsi.general post that ended up leading me to the answer. The post mentioned a property called "KeyType" of which I had been previously unaware.
Apparently, there are (at least) two types of IIS 5.1 virtual directories. The standard type has a DirectoryEntry.Properties["KeyType"] value of "IIsWebVirtualDir".
There is also a second type, which has a KeyType value of "IIsWebDirectory". Such virtual directories show up in inetmgr with the usual "virtual directory" icon (not the yellow "plain folder" icon) in the folder list in the right pane, but in the Properties dialog on the Directory tab, the Local Path field is disabled for such directories.
For "IIsWebDirectory" type directories, an attempt to access the DirectoryEntry.Properties["path"] property for the directory (to get the physical path to the directory) results in the System.Runtime.InteropServices.COMException ("Exception from HRESULT: 0x80005006") being thrown.
I ended up working around this issue by assuming any directories of type IIsWebDirectory are located under the root IIS virtual directory (for which DirectoryEntry.Properties["path"] does return a valid result). Unfortunately, I wasn't able to turn up any documentation on IIsWebDirectory-type directories to verify this assumption, but it seems reasonable given that the Local Path field in inetmgr for such directories is disabled.
A few months ago, I replaced my old non-wireless Linksys router with a new Linksys Wireless-B router. At the time, I wanted the router so that I could get online with my PocketPC around the house. I also subsequently got a TiVo as a Christmas gift (thanks Dad!) which uses the online network to talk to the TiVo server out on the Internet to download new schedule information.
Earlier this week, my PocketPC stopped working on the wireless network. It could see the router with no problem with "Excellent" signal strength, but it was apparently unable to get an IP address; it reported a 169.x.x.x address instead of a real 192.168.x.x address.
Unfortunately, the PocketPC provides very poor error reporting when it has a problem getting on the network -- no error message any more detailed than "unable to connect" appears.
I tried assigning the PocketPC network card a static IP address instead of having it dynamically pick up an IP from the router. With the static IP, I was able to get online successfully, which seemed to indicate that the issue was with the DHCP server. I didn't want to leave the static IP in place, though, since it would mean that my PocketPC would be unlikely to connect successfully on wireless networks other than my own.
After looking at many other settings in the router's browser-based configuration application, I took a look at the Wireless Client MAC List under Wireless | Wireless Network Access. My PocketPC did not appear on the table, but the TiVo appeared, with an IP of 192.168.1.152. This tickled my memory; I remembered seeing on the main page of the config app that the router's DHCP was set to assign up to 50 dynamic IPs, in the range 103 through 152 (with 100 through 102 being reserved as static IPs for my desktop machines).
I returned to the main page in the config app, and extended the count of available DHCP IPs from 50 to 100, in the range 103 through 202. Immediately after saving this new setting, my PocketPC was able to successfully get a valid IP! It got 192.168.1.154 (skipping 153 for whatever reason).
So as far as I can tell, the problem is that the router assigned dynamic IP addresses (as the leases on existing addresses expired) in sequence starting with 103 and eventually reaching 152. Instead of wrapping back around to 103 as I would expect, it apparently just decided to quit assigning new dynamic IPs at that point!
Is this a bug in the router software? The status page reports that the firmware version is "1.50.14, May 27 2004". I may need to look into whether an update is available so I don't run into this issue again once the router issues another 50 IPs and reaches the new cap of 192.168.1.202!
In the meantime, though, between troubleshooting this issue and typing up this post, it's past my bedtime, so any further investigation will have to wait until another time!
On my dev team at work, we still use Microsoft Visual C++ 6.0 to build and debug several of our server components. The VC++ debugger does not inclue a mechanism for viewing long strings -- the Watch panel is limited to showing the first 252 characters of a string.
I found a nice VC++ 6 add-on this afternoon that allows an entire string to be viewed and/or copied to the clipboard, called StringWatch. The author's homepage for the add-on appears to be no longer available, but the add-on is available from this page on CodeGuru.
Installing the add-on was a painless process -- I just followed the instructions given in the included index.html file. I didn't need to restart Visual Studio or even end the debugging session that I had in progress.
I'd recommend this add-on to anyone who needs to view long strings (such as SQL or MDX statements) while debugging in Visual C++ 6.
While I was on hold with Microsoft support recently, I decided to download and try the new public beta release of Microsoft Internet Explorer 7 on my test machine.
Overall, it feels a lot like a Firefox clone -- which isn't a bad thing. Firefox 1.5 has recently become my primary browser of choice for all pages and applications except for those which only play nice with IE. Prior to switching, I had used IE 6 for everything. (I had briefly tried Opera 8, but I ended up dropping it because it locks up my work machine for about 10-15 seconds while it is first starting up, and it doesn't support some keyboard shortcuts supported by IE that I tend to use automatically such as Ctrl+Enter to prepend "www." and append ".com" in the address bar -- Alt+d, "google", Ctrl+Enter takes me to the http://www.google.com site.)
One thing that I don't like about Firefox 1.5, however, is the behavior of Ctrl+Tab. When there are 3 or more tabs open, then repeated presses of Ctrl+Tab activate through each tab in order. Unfortunately, the IE 7 team has dutifully cloned this behavior in the current beta version of IE 7.
The behavior I would want to see is having Ctrl+Tab work like Alt+Tab does in Windows -- a press of Alt+Tab activates the most-recently-used window, not just the "next" window. This makes it very convenient to rapidly switch back and forth between 2 windows that I'm using at any given time.
There is a good Firefox extension available to fix the Ctrl+Tab behavior, LastTab. I'm willing to install LastTab on each of my machines since (1) FireFox makes it so painless to install extensions, and (2) I'm aware that any machines other than my own are not likely to have Firefox installed so I'll just be using IE on those machines anyway.
However, as soon as IE 7 is released, it is likely to become the new corporate standard at most businesses. For this reason, I would like to see the IE 7 team get the Ctrl+Tab behavior "right" by default, so that when I'm using someone else's machine I can Ctrl+Tab between tabs without being annoyed by the behavior, regardless of whether it might be easy to fix the behavior on my own machine by using an extension.
One thing that I'd like to blog about in this space are useful keyboard shortcuts that I come across. (I favor working with the keyboard as opposed to the mouse when it makes sense to do so, as it is often more efficient.)
One shortcut that my brother (Jeremy, owner and developer of Rentlinx, and an overall very sharp guy) hadn't seen before that I showed him recently was Ctrl+Shift+Esc to bring up Task Manager (on Windows machines). This is a slightly quicker way to get to Task Manager than going through the security dialog that is brought up by a press of Ctrl+Alt+Del (on machines that do not use the "Welcome Screen").
Another more basic but very useful keyboard shortcut is the use of the Shift key to select text. Holding down Shift and using the arrow keys or other navigation keys (such as Home or PageUp) selects the text between the current position of the caret and the new position. Holding Ctrl+Shift along with the left or right arrow selects an entire word at a time.
Selecting text with the keyboard in this manner is often faster than selecting text with the mouse, and can be more precise as well, particularly in applications such as some Microsoft Outlook versions where the app annoyingly (at times) attempts to be "smart" about selecting text and automatically selects to the end of the current word when you are midway through selecting the word, which in some cases is not the behavior you want.
A minor pet peeve of mine is how parenthesis are commonly used in conjunction with emoticons in Internet postings. The author will insert a parenthetical thought into a sentence, and want to associate a smiley with the thought. Most posts that I've seen do it like this:
"... so I got home from work at 5:15 (if only I could get home that early every day! :)"
The problem with this is that the parenthetical statement is never really closed. The ')' character at the end of the sentence is the "smile" part of the emoticon, and it seems awkward to have it act as the closing parenthesis character as well.
As an alternative, I would suggest the following:
"... so I got home from work at 5:15 (if only I could get home that early every day!) :)"
In this version, the parenthetical statement is closed properly, and the feeling that the author is trying to convey by use of the emoticon still comes across clearly, even though the emoticon is located outside the parenthesis.
For a while now, I've been wanting a space to record thoughts I have on technology and related things. Well, the time is now, so away we go!
My motivation for finally getting this started? Earlier today, I read one post too many where the author closed a parenthetical statement with a smiley (like this :), so I've decided to do something about it! Or at least set up this blog to make it easier for me to conveniently rant about such things in the future, regardless of whether anyone might actually be reading!
For now, I'm setting up shop here on Blogspot. Eventually, I'd like to move this to a location that I host myself (as I do with my homepage), but this should do fine for now! (Blogspot was the convenient choice, as my wife Missy and I also have our Pregnancy/Childcare Blog here.)
|
|