Re: SyncToy and .Net 2.0

Thanks Michael,

I'd never realised that that's what Microsoft was doing with their
versioning. It makes a lot of sense when seeing new software which is
compatible with a wider range of OS versions and other apps using .net 1.1
instead of .net 2.0.

I'm quite new to programming, and have only ever been taught .net 2.0 IDEs
and techniques. Do you think it's worth getting a good book from a couple of
years ago and learning .net 1.1 as well?

-Graeme

"Michael J. Mahon" wrote:

Graeme wrote:
It would seem that MS either doesn't trust .Net or doesn't find it as useful
as their marketing would like users to think it is.

"Leo" wrote:


It would be nice if MS would just update SyncToy to recognize .net 2.0

You misunderstand (and Microsoft's "naming" doesn't help).

In the .NET world, version numbers are forever. Newer versions do not
obsolete older versions. Older versions are retained forever to run
code developed and tested on them.

This is Microsoft's latest attempt to resolve "DLL hell", in which
hidden dependencies on, for example, "bugs" in an older implementation
of a DLL cause using applications to malfunction when the DLL is updated
to a newer "corrected" version.

There is no way for Microsoft to ensure that all older pieces of
software, tested in an older environment, will run correctly on a
newer version of the "same" environment without enforcing rigourous
architectural control over the interfaces and functionality for both
the environment (hard, but doable) and all the applications that use
it (not doable without a costly, time-consuming certification program
for all applications).

So their pragamatic (but confusing) solution is to keep all older
versions of an environment active to support all older apps.

It's a hard problem, and a relatively chaotic market that would not
accept any increased rigorousness in the development and certification
process.

The confusing thing is that in the past, a higher version number of
a particular named piece of software meant "supercedes", not simply
"is later than".

-michael

Home page: http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."

.

Relevant Pages

  • Re: SyncToy and .Net 2.0
    ... I'd never realised that that's what Microsoft was doing with their versioning. ... of a DLL cause using applications to malfunction when the DLL is updated ... newer version of the "same" environment without enforcing rigourous ...
    (microsoft.public.windowsxp.photos)
  • Re: Green Hills CEO: Linux threat to free world!
    ... >> required an updated DLL, and when that DLL is installed finding that other ... (He correctly describes the problem but offers another Microsoft ... problems caused when multiple applications attempt to share a common ... A user may remember installing something a week ...
    (comp.arch.embedded)
  • Re: Maximum String size in Java?
    ... > i think we can apply standard programming answer #1 to the question ... provided were specific and mapped to the business environment. ... We're hugely a Microsoft shop these days. ... The bottom line is that cross-platform portability is vital in some ...
    (comp.programming)
  • Re: Odd behavior of getenv and putenv
    ... Recently I have observed some odd behavior of getenv and putenv function. ... This sounds like the modules (EXE, DLL) are using different CRTs and thus ... you could link everyone to the same CRT DLL so they would share CRT state. ... So it seems that getenvand systemlook at different environment. ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Threads Vs Forks in Embedded Environment
    ... forks....because using thread or forks are 2 different design ... normal computing environment. ... legacy applications work well with threaded applications. ... programming tools also make it harder to design and test threaded code. ...
    (comp.unix.programmer)