🚀 go-pugleaf

= >The October issue of Dr. Dobbs has a review of several application
= >frameworks for Windows, most notable OWL and Microsoft's MFC.
= >
= >The task was for each vendor to write a program based on a third
= >party specification.  In this case we were asked to write a hand-
= >writing browser.  This was a non-trivial application (imho).
= >
= >The end result was (quoting the stats from the magazine):
= >
= >                   OWL      MFC
= >Lines of Code     3398      934
= >EXE size(bytes) 56,848   46,536
= >

Keep in mind that the MFC version's main window  was a dialog box 
(i.e. MUCH of the logic is actually taken care of w/in Windows) 
whereas the Borland version created an "unadorned" window and added 
UI logic to that. 

= >The OWL executable also requires 3 DLLs totalling 312,640 bytes.  MFC
= >is a stand-alone EXE.

The MFC version required at least 1 DLL - commdlg.dll. That is, if it 
were to run on a WIN30 platform...it's already there in WIN31.  If any
one really wants to pick nits (What?! Nit-picking on the net?!) ALL Windows
apps use additional DLL's - GDI.EXE, KERNEL.EXE, USER.EXE, some even more,
in the form of Font files, *.drv's ... but who's counting ...

The impact of additional DLLs on calculated code size can be considered 
moot, or at the very least, be reduced by the fact that apps written 
using XXX.DLL can actually share code with other apps (and, alas,
share bugs... ).  Such is the case with all those apps using (and sharing)
commdlg.dll, olecli.dll, olesrv.dll, ddeml.dll, etc.

One obvious benefit to this approach, is the provider of XXX.DLL can 
improve the performance of the DLL's routines, and the next time the DLL is
distributed with an app, ALL other apps that use that DLL benefit, 
*provided* the DLL creator has not invalidated the original API in the 
update, and the DLL is placed in a commonly accepted and accessible 
place for such things (I'm all for a DLL directory in the Windows 
heirarchy...).  Of course, the above caveat could potentially make things
more difficult for the DLL provider (what API has NEVER had to support
obsolete functions...?).

Now that everyone is convinced that I am an apostle of OWL, it just ain't
so.  I believe that since the DDVT scheme is only supported by Borland
whereas MFC uses constructs that are *for the most part* quite portable
(with the exception of __segment() 'keywords' and the addressing scheme in
the medium model - all things easily avoided), MFC is a better solution 
for MY NEEDS (OK, OK, price played a factor...after getting BCC *and* MFC, 
there weren't a whole lot of cookies left in the jar...).  

Currently, Borland, Intl. is the only kid on the block that can spell
"DDVT".  IMO, tying yourself to one vendor as intimately as DDVT's tie 
one to Borland is asking for an Adult-Sized-Bangaroo of a headache.  

Case in point - how many of us remember Microsoft's song of praise 
about OS/2, about it being the wave of the future and the transition of
Windows to OS/2 will be almost painless?  How much of that code
does MS promise to support in the future? 

The Borland-only nature of OWL could change, either through Borland's 
ability to sell the DDVT idea to other compiler writers (yea, sell 
technology to the competition ... that's the "barbarian" thing to do ... ),
change their OWL code to not use the construct (and break all that other
stuff??!!), or, finally now that Symantec owns the Whitewater Group, 
it could be built into Zortech's compiler ... ("Now where DID I put that
non-disclosure statement...") (for those who don't know, the Whitewater
group worked with Borland in their development of OWL). 

I personally get a warm and fuzzy thinking of Borland making it official and
supporting MFC ... *or* how about a new *portable* UI lib that can handle
DOS and WINDOWS...

Excuse me, I need to go take a cold shower...


-- 
Jason D. Smith  	|
jasons@atlastele.com	|    I'm not young enough to know everything.
     1x1        	|