|
I guess what I don't understand is how doing it dynamically is of any benefit.
I don't know about Aaron's situation, but I can dream up uses for it.For example, my HTTPAPI software is designed to work with the Expat XML parser if it exists on the system, and not do XML parsing if it's not there. Right now, if a user wants to add or remove XML support, they have to recompile HTTPAPI.
If I wanted to do it so that they didn't have to recompile it, I could have HTTPAPI check for the EXPAT service program at runtime. It could even search for it in the library list, or in typical locations. If found, use it. If not, don't. That way, the user wouldn't have to re-compile (or, at least re-bind) HTTPAPI after installing EXPAT, or after removing it.
Similarly, I might create a report writer software. It may call service program routines that do the actual writing out to the spooled file. These routines could be dynamically bound.
In a few months, I could create an add-on service program that wrote the reports to PDF in the IFS, instead of a spooled file. I could distribute this new "PDF driver" to the customers, and just by copying it to the right library on the system, it'd automatically pick it up and use it.
Next time around, I could write an HTML output module or PostScript or whatever, and I wouldn't have to re-build the whole software, just send them the one module and it could bind to it dynamically.
Indeed, this might make a nice model for selling software. Buy what you need, and if you need more, buy that module later. Pretty cool.
In fact, that's how hardware drivers for Windows typically work. When you buy a new printer and install the printer driver, what you're really doing is copying a "service program" (though, they're not called that on Windows) and a registry entry that contains information about it to the Windows system. When a program tries to print (or output video, or audio, etc) using that driver, it calls the routines in your "service program." (or, DLL in Windows lingo)
That way, hardware manufacturers have the freedom to design their hardware any way they like, as long as they're able to write software to interface with it.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
