This is where I place my more random ramblings. Some of them may be fairly permanent, while others are transient. Anything truly worth chiseling in stone is likely to get its own page.
FWDiscus has been updated several times recently.
Somebody asked in a VB forum site how to have one VB program execute another one sitting over on another computer. It seems he had some long-running process he wanted to split off as a second program, and then have the original one kick off the new Program B over on the "server" computer.
Since he had a file share of some sort to drop "work input" files into and pick up "work output" files, he just wanted to be able to remotely execute Program B from within Program A on his "client" machine.
He didn't want to mess around with DCOM, an obvious answer. He also didn't want to try MSMQ Triggers, which could be another great way to do what he wanted.
A low-impact solution, which he finally accepted, was to run the Telnet service on the "server" machine (both machines were Windows XP Pro). Then by using a simple free Telnet component from Dimac, he could have his Program A Telnet over to the "server," log on, and START Program B.
This got me wondering...
In any case, I decided to bite the bullet and give it a shot.
By writing a "server program" in VB as a command-line program, it would be possible for a "client program" to Telnet to the server, log on, fire up the "server program" with command-line parameters, and from there communicate back and forth via text streams.
This would let you run a single service (Telnet) listening on a single port, yet have clients be able to invoke any of some arbitrary number of "server" applications on that "server" box. This could beat the heck out of the usual crap where you write server applications as Winsock servers, each one needing its own port, needing to be fired up or built as NT Services, etc.
It also seemed like a good way to have such server applications be available via the public Internet, after all you only need to expose one port.
Ahh, but what about security?
Well this is where SSH comes in. One of the main things SSH provides for is a very Telnet-like service, over an encrypted channel. It can also use simple public-key authentication. All without the need for clumsy, pricey SSL certificates and such!
It turns out there is even a free SSH service for Windows now: freeSSHd.
No, there isn't any free component a VB program can use to "speak SSH" like the one from Dimac does for Telnet.
But there is a free utility called PLink that is part of the free PuTTY package.
PLink is a command-line Telnet, "raw," and SSH session utility. It is intended for command-line operations, especially from within scripts and CMD/BAT files.
Wrapping PLink in a VB6 class I wrote called CExec lets me write VB programs that fire off a copy of PLink and communicate with it via standard streams:
Well I have a simple application written and it seems to work just fine.
Clearly there are scalability issues, for example every client runs a unique instance of the server application. But that is no problem in many situations. Consider the flexibility!
One could even write the client as a thin "web based" presentation layer by hosting IE in a form, and pass all interactions back and forth with the server using HTML plus some headers. The client could be a regular VB GUI and pass XML back and forth. Lots of possibilities here, including using a fairly thin "server program" that calls a multiuse ActiveX EXE behind it - gaining some user-to-user communication capabilities or single-threading your way out of sticky concurrency problems.
I hope to have a more detailed writeup posted here soon.
Here's an interesting subject with a tiny thrill of the subversive to it.
You work in an organization that offers little in terms of workgroup collaboration tools, yet you have communication chaos arising from the use of scattered phone calls, emails, and ad hoc meetings. The parties involved are scattered geographically or you'd simply be talking to each other regularly. Sometimes everyone gets copied on the many brief emails, sometimes they don't. Sometimes the brainstorming gets collected from notes and emails for use in a project history document, sometimes the small points and decisions get lost.
Wouldn't it be nice if there was some tool to get a lot of this incremental discussion "on paper" so all parties have access to it? Maybe something that could be archived so that issues could be revisited later? Something like a joint "notebook" or (dare I say it?) a discussion board or forum?
What tools do we have in common? Let's assume the following:
One answer: Write an HTA using VBScript backed by a Jet database on the common file share to simulate a "web application" in the form of a BBS.
This can be a zero-install solution, requiring only the HTA, the MDB, and perhaps a cute ICO file for your HTA. Just copy them into some folder on the file share and everyone begins collaborating. No web server required!
Give the application a lock further comments option and you can simply zip up the whole thing for the project archives. For later perusal simply unzip the package into any folder and browse through it. No rogue server operation here, simply a "document" in a collaborative form. Jet manages update concurrency while the HTA glues everything together and provides the user experience. A user experience familiar to lots of Web surfers: the web-based forum site.
Well, I have an example available now as FWDiscus, a LAN (file server) based multi-user web application... with no web server!
