From: "Robert Comer" 

This is a multi-part message in MIME format.

------=_NextPart_000_002A_01C2A752.A3DCF940
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

>   You demonstrate a failure to understand the problem.  No specific =
location you mention makes any difference.  Wherever the shared files =
reside is where they will be updated.  Not only that, your suggestion is =
ill conceived and would break applications and solve nothing.<

You obviously don't understand what I wrote, but no matter, I agree it =
will break some things but I think that it acceptable.

>   Are you unable to describe the OS/400 system which you claimed =
familiarity with.  We were not discussing Windows.

I am very capable of describing what the AS/400 but that is irrelevant = to
what I was talking about, not to mention there really isn't enough = time
for me to go into depth about it.

>You are the one that brought OS/400 into the discussion.=20

Yes I did, but only as an example of a system that doesn't have nearly = as
bad a problem with something like DLL hell as windows does.

>We are discussing shared library problems and in particular I have been =
trying to get you to state exactly what it is that you think is the =
architectural flaws and successes in all the systems that supported =
shared libraries with which you have familiarity.<

I know that's what you have been trying to do, I am unwilling to broaden =
the discussion that much in this venue.

>So far you have demonstrated knowledge of none.  Just lots of hand =
waving and finger pointing.

Whatever you say Rich.

>   You continue below to spout a bunch of FUD without a single =
specific.

I am not spouting FUD. Windows has a DLL hell problem.

>I'd be interesting in understanding why it is that you believe you have =
so many problems while I can't remember the last time I had any = problem.<

So I suppose you think I'm lying about the problem?  Perhaps it could be =
that I control far more desktops than you do, or perhaps I actually have =
users out there that mess things up?  (duh.......)

>Also be specific about the instances you claimed you have encountered =
on the OS/400 and how they differ.<

I told you I'm not going there, I don't have the time or the patience.

- Bob Comer



  "Rich"  wrote in message news:3e018429{at}w3.nls.net...
     You demonstrate a failure to understand the problem.  No specific =
location you mention makes any difference.  Wherever the shared files =
reside is where they will be updated.  Not only that, your suggestion is =
ill conceived and would break applications and solve nothing.

     Are you unable to describe the OS/400 system which you claimed =
familiarity with.  We were not discussing Windows.  You are the one that =
brought OS/400 into the discussion.  We are discussing shared library =
problems and in particular I have been trying to get you to state = exactly
what it is that you think is the architectural flaws and = successes in all
the systems that supported shared libraries with which = you have
familiarity.  So far you have demonstrated knowledge of none.  = Just lots
of hand waving and finger pointing.

     You continue below to spout a bunch of FUD without a single =
specific.  I believe you are posting bullshit.  How about you give =
concrete examples of what you claim is prevalent?  I'd be interesting in =
understanding why it is that you believe you have so many problems while =
I can't remember the last time I had any problem.  Also be specific = about
the instances you claimed you have encountered on the OS/400 and = how they
differ.  If you can't be specific, why not just say so and we = can stop
this pointless exchange that has failed to get from any = substance to
support your hand waving and finger pointing.

  Rich

    "Robert Comer"  wrote in message =
news:3e0169cb$1{at}w3.nls.net...
    >  Describe in detail your suggestion for "make it harder for the =
programmer
    to mess up".

    *no* access to /WINNT -- if using WWindows installer and that is =
requested,
    don't put the DLL there and put it in the apps directory.

    >Please include a description of exactly what IBM did with OS/400 =
and any
    other system with which you have familiarity that.<

    We are talking about Windows.

    >So far all you have done is wave your hands around and try to lay =
blame on
    anything but the shared components with the incompatibilities =
themselves.<

    Now just who's fault is the incompatibilities of the shared =
components?
    Most are Microsoft DLL's.

    >   In regard to your other remarks, ISVs are free to not use shared
    components and some do.<

    Of course.

    >  There are all sorts of ways to keep private something that the =
author
    intended to be shared.  I've seen some ISVs do this but it is =
uncommon. <

    Unfortunately.

    >Windows XP introduced something significantly more meaty and this =
is used
    by the OS itself as well as many applications.  To take advantage of =
the
    themed UI in Windows XP this mechanism must be used.  While it adds =
more
    structure and control, you can't force third parties to use it.<

    That's just it, I think you can force it, and with smart enough =
install
    routines Microsoft should be able to "fix" problems on existing =
