Using WBC Files

Question:

We have a set of utilities currently combined into a single WinBatch executable. From comments made on the board, and articles in the knowledge base, we are wanting to move to a more modular WBC format (allowing updates of one utility at a time). But if I am understanding things correctly, each WBC must stand on its own. In effect you have a single, master EXE that launches the appropriate WBC (command line parameter or however you want to pass that detail) and then processes its return code and exits.
This is very different than how we have done WinBatch for 8 years now so we are struggling with the concepts and want to make sure we are not missing anything. There seem to be no real communications between the master program and the called WBC, except through the command line. And as for returns, I assume you can return any single value you want in the Return( "value" ) format, but that is about it.

If anyone has any insight or good examples of how that took a program with multiple switches pointing to multiple routines and broke them out as WBC modules I would GREATLY appreciate it.

Answer:

I think the issue of breaking up a large monolithic script into a series of WBC files is worthy of discussion w/respect to improving the overall modularity of a program from a maintenance point of view. It even helps more if many of the modules are in fact unrelated to each other and thus you might like to upgrade individual components w/o having the recompile the entire script. The end result will be very much like the "WBCRUNNER" script that has been posted on here numerous times in connection with running WB scripts from a logon script over a dial-up connection. The goal is to reduce the execution time of the logon script by having a stub script compiled to a .EXE file stored locally on the computer while the logon script tells the stub to execute WBC files that are centrally located on the server which is processing your logon request.

Using a stub EXE file that simply parses its parameters and then calls the appropriate WBC file is not difficult to do. For the most part, here's the "gotchas" that come to mind:

Watch out for "breaks" in compatibility between WIL versions w/respect to the format of WBC files. For example, it is expected that the EXE file will have been compiled with a version of WIL that is as new as or newer than the version used most recently to compile WBC for use with the stub. Having WBC files compiled with a version of WIL that is newer than the version used to compile the stub EXE file could cause problems.
Watch out for those rare changes in format signatures between WIL versions and extender versions. I'm trying to recall if this has happened before with WIL; maybe it hasn't. It cerrtainly has happened with extender functions, however, so beware that if multiple WBC files used by the stub all use a common subset of extenders that one WBC file's requirement for a newer version of any particular extender may interfere with another WBC files dependency on an older version of the same extender.

About the only benefit I see from using a WBCRUNNER type of stub EXE is that in distribution you only have to push out WBC files and possibly updated extenders. With each script compiled to an EXE file, you have more files ot push out but then each script stands on its own as a separate EXE file.

One other possibility for the modular WBC approach would be if your compiled script supports some sort of customized plug-in architecture where it can call an arbitrary WBC file that does some customized work for the extender using an interface specification that was previously defined for said purpose. This would be akin to how extenderr DLLs are used by WIL itself.

Article ID:   W16396

File Created: 2005:02:18:12:20:22

Last Updated: 2005:02:18:12:20:22

Database Search

TechHome

Using WBC Files

Question:

Answer:

	Compiling XLS and Running as a Service
	Sample Code from Users