Many interpreted languages feature an ``eval'' or ``exec'' command which allows a program to execute an arbitrary string (including one that is obtained or built by the program at run-time) as though the string were part of the program itself. Perl, Tcl/Tk and the Unix shells all have this feature. Visual Basic, however, lacks it. If the core of the sniffle system were written in a language which supported eval, the client could submit ordinary programs in this language and the server could simply eval them. This would provide a much more elegant solution than the current scheme and would give the client-end user a much more powerful way to control the server-end I/O board. The client would be able to submit a true program to the server, rather than merely a series of commands. Programs could contain conditional statements and variables and could therefore cause the I/O board's output to respond to the board's inputs.
To the best of my knowledge, however, the subroutine libraries supplied by Analog Devices and other I/O board manufacturers do not support any language with eval/exec. It might be feasible to hack a way around this problem by using e.g. a Perl script as the cgi back-end to a Web server and having the script invoke small supplementary programs written in C or Pascal to accomplish low-level board control tasks. A DOS version of Perl is available and can be used with WinHTTPD. Beware, however, that the author of WinHTTPD strongly discourages the use of DOS programs as cgi back-ends, as these must be run in buggy virtual DOS machines under Windows.
The right solution probably involves extending an interpreted language (e.g. Perl or Tcl/Tk) by adding commands that control the I/O board. Rumor has it that it's fairly easy to roll your own C code into Tcl/Tk in a Unix environment, and this sort of splicing might be equally straightforward in on a PC. Tcl/Tk is available for MS-Windows and a wide variety of other platforms. Read all about it at http://cuiwww.unige.ch/eao/www/TclTk.html. The more I think about it, the more I wish I'd thought of this two months ago. (Caveat: serial communications are probably not nearly as easy in Tcl/Tk as in Visual Basic.)