apps. (like
    putting shared DLL's in the apps directory instead of /WINNT, they =
already
    make an effort to make the app run, just extend that idea to how it =
is
    installed.

    >   In regard to the question in the first paragraph, these new =
mechanisms
    make it easier for programmers to do the right thing, it does =
nothing to
    make it harder to mess up.  Why?  Because programmers that are =
sloppy in
    their use of shared components and create problems by being sloppy =
are not
    going to be happy with something that makes them do the work they =
have been
    skimping on.<

    TS is what I say about that.  That's no different from an =
administrator like
    myself, or my predecessor, making any contract programmers follow my
    conventions if they are going to work for me.  I have yet to have =
one even
    utter an argument against it. If doing thes would make Windows apps =
more
    stable, it's worth doing.

    >Programmers that are sloppy in keeping the shared components they =
create
    compatible aren't going to be happy with something that makes them =
do extra
    work or worse still makes their customers do extra work that their
    competitor's customers don't need.  Lucky for everyone, only a few =
folks are
    that sloppy and if you stay away from cheap software or shareware =
you are
    much less likely to encounter any problems.  I can't remember the =
last time
    I ever encountered one.  That's probably because I install software =
from
    responsible vendors.<

    That's a weak argument, blaming it on cheap software.  The problems =
are more
    than prevalent than you indicate anyway...

    >   In regard to system file protection in Windows 2000 and later, =
the
    reason you still see DLL hell with sloppy software is because it has =
nothing
    to do with system components.<

    So maybe these shared Microsoft DLL componens should be part of the =
OS and
    covered by system file protection...

    - Bob Comer




    "Rich"  wrote in message news:3e01591b{at}w3.nls.net...
       Describe in detail your suggestion for "make it harder for the =
programmer
    to mess up".    So far all you have done is wave your hands around =
and try
    to lay blame on anything but the shared components with the
    incompatibilities themselves.

       In regard to your other remarks, ISVs are free to not use shared
    components and some do.  There are all sorts of ways to keep private
    something that the author intended to be shared.  I've seen some =
ISVs do
    this but it is uncommon.   Windows 2000 and Windows Me introduced =
some ways
    to make this easier.  Windows XP introduced something significantly =
more
    meaty and this is used by the OS itself as well as many =
applications.  To
    take advantage of the themed UI in Windows XP this mechanism must be =
used.
    While it adds more structure and control, you can't force third =
parties to
    use it.

       In regard to the question in the first paragraph, these new =
mechanisms
    make it easier for programmers to do the right thing, it does =
nothing to
    make it harder to mess up.  Why?  Because programmers that are =
sloppy in
    their use of shared components and create problems by being sloppy =
are not
    going to be happy with something that makes them do the work they =
have been
    skimping on.
       In regard to system file protection in Windows 2000 and later, =
the reason
    you still see DLL hell with sloppy software is because it has =
nothing to do
    with system components.

    Rich

    "Robert Comer"  wrote in message
    news:3e011c2a{at}w3.nls.net...
    >   You didn't answer the question regarding the feature or property =
that
    should not exist.

    I answered it.

    >Your answer is "programers shouldn't do that".

    Microsoft could enforce such a policy, or at least make it harder =
for the
    programmer to mess up.

    >   Regarding the above, Windows 2000 and later support system file
    protection that protects system files.

    Yet DLL hell still happens.

    >A great feature but it doesn't keep programmer's from making =
mistakes.
    Nothing would prevent you from overwriting one DLL you wrote with =
another
    version that is not 100% compatible and breaks applications third =
parties
    wrote that use your stuff.<

    I don't see why not.

    >   I think the flaw in your thinking is that in while you recognize =
shared
    libraries are shared you fail to recognize that any change can =
introduce
    compatibility problems regardless of the author. <

    I understand that.  However shared dll's should be part of the OS =
and where
    the OS resides.  If it's a vendor shared DLL it should only be =
updated by
    the vendor and each app that uses it should keep their own copy of =
it.

    >Simply put, the only way to avoid this is to never share or never =
change
    anything that is shared.

    If the shared part is not part of the OS that would be fine by me.  =
There's
    absolutely no reason a second vendor couldn't license someone else's =
DLL and
    distribute it with their app -- and keep it in the apps directory.

    >I had hoped you would acknowledge this instead of all the finger =
pointing
    and name calling you posted instead.

    I called no names, unlike you.

    >Your back peddling on OS/400 by claiming that while a problem its =
never
    been enough of a problem that you would resort to the finger =
pointing and
    name calling you use elsewhere is particularly humorous.

    What back pedaling?  Because shared DLL's aren't a problem because =
we don't
    have them -- I was comparing shared DLL's to what the AS/400 does =
have and
    it's all in the OS or separately called executables, and I haven't =
had near
    the problems as in Windows and I've said that every time.  Now if =
you really
    want to talk about AS/400 shortcomings, I got a bunch, but this =
isn't one of
    them.

    - Bob Comer


    "Rich"  wrote in message news:3e0101f9{at}w3.nls.net...
       You didn't answer the question regarding the feature or property =
that
    should not exist.  Your answer is "programers shouldn't do that".

       Regarding the above, Windows 2000 and later support system file
    protection that protects system files.  A great feature but it =
doesn't keep
    programmer's from making mistakes.  Nothing would prevent you from
    overwriting one DLL you wrote with another version that is not 100%
    compatible and breaks applications third parties wrote that use your =
stuff.

       I think the flaw in your thinking is that in while you recognize =
shared
    libraries are shared you fail to recognize that any change can =
introduce
    compatibility problems regardless of the author.  Simply put, the =
only way
    to avoid this is to never share or never change anything that is =
shared.  I
    had hoped you would acknowledge this instead of all the finger =
pointing and
    name calling you posted instead.  Your back peddling on OS/400 by =
claiming
    that while a problem its never been enough of a problem that you =
would
    resort to the finger pointing and name calling you use elsewhere is
    particularly humorous.

    Rich

    "Robert Comer"  wrote in message
    news:3e00f0cd{at}w3.nls.net...
    >   I think the more appropriate question is why you are faulting =
the OS for
    the mistakes of programmer's?

    Both are at fault.

    >Do you fault IBM for the mistakes of OS/400 programmers?

    It depends on the mistake.  The DLL hell scenario just isn't tas =
severe or
    as often a problem enough on the 400 to comlain.

    >   As a follow on, what is the feature or property of the OS that =
you
    believe is responsible and should not exist in order to prevent any
    programmers from making mistakes with shared libraries that =
introduce
    compatibility problems?  <

    Apps should never be able to update these shared libraries if they =
aren't
    the one who wrote them.  If they need updates, make their own and =
call it
    something else.

    >Please answer this for both OS/400 and Windows and any other =
systems with
    which you have familiarity that also have this problem like Linux.<

    Like I said, we don't have enough of a problem on the 400 to worry =
about it,
    and as for Linux, I don't have enough experience with it to answer.

    - Bob Comer




    "Rich"  wrote in message news:3e00e8fd{at}w3.nls.net...
       I think the more appropriate question is why you are faulting the =
OS for
    the mistakes of programmer's?  Do you fault IBM for the mistakes of =
OS/400
    programmers?

       As a follow on, what is the feature or property of the OS that =
you
    believe is responsible and should not exist in order to prevent any
    programmers from making mistakes with shared libraries that =
introduce
    compatibility problems?  Please answer this for both OS/400 and =
Windows and
    any other systems with which you have familiarity that also have =
this
    problem like Linux.

    Rich

    "Robert Comer"  wrote in message
    news:3e00a7c6{at}w3.nls.net...
    > I do?

    Sure seem to.

    >Because I see fault in others as well?

    Not even close.  You seem to be saying one shouldn't fault Microsoft =
OS's
    problems because other have the same problem.

    >It seems to me that
    > I am seeing the fault in others as well as in Windows, and finding =
their
    > faults as well.

    As am I.

    >Show where I have said Windows deserves a free ride, and
    > they are not guilty.

    "The facts are simple. Windows isn't alone with the problem. Yet =
Windows
    gets
    the blame. Windows isn't even the one responsible for the problem
    oftentimes. Yet it gets the blame."

    >What I -HAVE- said is that -OTHERS- suffer the same
    > problems and should be held up to the light as well because the =
same
    > warnings should apply.

    That's hard to do in a conversation about Windows...

    > How is that excusing Windows faults?

    How is that not?  You seem to be making excuses for Windows and you
    shouldn't be.

    - Bob Comer




    "Ronnie T. Mungo, Boy Genius"  wrote in message
    news:3e009164$1{at}w3.nls.net...
    >
    > "Robert Comer"  wrote in message
    > news:3e008d2d$1{at}w3.nls.net...
    > > > Your two above comments don't reconcile well.
    > >
    > > They do to me.
    >
    > Through the darkness blindly...
    >
    > > > There's a logic shortfall there.
    > >
    > > You seem to want to excuse Windows faults, I don't. (Nor any =
other
    > platform
    > > for that matter.)
    >
    > I do? Because I see fault in others as well? Odd logic. It seems =
