Since there is nothing on the Desktop Search page, here's something for it to get the ball rolling (and million thanks to Session Saver Firefox extension for making me NOT lose this thing =)
NOTE: I just realised the Left() usage pattern day before yesterday, and I only looked at one source that says something about this. I haven't yet researched it further, just that this one particular page said that StrCmp() is not a Good Thing and people should always use Left()/Mid()/Right() instead. What is the actual best practice in VB5? If I'm just bullshitting here, please remove that paragraph, but I'm posting this text, as I've so far written, for comments. Feel free to omit that paragraph for now if you put it to the web site; I'm not a VB programmer and this is probably just a tiny problem in an already giant big ball of WTFery...
---
Spectate Swamp Desktop Search is a multi-purpose application, incidentally not limited to (Spectate Swamp's definition of) desktop search. Spectate Swamp claims that the application is the best application ever made, but this is obviously more than a bit of a stretch. The application is highly problematic on almost all imaginable layers of software engineering, starting from very low-level problems like coding style, stretching all the way to the project management.
The program can be understood best if one looks at the functionality. The program can search text inside one specific file, and also highlight the context. The program can also display images and video clips. Spectate Swamp apparently uses the program to assist with his own tasks; he apparently maintains note files with it - the application can merge material from clipboard to note file, for example - and searches these notes, along with email and web clippings.
Coding style: Where do we even begin? SSDS code is a mish-mash of eye-straining ignorance of all good programming conventions. SS uses variable names that are not at all obvious, even based on context. (Examples: SSS, tt1 or tot_s1.) The comments are frequently not particularly helpful either; most of the commenting just comments out blocks of code or marks when the particular feature was changed (of which more later). Some of the comments are completely undecipherable and they don't explain what the code actually does in any meaningful way. (Example: code line: ttt = "RRR", comment: "testing only re the close of the file etc...").
The code also includes several passages that are, apparently, copied from examples as is; these are usually easily identified as they usually have meaningful variable names.
One point is that the code is riddled with one VB5 idiom: using Left() for string comparison. While this is apparently a practices of VB5 (StrCmp() function is discouraged because it needs to do some very slow memory allocation), Left(buf,bufLen) comparisons are done throughout the code with no encapsulation whatsoever, possibly allowing bugs to creep through by using wrong buffer lengths.
Architectural choices: The program goes against all conventions of modern software design, which encourages breaking the program in modules - generally, the smaller the better. The bulk of the SSDS program is in a massive text2_Chg() subroutine, and all program flow within is managed through goto commands. While goto commands were the norm in old Basic dialects, they are severely discouraged in new, structured Basic dialects such as Visual Basic. SS makes this even worse by using deliberately obscure labels: Modern Basic dialects do not use line numbers, and instead allow the programmer to use arbitrary goto labels, so SS brings back the line numbers by using labels like "line_20". In his statements, SS has vehemently defended this spaghetti coding.
User requirements, expanding possibilities, and definition of the problem the application is trying to solve: SS claims SSDS is a "desktop search" application. However, SSDS qualifies as "desktop search" only in SS's own definition and when using SS's own computer usage patterns; it does not qualify as a "desktop search" application in any other definition of the term. In most definitions, a "desktop search" system indexes the user's personal files, extracts metadata from the files, and allows the user to perform searches on this metadata; for example, "songs by a composer called John" or "instant messaging conversations that mention pizza" or "email about Project X". SSDS, on the other hand, requires the user to convert all data to plain text format, thus losing all formatting and metadata, and merge everything in one file. For certain operations, the user is required to maintain such index themselves. Further, ordinary desktop search systems allow the user to see all metadata, such as "this matching song is 4:33 long" or "the last pizza conversation took place yesterday" or "the boss mailed to you about Project X using Microsoft LookOut, the bastard"; SSDS only allows you to see matching likes in SSDS index file. For example, if you search for "Project X", it is difficult to see when, by who, and (for example) with what program the e-mail was sent with.
At best, SSDS is a simplistic linear search application that attempts to match search terms against a text file - and with extra features that allows the user to show images and videos, also in random order.
SS also seems to completely ignore the definitions in question.
User interface design: SSDS has been designed to mimic - badly - the command line environments. The user enters abbreviated commands, and results are displayed in text format in the main window. This completely ignores all features VB has for building simple, intuitive and modern graphical user interfaces.
It is not even a good command line environment. All commands are entered through Visual Basic pop-ups, with little intelligent parsing done. The commands are cryptic, and often chosen based on SS's ideas of "speed", and thus grouped together. For example, the "SS" command starts a screen saver mode, while "TT" and "WW" are also screen saver modes with different modes of operation. Understanding the commands first requires the user to understand SS's logic in choosing these particular command names. The user interface is also not in any way discoverable - the user can't be expected to find out what the commands do by themselves or by lucky guess, and the only way to find out what the commands do is to look at the more than occasionally cryptic help text that does not explain the commands in sufficient detail.
Platform choice: SSDS is implemented with Visual Basic 5.0, which is a very old version. Apparently, Visual Basic 6.0 (the last non-.NET version of VB) cannot compile SSDS due to VB6.0's "limitations" in size of functions; however, these "limitations" simply mean that VB6.0 is pickier about coding style, and properly engineered applications would not run into these limits in first place. The choice of Visual Basic also limits the possibilities of the "open source" development that SS wanted, because Visual Basic is a proprietary language and not widely used in open source community.
SS also claims SSDS is a multimedia player, and it can indeed play video files. However, it uses Windows Multimedia API and the Windows Media Player to do the actual heavy lifting. Implementing a media player shell is a relatively simple and straightforward matter using the Windows APIs in question, and it is unlikely this feature alone is a selling point. It also makes porting difficult to other operating systems.
Source control and distribution: SSDS does not use any form of source revision control. In most software development projects, source control is used to maintain revision histories of files; it is useful to document all changes to the system, access past versions and to roll back mistakes. It also makes distributed development by several developers easier, as it makes sure all conflict situations are detected properly - if two people change the file at the same time, the system detects it.
Instead of source control, SS relies on commenting out unnecessary code, and using comments that have dates on them to explain when the specific code line was added. While this is a natural thing to do in absence of source control in situations the programmer also wants to retain old code and remember when the feature was added, it is a bad idea from maintainability point of view: it adds unnecessary clutter to the code and makes it hard to follow.
Further, the development project itself isn't packaged in any way. It is a norm in Visual Basic development to use project files which store all of the relevant non-code information about the application (form designs, build options, executable information, etc), but apparently SS is only distributing the actual source code, as "source.txt", and distributed a video (LINK HERE) that shows how to set up the VB project and form controls. The process is cumbersome in itself, and there is no indication of whether or not SS also follows this method himself.
Development management: SS seemed to be very enthusiastic about getting people to develop the application in "open source" style. However, he later dismissed it all after doing development following the usual open source conventions became too difficult for him to handle. Following the suggestions of other people, he set up a project on SourceForge.net (LINK), but failed to do anything else on it. Development at SourceForge.net requires, at minimum, that the project manager - by default, the person who registered the project - adds other would-be developers to the project and allows them to check in source revisions. He could have even added another user as a project manager to handle that aspect for him, requiring absolutely no other work from him. Instead, he ignored all requests to help, even from one TDWTF user who volunteered for management.
Communication and documentation: Modern software engineering relies heavily on proper documentation, all the way from design documents to end-user documentation. Source code should be appropriately commented, which allows comprehensive documentation to be built automatically, and other design choices should be documented extensively. There are several diagramming methods and practices (such as UML) to further allow easy explanation of the higher-level structure of the program. While it is understandable that individual developers - such as SS - do not use such extensive documentation for projects of their own design, SS seems to particularly eschew such documentation, even if it would help others to understand the system. Even his attempts seem to have failed. He seems to believe the source and flowcharts of highlight logic he has made is all that is needed to describe the program. However, the flowcharts, like the program itself, are very cryptic and do not help to explain the logic and design choices used in the program.