Back in the day- the bad old Dark Ages, which is to say about a year and a half ago- I did most of my programming in VB6.

I know, right? Anyway, as a result some of my older programs are, not surprisingly, written in VB6. One of these is BCSearch. this program works alright, to the point where I actually use it myself just fine. But it has quite a few issues.

• It crashes more often then it should

  This is mostly a result of the way I work in VB6- which is not at all safe. VB6, and the applications it creates are designed for the late 90’s, with Windows 98SE and Windows 2000. Windows XP, Vista, and 7 are practically like being flung into the far future and being handed a plasma rifle. This means that you have to do all sorts of hacks- from including manifest resources (which itself requires a hack, using the resource compiler yourself rather than the resource editor), to using custom controls to workaround limitations and omissions of controls like the ListView control, or, equally common, dropping to various Windows API functions, Shell functions, or even direct COM vtable fiddling to get the functionality you want. I touched on the iterators limitation of VB6 previously in my iterators discussion. One of the biggest workarounds is to the fact that VB6 is simply not designed for multithreading. Any multi-threading and most asynchronicity is going to require disgusting hacks. BCSearch, for example. When you click Start to begin a search, the UI still remains, — or at least, it tries to remain — responsive. You can still resize columns, right click results, stop the search, etcetera.

  Most of the issues with BCSearch and crashing come right down to this. My method to get this ability is to use a Win32 Timer and pass it the address of another routine, which then begins and executes the actual search. I’m not 100% certain as to why, but for some reason the two contexts of execution remain mixed; my experience on this seems to indicate that when I do it that way the program will do it’s thing, but then “stop” if the user does UI tasks. It is a very curious behaviour. It’s not quite multithreading, by any metric, but it’s still confusing at least as much to programmers using VB6 as it is to VB6 itself. This causes most of the crashes, simply because the language has no support for locking or mutex-like behaviour.

• It’s a pain to work on

  Because of the above hacks and work-arounds and gross code, the program is actually quite annoying to work on. A lot of it is modularized into classes, but VB6’s classes are extremely limited in capability.

• It’s Visual Basic 6

  I mean. Come on… It’s Visual Basic 6. The Language is limited, the library is limited, and the entire system and ecosystem is nearly a decade and a half old and is only clung to by a few die-hard advocates who throughout the years actually built their entire careers on VB “Classic” knowledge and memorizing it’s stupid and ridiculous idiosyncrasies. Of course once MS fixed those retarded behaviours, their information and knowledge became useless, so they pulled some argument that they were “breaking backward compatibility” and “this will cost companies millions”. Well, maybe. But Considering some of the rates those people were charging for their VB consulting services I don’t really see how they would have saved money otherwise.

Anyway, I digressed a bit there. What prompted this post was a quick little app I wrote to quickly experiment with the new Async features of C# 5. The goal was pretty simple- attempt to parallelize searching a directory tree.

It’s probably not the best use of asynchronous features, given that by definition going through a directory tree is going to be pretty I/O locked rather than depend on CPU speed or utilization, however it seemed like a reasonable start. The technique was actually quite simple.

Basically, what I ended up with could pretty easily be improved and extended in a myriad of ways to faciliate the creation of a new Search program in C# comparable to, faster, and more stable than the VB6 version.

Whether it will is probably another story, of course- since it’s just a very simple little class at the moment. However in experimenting with async I may just decide to branch out and create a full-fledged WPF program out of it.