Terminally Incoherent

Apparently there is something to be said about short blog posts. Allegedly I tend to get long winded sometimes and my posts can run a tad verbose sometimes. I usually tell people to STFU and go read Steve Yegge if they want to see verbose. I’m short, concise and to the point compared to him. But I figured that I’ll try some of that short blog post thing that people seem to be enjoying in other parts of the web. So I’m making a post about a silly little windows command. This is so that I don’t forget it about it next time I need it.

Have you ever needed a file of specific size to test something but you didn’t care what that file was? You know, just a space holder or a space filler kind of a thing? This is what you need to do to create one on Windows XP:

fsutil file createnew file.ext 10000

Naturally file.ext is the desired name of the file you want to create, and the numeric argument is the desired size in bytes. Note that fsutil creates a sparse file which means that this operation will be blindingly fast. For example it took about 3 seconds to create a 10GB file on my elderly windows machine.

Useful trick. I sometimes use it to see how a given app will act when it encounters a file of certain size. To accomplish the same thing in linux you apparently need to do something like:

dd if=/dev/zero of=my-file bs=1 count=0 seek=10G

I messed around with it, and the bs and count are important so don’t just skip them. The seek attribute specifies the desired size of your file, and here you can use human readable units (like 10Gb in the example).

So if you ever need a file of a specific size to test something, here is how you make one. How is that for a short post? What do you mean 350 words is not short? Ah, go to hell then. I tried. Next post will be verbose again.

Recently I plopped an old laptop running a stripped down version of Ubuntu onto my home network. I joined it to the local workgroup and gave it a NetBIOS name so I could ssh into it from the windows machines without having to remember the IP address. In the past this has always worked for me, but this time around I noticed something weird. When I tried to ping the machine from within windows the local address was resolving to some remote ip:

>ping elder
Pinging elder.hsd1.nj.comcast.net [208.67.217.132] with 32 bytes of data:

Initially I thought that I simply messed up the entries in smb.conf but this was not the case. To my dismay I realized that this was happening for EVERY machine on my network. I could not ping grendel, I could not ping eoran, I could not reach malekith and even myprecious (don’t ask - it’s not my machine) was out of reach! What the fuck in hell?

Quick whois lookup gave me the culprit: OpenDNS which I have been using as my primary DNS provider for quite a while now. I’m not sure why this issue started right now. I don’t remember seeing this problem ever before. Nevertheless it was there and I suspected it had something to do with the OpenDNS auto correction which fixes typos in your URL’s and redirects you to a search page whenever it fails a look-up. I was always a bit skeptical about that particular “feature” but I didn’t really mind it as long as it did not interfere with normal day to day operations.

This issue really boils down to the way Windows does domain name resolution. It works like this:

1. First it checks the HOSTS file.
2. Next it Queries the DNS server(s).
3. If all else fails it falls back on NetBIOS.

In my case, step 2 would never fail because it would successfully resolve to that weird remote ip I shown you above so it would never even try to use NetBIOS. This was an issue because I really did not feel like setting up a local DNS server just to be able to access local machines. I mean, I could but I don’t really have a spare box to devote to this task, and also it would be silly considering that up until now I was happily relying on NetBIOS names for this sort of stuff.

There only one quick solution could think of: stop using OpenDNS and switch back to the servers provided by my ISP. But I did not want to do that. There is a reason why I started using OpenDNS in the first place - not only is it faster, but also more reliable than whatever Comcast had to offer.

The Real Solution™ required some digging around in OpenDNS docs. Apparently you can disable the auto correct feature if you register your network on the OpenDNS website. The process is very straightforward - you create an account and then associate your external IP with it. Once you do that, you can disable, and reconfigure all the “questionable features” that come with the service.

I’m not terribly happy with putting my IP address in their database this way, but then again I have to remind myself that they already have my IP showing up many many times in their logs so there is probably no difference here.

The changes took effect some 5 minutes after I registered and disabled the typo correction. Now I can ping local machines again without any issues. So if you are using OpenDNS and you suddenly find yourself cut off from your local network consider registering, or dropping their service.

Sigh… I wish some of these features were opt-in instead of opt-out. But I guess they are trying to make their service idiot friendly and idiots do not opt into or opt out of anything that ever remotely relates to technology.

This is hopefully the last post from my VBA Purgatory cycle. This time around it is a rant about one of the more infuriating little bugs in MS office namely the lack of scroll wheel support in the built in VBA editor. I have no clue why that little editor doesn’t work with the scroll wheel when the rest of the office does. It makes no sense.

I read somewhere that this may have something to do with mouse drivers you are using. Apparently some of proprietary MS drivers do work. I currently use MS Sidewinder and I can confirm that the scroll wheel works in the copy of Office 2007 that was graciously provided to my by the CS department at my university. On my work laptop however I use Logitech VX Revolution with Logitech drivers installed on the XP running inside a VM and the wheel doesn’t work in Office 2003.

