From: "Robert Comer" 

>  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
>
>

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