to me
    that
    > I am seeing the fault in others as well as in Windows, and finding =
their
    > faults as well. Show where I have said Windows deserves a free =
ride, and
    > they are not guilty. What I -HAVE- said is that -OTHERS- suffer =
the same
    > problems and should be held up to the light as well because the =
same
    > warnings should apply.
    >
    > How is that excusing Windows faults?
    >
    > RTM, BG
    >
    >


------=_NextPart_000_002A_01C2A752.A3DCF940
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








>   You demonstrate a =
failure to=20
understand the problem.  No specific location you mention makes any =

difference.  Wherever the shared files reside is where they will be =

updated.  Not only that, your suggestion is ill conceived and
would = break=20
applications and solve nothing.<
 
You obviously don't understand what I =
wrote, but no=20
matter, I agree it will break some things but I think that it=20
acceptable.
 
>  
Are you unable to =
describe the=20
OS/400 system which you claimed familiarity with.  We were not =
discussing=20
Windows.
 
I am very capable of describing what =
the AS/400 but=20
that is irrelevant to what I was talking about, not to mention there = really=20
isn't enough time for me to go into depth about it.
 
>You are the one that
brought OS/400 =
into the=20
discussion. 
 
Yes I did, but only as an example of a =
system that=20
doesn't have nearly as bad a problem with something like DLL hell as = windows=20
does.
 