Two things may be happening here. Perhaps MS finally fixed this issue on 2007 version of their product (and about time damn it!) or it is indeed a driver dependent thing. Either way, most of office users are still on 2003 because the ribbon interface sucks total ass until you get the hang of it. I’ve been using it for over 2 semesters now so it makes no difference to me - just another interface I guess. I can find my way around easily, but I noticed that learning new UI is akin to the end of the world for some people. Also not everyone owns a MS mouse so I set out to find a solution to this issue.

As you can suspect, there are millions of google hits for the VBA editor scroll wheel query. I found that Daily Dose of Excel had the broad range of solutions to this issue. It pointed me to a MS Knowledge Base article which apparently claims this behavior is by design, but also offers two workarounds one of which is the download VB6MouseWheel.EXE package which may (but doesn’t have to) fix it for you.

If it doesn’t work, the Daily Dose blog recommends 3 software solutions that are targeted specifically at VBA. Some are more configurable than others and may offer additional functionality. Personally I recommend the last one - the Scroll Wheel Fix for VB6 (and others). While it is the least configurable of the 3 it is also the only one which is published both as binary and as source code. And this is not just the security freak in me talking here. After all I did not go through the code line by line to check for shady stuff. It’s just that the act of making code available is praiseworthy, and I want to support the guy who releases his solution to the world rather than just posting a binary on his home page bragging about his awesome haxin skills.

Also, the solution doesn’t seem to be that incredibly complex. I counted a little over 500 lines of code in the source. While it is a sizable chunk of code, it doesn’t seem like a complete show stopper of a project that could not be included in each of the successive releases of MS’s flagship product. To me the fact it was never fixed indicates that no one at MS actually cares about the VBA editor. They know full well that the core users of their product never will actually see it. The only people who will work with it are the poor souls forced to write macros as a form of punishment by pointy headed managerial staff. And since they will loathe the task anyway MS sees no reason to actually make their life any easier.

Hi, I’m here to torture you with more VBA! Run away! Run away! This is part two of the tales from the Programmer’s Purgatory. And once again, no it is not hell. When you are in Programmer’s Hell you spend all your time in meetings, and/or doing team building exercises *shudder*.

This time I’m unloading few random snippets of code that I produced during my sentence in the purgatory. For example, there is a vba macro that is supposed to extract some data from an excel file with ~20 worksheets. The users need to be able to add new worksheets to it, or move and modify existing ones (that is an absolute requirement, and arguing about it is pointless) so you can’t really protect the workbook. There are really two ways to access any given sheet:

1. By it’s name: ThisDocument.Sheets(”Accounts Receivable 10″)
2. By position: ThisDocument.Sheets(10)

There is of course an issue here. If you try to call worksheets by name, the users will promptly rename every single one. If you try to get it by position, they will rearrange the whole workbook. It is a lose-lose situation and almost every day our helpdesk has this very conversation:

We decided to be tricksy Hobbits and added the following snippet to every single sheet in the document that should not be renamed:

Sub Worksheet_Deactivate()
    Me.Name = "The Name of the Worksheet"
End Sub

It’s funny because it is so subtle. They can rename the worksheet all they want, but as soon as they click on another sheet the name will just quietly revert to what it was supposed to be in the first place. No matter what they do to it, it won’t keep the new name. I imagine they will eventually give up, or call the Helpdesk and then we can tell them in our best BOFH voice “Read what it says in red on top of the worksheet. Do not rename!”

Of course techno-idioticus luseratis is the most ingenious animal on the planet. While they are unable to perform the simplest tasks in Windows or Office without assistance, they show almost limitless resourcefulness when it comes to circumventing the tricks we use to stop them from breaking things.

So if they can’t rename the worksheet they will delete and recreate it or do something equally silly. So we came up with an insidious way to make their life harder. Naturally, it couldn’t be easy because the fuckers at Microsoft decided that there is no reason to fire some sort of an event when a worksheet is deleted. I mean, who would ever want to capture such an insignificant event? No one, that is who.

So there is no real way of preventing the user from deleting a worksheet other than protecting it, or protecting the workbook but that naturally won’t work for two reasons. One reason is that they would often need to un-protect it in order to add/modify certain sheets. The second reason is that most of the time you can remove protection using tools like this one.

So we figured that we’ll just disable the Delete button on relevant Sheets. The user will still be able to get in trouble by moving the worksheet to another workbook, but at least the most obvious way to delete things will be disabled. This is a bit convoluted, but I blame Microsoft for not making a Worksheet_Delete method.

' Put this in it's own module or Workbook module
Sub DeleteButton(ByVal enable As Boolean)
  Dim CommBarTmp, Commbar As CommandBar
  For Each Commbar In Application.CommandBars
    Set CommBarTmp = Commbar.FindControl(ID:=847, _
       recursive:=True)
    If Not CommBarTmp Is Nothing Then _ 
      CommBarTmp.Enabled = enable
  Next
End Sub
 
' On each sheet put the following two subroutines:
 
