In case anyone is wondering why I felt it necessary to write yet another file verifier, the answer is simple. At the time I did not know about any others. Well, I knew there were some but I thought those were for DOS.
Since I and a few others like Hamp and Marky Maypo felt the need for one, I decided to write one. At first the intention was to do one in Java, but unfortunately the Java 1.1 SDK would not install on my system. A problem which has been fixed with the recent release of the Java 1.1.1 SDK. So no Java release for the first version.
But I also needed to testdrive a new development environment as well as to verify some problems with the StringGrid that holds the list of files. Those problems, b.t.w. have been verified which is why there is no color highlighting. Furthermore I was looking for an opportunity to write some multi-threaded program and get hands on experience with Win32's memory mapped file mechanism. In short, it became a Win32 program.
Since this apparently might be seen as a critique on the work of others, let me assure you that this is not the case. For the simple reason that I did not know of those other programs. Nor have I seen those programs or know their authors. Furthermore I respect anyone that writes programs (and other items) for free distribution. Period.
In fact it was only after the point of no return had been reached that I stumbled across an article posted on the Usenet that listed available resources. But by that time it was too late. So I can only go forward now. But I will, again out of my own need, switch to Java now that the SDK installs, as well as maintain this release. Again this says nothing about the respective merits of the languages in question. I merely need some hands-on experience with Java. [Besides, there is no language that even comes close to my own! (Joke, btw, all functional languages are sort of equal)]
The same holds true for the other utilities as well. I am always testing out new things and writing little things I need. For me it is often quicker to just write something I need then to take the time to go out and find a thing that resembles it. Besides, when I write it myself I can make it as I would like it to be. Most important of all is that by writing an utility you learn, get experience with the technology involved.
Some of the junk I continuesly write might come in handy for one or two others as well. So, why not release it for those two to play with? Again, this is not saying that whatever else is out there is even worse than what I produce. I am merely saying that I write stuff for selfish reasons anyway, so I might as well let others have a go at it.
This way of releasing is an experiment. Though I have shared programs before, they were usually for fellow programmers. Mostly source code, though I have, some years ago, tried my hands at a shareware utility (also in source for programmers). Didn't work out and the administrative burdens involved I really, really dislike. Writing docs is bad enough.
So I have yet to see how this works out. Just keep in mind that I am an engineer and researcher, both professionally and at heart. That does not mean I am infallible, know a lot or can do miracles. It just says that I like to fiddle with things and see if I can figure out what makes them tick. This site holds some of the more practical results and describes what little I know of the topic.
If I do include names and such (don't worry, no email adresses), then that is because it is what I am supposed to do. The results I jot down must be verifiable by others. Otherwise I might as well suck on my thumb and write down whatever inspiration I got out of that enlightening experience. It might make for a nice bedtime story but it will do nothing for advancing the state of the art.