>We are discussing
shared library =
problems and=20
in particular I have been trying to get you to state exactly what it is = that you=20
think is the architectural flaws and successes in all the systems that = supported=20
shared libraries with which you have familiarity.<
 
I know that's what you have
been trying =
to do, I am=20
unwilling to broaden the discussion that much in this =
venue.
 
>So far you have demonstrated =
knowledge of=20
none.  Just lots of hand waving and finger
pointing.
 
Whatever you say
Rich.
 
>  
You continue below to =
spout a=20
bunch of FUD without a single specific.
 
I am not spouting FUD. Windows has a =
DLL hell=20
problem.
 
>I'd be interesting in
understanding =
why it is=20
that you believe you have so many problems while I can't remember the = last time=20
I had any problem.<
 
So I suppose you think I'm lying about =
the=20
problem?  Perhaps it could be that I control far more desktops
than = you do,=20
or perhaps I actually have users out there that mess things
up? =20 (duh.......)
 
>Also be specific about the =
instances you=20
claimed you have encountered on the OS/400 and how they =
differ.<
 
I told you I'm not going
there, I don't =
have the=20
time or the patience.
 
- Bob Comer
 
 
 

  "Rich" <{at}> wrote in message news:3e018429{at}w3.nls.net...
     You demonstrate a =
failure to=20
  understand the problem.  No specific location you mention makes =
any=20
  difference.  Wherever the shared files reside is where they will =
be=20
  updated.  Not only that, your suggestion is ill conceived and =
would break=20
  applications and solve nothing.
   
     Are you
unable to =
describe the=20
  OS/400 system which you claimed familiarity with.  We were not =
discussing=20
  Windows.  You are the one that brought OS/400 into the =
discussion. =20
  We are discussing shared library problems and in particular I have =
been trying=20
  to get you to state exactly what it is that you think is the =
architectural=20
  flaws and successes in all the systems that supported shared libraries =
with=20
  which you have familiarity.  So far you have demonstrated =
knowledge of=20
  none.  Just lots of hand waving and finger
pointing.
   
     You
continue below to =
spout a bunch=20
  of FUD without a single specific.  I believe you are posting=20
  bullshit.  How about you give concrete examples of what you claim =
is=20
  prevalent?  I'd be interesting in understanding why it is that =
you=20
  believe you have so many problems while I can't remember the last time =
I had=20
  any problem.  Also be specific about the instances you claimed =
you have=20
  encountered on the OS/400 and how they differ.  If you can't be =
specific,=20
  why not just say so and we can stop this pointless exchange that has =
failed to=20
  get from any substance to support your hand waving and finger=20
  pointing.
   
  Rich
   
  
    "Robert Comer" <bobcomer{at}mindspring.com>">mailto:bobcomer{at}mindspring.com">bobcomer{at}mindspring.com>
