Size problem

Mon Jan 13 13:46:00 GMT 2003

>> No, not at all. It's a perfectly reasonable way to construct an
>>application.
>>> How would he know that there were 20 executables? It's just a way of
>>> building an application.

Passing information between executables is a bit more difficult than passing
references (or primitives) within the same process; especially when they are
tightly coupled. You'd either have to pass things over the command line (cum
file system), or else you need to introduce a network protocol. Unless you
need process isolation for other purposes, or inter-machine communication,
which requires a network protocol anyway, I'd stick to the simplest
solution.
y = f(x)
is a simple thing to do within the same process. Doing the same thing across
processes or machines requires marshalling/demarshalling, involving
serialization, in one form or the other; x and y could be relatively complex
hierarchical document types, that are not even simple to describe; and
regardless of any advocacy for a particular protocol, it's never really
transparent.
For example, just try to pass an abstract syntax tree between two
executables, over the command line. It's probably easier to pass the source
and parse again at the other end. In such case, you may as well integrate
both executables into one process space, pass a reference, and spare your
application from re-parsing.
When it's needed to institute interprocess communication between tightly
coupled subsystems, I do it; otherwise, I stay clear of it. Therefore, these
typical windows applications with 20 forms or more, targetted at typical
windows users, would not necessarily benefit from being split into 20
executables.