[NTLUG:Discuss] Re: has anyone used Alexandria?

[Bryan J. Smith]

On Sat, 2004-12-18 at 17:28, Kevin Brannen wrote:
> Stuff that is difficult to solve when you can't even figure out why it's 
> not working!

That happens all-the-time with developer libraries.

> The difference is in what widget set you use, the dependency list is 1
> extra set of header files and 1 extra lib (or two if you need Xpm). 

It's all about reuse.  At some point you have to say "okay, basic
widgets are here, bitmap functions here, vector graphics functions here,
process management here," etc...

In fact, GNOME and KDE are largely about unifying several underlying
libraries into one.  In some cases, it's actually easier to just write
for GNOME, instead of having to write for GTK+, GLib, etc... separately.

But you still have to have all the libraries installed, yes.

> The effort to get an X program (even if Motif is involved) to compile
> and work is trivial compare to getting a gnome &| gtk with their
> millions of little libs.  What little KDE (QT) programs I've compiled
> weren't too hard, but still harder than plain X ones.

Don't compare GNOME setup for a scripting environment/program (like
Ruby) to KDE setup for a C environment/program.  I've found no larger
issues in getting GNOME programs built than KDE programs.  Same deal for
GTK+ versus Qt.

In fact, GTK# on Windows isn't difficult at all.  I like the Mono
environment very much.

> And why is that exactly?

Because developers need _more_ files than just the run-time libraries. 
They need headers, language bindings, development libraries, etc... 
It's _never_ easy.  ;->

> Is it possible to get too modular?

Yes.  Systems bloat over time.  This has been the major, major issue
with Windows.  E.g., Win32 today in NT5.x is _nothing_ like Win32 was
originally designed.  The same thing is happening with .NET in NT6.x
Longhorn.

> The opposite extreme of what Microsoft does, where everything is
> integrated into 1 huge software thing that's hard to break apart? 
> Hmm, but I bet MS's [OS] software is hard too.  

That's not true at all, it's a common _mis_perception.  NT is
_very_breakable_ -- the Embedded NT releases let you build NT from
common objects.  This includes the GDI, WinForms and other components.

Heck, most of the components that make up GNOME and KDE are the _same_
-- they are very, very modular.

Now when you get to the Windows application level, yes, it's a mess. 
And this isn't largely due to the NT or VS teams, but the "RAD"
libraries and Microsoft application teams.  You have a lot of Win16,
direct by-passes into Int20-3Fh (yes, DOS) and totally violations of the
Win32 security model because MS-DOS 7/95/98/ME totally _lacked_ them.

In fact, one of my biggest complaints with Visual Studio in the '90s
used to be the fact that I _had_ to load MS IE libraries for an
application that had _nothing_ to do with _any_ Internet services --
both on the developer station and for the user run-time.  Microsoft is
now paying for it as all those libraries that totally _by_pass_ the
Win32 security model are being targeted left and right.

In fact, NT5.1/XP SP2 was largely just a return to NT5.0/2000 security,
which broke all kinds of things and the reason why Microsoft "hacked"
them in the first place, for compatibility.  It's funny to see Microsoft
go in circles.

> I know I've seen articles on software complexity where they 
> discuss number of entry/exit points, functions, and the like to come up 
> with a complexity rating.  Maybe the thing to keep in mind is "do one 
> thing well", then we're left with arguing what "one thing" is, 
> task/system/etc. :-)  Oh well, enough philosophy...

The _huge_ difference between MS and "open systems" is that the latter
is very _well_ documented.

With MS, the OS/VS teams _do_ come up with some _good_ APIs.  But then
the Microsoft RAD/application teams _purposely_ break'em to minimize
code modification.  And then those "hacked libraries" make it into VS
and the OS, and then the game is over.

It's the reason why .NET isn't going to make any difference from the
Microsoft applications standpoint or NT6 Longhorn.  There is some
excellent .NET work going on, but _none_ of it has anything to do with
the desktop -- at least not at Microsoft.


-- 
Bryan J. Smith                                    b.j.smith at ieee.org 
-------------------------------------------------------------------- 
Subtotal Cost of Ownership (SCO) for Windows being less than Linux
Total Cost of Ownership (TCO) assumes experts for the former, costly
retraining for the latter, omitted "software assurance" costs in 
compatible desktop OS/apps for the former, no free/legacy reuse for
latter, and no basic security, patch or downtime comparison at all.