Hi Peter! ----- Original Message ----- From: "Peter Luijer" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Thursday, June 09, 2005 3:20 PM Subject: [list] RE: [delphi-en] Why are people surprised about applications that use multiple exe files?
> Hi Warrick and all interested, > > This is not meant as critisism, merely as a point of discussion. > > The fact that an "Application" uses multiple exe's that run > successfully for over 3 years, doesn't automatically mean that > it's, "code-wise", good written software. It also does not neccessarily mean that it's bad either... :-) (In fact, it say much of anything IMHO... see below) > First let me define the differences between a single "Application" > and an "Application with Helper utilities": > - A single "Application" should be a single functional executable, > without the need of other separate executables. > If there's any need for using "External" code, this must be done > by use of separate "Libraries" (written in any language): on the > Windows platform these are generally DLL's (and "family"). > - As "Applications with Helper utils" I define shell-applications > that rely on other executables that do all the work and these > are mostly driven by using stdin and stdout or by using some sort > of (temp-)file to let the external exe work with, which are both > very dirty solutions. There is also the notion of a distributed application, which Delphi supports in various ways, e.g. COM/DCOM, Datasnap/Midas, Webservices/SOA. Out-of-process (D)COM servers ca be (as you maybe know), .Exe files, and is a valid design/implementation technique to use, even on one machine (though of course one must consider the implications/consequeces of doing so.) Thus, it is perfectly valid to talk of an "Application" consisting of multiple EXE files. We for example have Multi-tier (three-tier, to be exact) application, consisting of a client, an app server, and a database tier. Conceptually this is a single application, even if it is physically spread over 3 tiers. We can thus just generically talk about this "application", and take it as read that this might refer to the entire triad of physical applications, or to one of the tiers, as is appropriate to the context of a discussion (typically a "server" or "client" qualifier clarifies which you're referring to, when necessary.) You might argue that this should be called a "system" rather than an application - maybe so, but I think that gets very close to semantic hair-splitting. I think it's probably best not to get too pedantic about the meaning of "application", and to apply common sense when interpreting it (using context.) The point is that IMHO the exact outlay and presence of single/multiple instances of .exe files and/or .dll files (and/or .ocr files, assemblies or whatever) does not ipso facto say anything about how well an application (or system, if you prefer) is designed. In _some_ cases one might be able to conclude such, but the point is that without knowing specifics of a particular application, it's not really possible to come to solid conclusions (at least IMHO.) Regards Walter ----------------------------------------------------- Home page: http://groups.yahoo.com/group/delphi-en/ To unsubscribe: [EMAIL PROTECTED] Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/delphi-en/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
