Roger Scudder wrote in a message to All:

 RS> From: r.scudder{at}rcn.com
 RS> To: c_echo{at}yahoogroups.com

 RS> -----Original Message-----
 RS>  * Author: Roy J. Tellason

> I guess it depends on how large and complex a program we're talking  
> about here.  In some cases,  maybe even most,  it won't matter 
> because of the environment we're running in compared to what we used 
> to have to deal with.

RS>  I think it becomes more important to understand the issues as one
RS> gets closer to, and depends more directly on, the system...  as 
RS> well as when the programmer uses a technology that is designed to 
RS> solve problems related to binary compatibility, such as contract 
RS> based programming.

RS>  Basically what I am getting at is that real-world problems often 
RS> can not be solved by language alone.  Microsoft's .Net framework 
RS> in conjunction with C# is very elegant in the way it hides a great 
RS> deal of complexity from the programmer,  allowing him/her to 
RS> concentrate on the language.

Yeah,  but at what cost?

RS> In the case of COM, the programmer needs to have an intimate 
RS> knowledge of how the DLLs (in process) and EXEs (out of process) 
RS> work.

RS>  If one is lucky enough to be able to work strictly with a language
RS> like ANSI C, he/she may be spared from knowing ugliness.

Strikes me as a good place to start...    

> Under a unix-type environment,  stuff gets swapped out in "pages",  
> right? You don't even know when this is likely to happen unless you 
> have a pretty good idea as to how you write is going to translate to 
> what in the executable.

RS> I haven't done enough *NIX programming yet to comment.  Since both
RS> systems run on the same hardware, I am sure many of the challenges 
RS> are similar. 

> I guess for some things,  like on a system with small resources or 
> on one that's heavily loaded it might make more sense to have stuff 
> stay local to each other.

RS> I am not sure if I am reading you right here.  It is interesting to
RS> note that (in the case of MS anyway) a DLL is loaded into the 
RS> process space of the calling application and executed there...  as 
RS> opposed to running in a separate process, such as with a call to an 
RS> entry point on another EXE.

I guess on thinking about it a bit more,  it's more a function of how
something's linked than anything else...

> JB> AFAICT all that's cained by dynamic linking is smaller binaries
> JB> and some small ram savings where different apps that use the same 
> JB> library functions are "running" concurrently,

> That's not necessarily a trivial thing,  though I don't know of any  
> way to really estimate its impact.  Except that I can run linux on 
> *way* earlier hardware and get equivalent performance to that of 
> competing software which almost has to run on much later stuff.

RS>  I am a huge Linux fan, but I did have at least one case where 
RS> Linux really strained the resources on one of my PCs when I ran X.

That's real easy to do,  when you're running X.  :-)

I'm not sure what it was,  though I have my suspicions,  but yesterday
something was going on that pushed my system load figures up to 1.0 in all
three cases,  when I wasn't actually *doing* anything.  It got higher when
I did do something.  Exiting x didn't help much,  I had to reboot to fix
the problem.  I think something's got a memory leak,  perhaps,  or
something.  I need to update some of the software I'm running,  anyhow.

RS> There is no question that the Linux console blows away the MS 
RS> console.  I guess what I am trying to say is that YMMV.

Yep!

RS> Right now my main PC dual boots RH 9.0 and Win2k.  I am very happy
RS> with RH 9.0. It is rock solid at all times and GNOME and KDE have 
RS> come along very well.

I'm running Slackware 8.1,  and should probably move up to 9.  It may be
that there are some minor bugs,  security holes,  etc. that have been fixed
in the interim.

> JB> it may be possible to arrange a makefile to define a macro 
> JB> according to the availablilty of dynamic linking

> Makefiles are something I haven't had to deal with yet,  or at least 
> composing them.  I've looked in a couple to see what some of the
> options are,  and that's about it so far.

RS> Make is definitely worth taking some time to learn the basics of.
RS> Unless you are using an IDE that batches commands for you or runs 
RS> make in the background, makefiles are the way to go.  Once you 
RS> grasp the basics of how rules work, you are on your way.  I try to 
RS> keep my makefiles very basic. Hand coded makefiles are usually 
RS> quite different than the monsters some the makefile generators
RS> churn out.

At this point I'm continuing to keep busy configuring software and
installing new stuff from time to time,  and figuring out what I already
have in there to make it do what I want.  I'm a ways off from wanting to
actively jump back into development again,  though when I do,  I'll
probably get into studying that...

---