' When browsing away, enable the Delete button
Private Sub Worksheet_Deactivate()
    DeleteButton True
End Sub
 
' When activated, disable the Delete button
Private Sub Worksheet_Activate()
    DeleteButton False
End Sub
 
' Add these two in the Workbook module:
 
' Enable the button before closing excel
Private Sub Workbook_BeforeClose(Cancel As Boolean)
    DeleteButton True
End Sub
 
' Enable the button when you switch to another workbook
Private Sub Workbook_Deactivate()
    DeleteButton True
End Sub

Note that you could use the Workbook_SheetActivate method to activate this behavior for all worksheets instead of using separate Worksheet_Activate and Worksheet_Deactivate methods. We didn’t do that because only some sheets need to be protected this way, while others are free game.

Finally, here is another frequent Helpdesk conversation that happens at least twice a day:

So here is yet another trick - we will forcefully save the document even if the user resists:

' Put all of these in ThisDocument module
Sub AutoOpen()
    WaitAndSave
End Sub
 
' Wait 5 minutes
Sub WaitAndSave()
    Application.OnTime Now + TimeValue("00:5:00"), "Saver"
End Sub
 
' Save the doc and wait again
Sub Saver()
    ThisDocument.Save
    WaitAndSave
End Sub

This way, the lusers can’t claim they lost 5 hours of work because Word sucks or because some macro crashed their Office or because there was a power outage. Now they can only lose up to 5 minutes of real work. I’m also considering combining this with the versioning feature of Word 2003 (and higher). This way if the user fucks something up they will be able to roll back their changes in 5 minute increments.

I hope you enjoyed this brief excursion into the terrifying world of madness which is VBA. Let’s hope there won’t be part 3, because even right now I feel that my sanity is slipping.

This is going to be a quick rant about usability. Recently I noticed that a lot of Windows XP and Vista users get very frustrated with their machine at boot time. This frustration stems from the fact that while their graphical desktop environment is fully loaded , their machine is not ready to be used yet. Let me walk you through a typical windows boot sequence:

1. The BIOS POST sequence:

2. The Windows Logo:

3. Potential Login screen:

4. Windows Desktop

Naturally, the fact that you see the desktop, almost never means you can use it unless you are running a pristine clean windows install that is. And even then, it still takes few seconds before the explorer becomes fully responsive. Most brand new computers come preloaded with a slew of applications that are loaded on startup. These include antivirus suites, search applications, notification services, vendor specific applications and etc. So it usually takes 10-15 seconds (sometimes even up to a minute or two) for all of them to finish loading. It seems that windows designers decided to render the desktop as soon as it was humanely possible to allow impatient users start moving their mouse around and click icons. Unfortunately this is not a perfect choice. While the user gets the control of the machine early, it will act extremely sluggish, unresponsive and in general annoying for the first few minutes of operation. This is extremely frustrating when you are for example trying to quickly boot up your laptop and show someone/print that important document.

I noticed that my Kubuntu machine does not exhibit such behavior. Instead, when I log in it shows me a KDE splash screen with a nice progress dialog which tells me what is being done as I wait:

KDE is not rushing ahead to show me a mostly unusable desktop as soon as it can render it. Rather, it patiently loads up all the components, and allows applications to start initializing themselves. When my graphical desktop pops up, the machine is ready and I can jump right into action. Part of this of course is the inherent division between the core linux OS and the graphical desktop environment that runs on top of it. By the time KDE starts loading, all the system daemons are already loaded and running, the X server has been initialized and the OS is fully operational. With windows this is not always the case. Some applications - especially made by Symantec and McAfee like to take their sweet time hugging the CPU and initializing for a long time after the desktop appears. What are they doing? Are they take all this time to build their unnecessarily flashy GUI’s all this time?

The reverse is also true. If you go nuts, and use exuberant number of KDE based tray applications and desktop widgets that start with the system you may get it to the point where it starts sluggishly just like your average Windows desktop.

I think that a splash screen which would delay displaying of the desktop and say something like “Loading Applications/Components… Please Wait…” and display a progress bar is a great idea - for any OS. I really don’t mind waiting a little longer during startup. How often do I boot my machine anyway? My laptop gets booted on average once a day. My desktop - once every two months maybe. Sometimes less often than that.

That’s just something that popped into my head while I observed users cursing and hitting their laptops while trying to do something really quickly right after rebooting them. To me, waiting for a progress bar is easier on the nerves. It gives the user an idea how long the process will take, allowing him to take a bathroom break, or maybe grab a cup of coffee and let the computer finish what it’s doing. When you show the user a seemingly functional desktop, but remain unresponsive it is almost like you were taunting him. Clueless users are usually not in habit of observing the HD LED or listening to the grinding noise to judge whether or not the boot process was finished as we do. They always try to use it to early, and get angry, annoyed or just roll their eyes with impatience.

But perhaps I’m wrong about this. Feel free to present counter arguments in the comments.