= wrote=20
    in message news:3e0169cb$1{at}w3.nls.net...> =20
    Describe in detail your suggestion for "make it harder for the=20
    programmerto mess up".*no* access to
/WINNT -- if using =
WWindows=20
    installer and that is requested,don't put the DLL there and put =
it in=20
    the apps directory.>Please include a description of =
exactly what=20
    IBM did with OS/400 and anyother system with which you have =
familiarity=20
    that.<We are talking about
Windows.>So far all =
you=20
    have done is wave your hands around and try to lay blame =
onanything but=20
    the shared components with the incompatibilities =
themselves.<Now=20
    just who's fault is the incompatibilities of the shared =
components?Most=20
    are Microsoft DLL's.>   In
regard to your other =

    remarks, ISVs are free to not use sharedcomponents and some=20
    do.<Of
course.>  There are all sorts of =
ways to=20
    keep private something that the authorintended to be =
shared.  I've=20
    seen some ISVs do this but it is uncommon.=20
   
<Unfortunately.>Windows
XP introduced =
something=20
    significantly more meaty and this is usedby the OS itself as =
well as=20
    many applications.  To take advantage of thethemed UI in =
Windows XP=20
    this mechanism must be used.  While it adds morestructure =
and=20
    control, you can't force third parties to use
it.<That's =
just it,=20
    I think you can force it, and with smart enough installroutines=20
    Microsoft should be able to "fix" problems on existing apps.=20
    (likeputting shared DLL's in the apps directory instead of =
/WINNT, they=20
    alreadymake an effort to make the app run, just extend that idea =
to how=20
    it
isinstalled.>   In
regard to the =
question in the=20
    first paragraph, these new mechanismsmake it easier for =
programmers to=20
    do the right thing, it does nothing tomake it harder to mess =
up. =20
    Why?  Because programmers that are sloppy intheir use of =
shared=20
    components and create problems by being sloppy are notgoing to =
be happy=20
    with something that makes them do the work they have =
beenskimping=20
    on.<TS is what I say about that.  That's no =
different from=20
    an administrator likemyself, or my predecessor, making any =
contract=20
    programmers follow myconventions if they are going to work for =
me. =20
    I have yet to have one evenutter an argument against it. If =
doing thes=20
    would make Windows apps morestable, it's worth=20
    doing.>Programmers that are sloppy in
keeping the shared=20
    components they createcompatible aren't going to be happy with =
something=20
    that makes them do extrawork or worse still makes their =
customers do=20
    extra work that theircompetitor's customers don't need.  =
Lucky for=20
    everyone, only a few folks arethat sloppy and if you stay away =
from=20
    cheap software or shareware you aremuch less likely to encounter =
any=20
    problems.  I can't remember the last timeI ever encountered =

    one.  That's probably because I install software =
fromresponsible=20
    vendors.<That's a weak argument, blaming it
on cheap=20
    software.  The problems are morethan prevalent than you =
indicate=20
    anyway...>   In regard to
system file =
protection in=20
    Windows 2000 and later, thereason you still see DLL hell with =
sloppy=20
    software is because it has nothingto do with system=20
    components.<So maybe these shared Microsoft
DLL componens =
should=20
    be part of the OS andcovered by system file =
protection...- Bob=20
    Comer"Rich"
<{at}> wrote in message news:3e01591b{at}w3.nls.net...&nbs=
p; =20
    Describe in detail your suggestion for "make it harder for the=20
    programmerto mess up".    So
far all you have =
done is=20
    wave your hands around and tryto lay blame on anything but the =
shared=20
    components with theincompatibilities =
themselves.   In=20
    regard to your other remarks, ISVs are free to not use =
sharedcomponents=20
    and some do.  There are all sorts of ways to keep =
privatesomething=20
    that the author intended to be shared.  I've seen some ISVs =
dothis=20
    but it is uncommon.   Windows 2000 and Windows Me =
introduced some=20
    waysto make this easier.  Windows XP introduced something=20
    significantly moremeaty and this is used by the OS itself as =
well as=20
    many applications.  Totake advantage of the themed UI in =
Windows XP=20
    this mechanism must be used.While it adds more structure and =
control,=20
    you can't force third parties touse
it.   In =
regard to=20
    the question in the first paragraph, these new mechanismsmake it =
easier=20
    for programmers to do the right thing, it does nothing tomake it =
harder=20
    to mess up.  Why?  Because programmers that are sloppy =
intheir=20
    use of shared components and create problems by being sloppy are=20
    notgoing to be happy with something that makes them do the work =
they=20
    have beenskimping on.   In regard
to system file=20
    protection in Windows 2000 and later, the reasonyou still see =
DLL hell=20
    with sloppy software is because it has nothing to dowith system=20
    components.Rich"Robert
Comer" <bobcomer{at}mindspring.com>">mailto:bobcomer{at}mindspring.com">bobcomer{at}mindspring.com>
= wrote=20
    in messagenews:3e011c2a{at}w3.nls.net...>=
  =20
    You didn't answer the question regarding the feature or property=20
    thatshould not exist.I answered
it.>Your =
answer is=20
    "programers shouldn't do that".Microsoft
could enforce such =
a=20
    policy, or at least make it harder for theprogrammer to mess=20
    up.>   Regarding the
above, Windows 2000 and =
later=20
    support system fileprotection that protects system =
files.Yet DLL=20
    hell still happens.>A great feature but it
doesn't keep=20
    programmer's from making mistakes.Nothing would prevent you from =

    overwriting one DLL you wrote with anotherversion that is not =
100%=20
    compatible and breaks applications third partieswrote that use =
your=20
    stuff.<I don't see why
not.>   I =
think the=20
    flaw in your thinking is that in while you recognize =
sharedlibraries are=20
    shared you fail to recognize that any change can =
introducecompatibility=20
    problems regardless of the author. <I understand =
that. =20
    However shared dll's should be part of the OS and wherethe OS=20
    resides.  If it's a vendor shared DLL it should only be updated =

    bythe vendor and each app that uses it should keep their own =
copy of=20
    it.>Simply put, the only way to avoid this
is to never =
share or=20
    never changeanything that is shared.If
the shared part =
is not=20
    part of the OS that would be fine by me.  There'sabsolutely =
no=20
    reason a second vendor couldn't license someone else's DLL =
anddistribute=20
    it with their app -- and keep it in the apps
directory.>I =
had=20
    hoped you would acknowledge this instead of all the finger =
pointingand=20
    name calling you posted instead.I called no names, unlike=20
    you.>Your back peddling on OS/400 by
claiming that while =
a=20
    problem its neverbeen enough of a problem that you would resort =
to the=20
    finger pointing andname calling you use elsewhere is =
particularly=20
    humorous.What back pedaling?  Because shared DLL's =
aren't a=20
    problem because we don'thave them -- I was comparing shared =
DLL's to=20
    what the AS/400 does have andit's all in the OS or separately =
called=20
    executables, and I haven't had nearthe problems as in Windows =
and I've=20
    said that every time.  Now if you reallywant to talk about =
AS/400=20
    shortcomings, I got a bunch, but this isn't one
ofthem.- =
Bob=20
    Comer"Rich" <{at}>
wrote in message news:3e0101f9{at}w3.nls.net...&nbs=
p; =20
    You didn't answer the question regarding the feature or property=20
    thatshould not exist.  Your answer is
"programers shouldn't =
do=20
    that".   Regarding the
above, Windows 2000 and =
later=20
    support system fileprotection that protects system files.  =
A great=20
    feature but it doesn't keepprogrammer's from making =
mistakes. =20
    Nothing would prevent you fromoverwriting one DLL you wrote with =
another=20
    version that is not 100%compatible and breaks applications third =
parties=20
    wrote that use your stuff.   I
think the flaw in =
your=20
    thinking is that in while you recognize sharedlibraries are =
shared you=20
    fail to recognize that any change can introducecompatibility =
problems=20
    regardless of the author.  Simply put, the only wayto avoid =
this is=20
    to never share or never change anything that is shared.  =
Ihad hoped=20
    you would acknowledge this instead of all the finger pointing =
andname=20
    calling you posted instead.  Your back peddling on OS/400 by=20
    claimingthat while a problem its never been enough of a problem =
that you=20
    wouldresort to the finger pointing and name calling you use =
elsewhere=20
    isparticularly
humorous.Rich"Robert
Comer" =
<bobcomer{at}mindspring.com>">mailto:bobcomer{at}mindspring.com">bobcomer{at}mindspring.com>
= wrote=20
    in messagenews:3e00f0cd{at}w3.nls.net...>=
  =20
    I think the more appropriate question is why you are faulting the OS =

    forthe mistakes of programmer's?Both are at =
fault.>Do=20
    you fault IBM for the mistakes of OS/400 programmers?It =
depends on=20
    the mistake.  The DLL hell scenario just isn't tas severe =
oras=20
    often a problem enough on the 400 to =
comlain.>   As a=20
    follow on, what is the feature or property of the OS that =
youbelieve is=20
    responsible and should not exist in order to prevent =
anyprogrammers from=20
    making mistakes with shared libraries that =
introducecompatibility=20
    problems?  <Apps should never be
able to update =
these shared=20
    libraries if they aren'tthe one who wrote them.  If they =
need=20
    updates, make their own and call itsomething =
else.>Please=20
    answer this for both OS/400 and Windows and any other systems =
withwhich=20
    you have familiarity that also have this problem like =
Linux.<Like=20
    I said, we don't have enough of a problem on the 400 to worry about=20
    it,and as for Linux, I don't have enough experience with it to=20
    answer.- Bob
Comer"Rich"
<{at}> wrote =
in=20
    message news:3e00e8fd{at}w3.nls.net...&nbs=
p; =20
    I think the more appropriate question is why you are faulting the OS =

    forthe mistakes of programmer's?  Do you fault IBM for the =
mistakes=20
    of OS/400programmers?  
As a follow on, what =
is the=20
    feature or property of the OS that youbelieve is responsible and =
should=20
    not exist in order to prevent anyprogrammers from making =
mistakes with=20
    shared libraries that introducecompatibility problems?  =
Please=20
    answer this for both OS/400 and Windows andany other systems =
with which=20
    you have familiarity that also have thisproblem like=20
    Linux.Rich"Robert
Comer" <bobcomer{at}mindspring.com>">mailto:bobcomer{at}mindspring.com">bobcomer{at}mindspring.com>
= wrote=20
    in messagenews:3e00a7c6{at}w3.nls.net...>=
 I=20
    do?Sure seem to.>Because
I see fault in others as =

    well?Not even close.  You seem to be saying one =
shouldn't fault=20
    Microsoft OS'sproblems because other have the same=20
    problem.>It seems to me
that> I am seeing the =
fault in=20
    others as well as in Windows, and finding their> faults as=20
    well.As am I.>Show where
I have said Windows =
deserves a=20
    free ride, and> they are not
guilty."The facts are =
simple.=20
    Windows isn't alone with the problem. Yet Windowsgetsthe =
blame.=20
    Windows isn't even the one responsible for the =
problemoftentimes. Yet it=20
    gets the blame.">What I -HAVE- said is
that -OTHERS- =
suffer the=20
    same> problems and should be held up to the light as well =
because the=20
    same> warnings should apply.That's
hard to do in a=20
    conversation about Windows...> How is that excusing =
Windows=20
    faults?How is that not?  You seem to be
making excuses =
for=20
    Windows and youshouldn't be.- Bob=20
    Comer"Ronnie T.
Mungo, Boy Genius" <dolly{at}barkto.com>">mailto:dolly{at}barkto.com">dolly{at}barkto.com>
wrote in=20
    messagenews:3e009164$1{at}w3.nls.net...=
>>=20
    "Robert Comer" <bobcomer{at}mindspring.com>">mailto:bobcomer{at}mindspring.com">bobcomer{at}mindspring.com>
= wrote=20
    in message> news:3e008d2d$1{at}w3.nls.net...=
>=20
    > > Your two above comments don't reconcile
well.> =
>>=20
    > They do to me.>> Through the
darkness=20
    blindly...>> > >
There's a logic shortfall=20
    there.> >> > You seem
to want to excuse Windows =
faults,=20
    I don't. (Nor any other> platform>
> for that=20
    matter.)>> I do? Because I see fault
in others as =
well? Odd=20
    logic. It seems to methat> I am seeing the fault in =
others as=20
    well as in Windows, and finding their> faults as well. Show =
where I=20
    have said Windows deserves a free ride, and> they are not =
guilty.=20
    What I -HAVE- said is that -OTHERS- suffer the same> problems =
and=20
    should be held up to the light as well because the same> =
warnings=20
    should apply.>> How is that excusing Windows=20
    faults?>> RTM,=20
BG>>

------=_NextPart_000_002A_01C2A752.A3DCF940--

--- BBBS/NT v4.01 Flag-4