Re: Statement on backwards compatibility?



My point exactly. The problems I'm referring to can manifest themselves in
different ways. This is just one

Tony Proctor

"Ivan Brugiolo [MSFT]" <Ivan.Brugiolo@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:#rmp6o2#FHA.344@xxxxxxxxxxxxxxxxxxxxxxx
> You have just described a problem of upward compatibility
> form the point of view of the OS.
> How can an OS with only version 2.7installed,
> run an application compiled against 2.8 ?
> If it were able to do so, the OS could be used to win the lottery.
>
> On top of that, you may have the infamous *.tlh problem,
> where the build process depends on the build machine,
> that is always wrong.
>
> --
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> Use of any included script samples are subject to the terms specified at
> http://www.microsoft.com/info/cpyright.htm
>
> "Tony Proctor" <tony_proctor@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message
> news:Oiplc%231%23FHA.912@xxxxxxxxxxxxxxxxxxxxxxx
> > Thanks Hector. In fact, the problem isn't just with the language tools,
or
> > even the header files. We recently found a problem with typelib
versions.
> > For instance, code that was compiled under W2K against msadomd 2.7 would
> > happily run on W2003, even though *only* 2.8 is available there.
However,
> > if
> > the same program were compiled on W2003 then it was bound against the
2.8
> > version, and this would not run under W2K if only 2.7 were available.
> > Worse
> > still, depending on how the code made references to the msadomd
> > interfaces,
> > we saw a situation where the code (an ActiveX EXE) would not even
register
> > itself, instead just emitting an uninformative BEEP.
> >
> > Tony Proctor
> >
> > "Hector Santos" <nospamhere@xxxxxxxxxxxxxx> wrote in message
> > news:#7TBGl1#FHA.916@xxxxxxxxxxxxxxxxxxxxxxx
> >> Tony, you been around. You know the drill.
> >>
> >> MS made a very profound statement about WIN32 compatibility many moons
> >> ago during the 16 bit to 32 bit transition days. I expect MS to hold
> >> this fundamental statement of WIN32 compatibility guarantee. Hundreds
> >> of thousands, if not millions, of companies and applications world wide
> >> are financially at stake and it needs to be made very clear to MS that
> >> they realized how important this is.
> >>
> >> I'm sure they realize this, but I can't help but feel MS is forcing the
> >> "issue" some how. It is making me worry.
> >>
> >> That said, I have been thinking about the same thing with the latest
> >> renditions of the OS with or with the .NET foundation, and/or with
> >> VS2005.
> >>
> >> Just the other day, I compiled a old C/C++ console utility, something I
> >> can do very quickly with VS2005 (version 8 of CL.EXE), to test the
> >> theory. No compile errors or warnings and I was able to run it all
> >> WIN32 test machines we have. I asked in MSDN support forums about
> >> VS2005 MFC/C/C++/RPC development as the response was that it was still
> >> supported. I was wondering if we would need to have both VS 6.0 and
> >> VS2005 development environments.
> >>
> >> I think we should expect BACKWARD compatibility if you are compiling
for
> >> WIN32 on a newer OS. Distribution to any WIN32 OS should work.
> >>
> >> Yes, I agree. I think it is extremely and vitally important that
> >> Microsoft take a step back and comfort their long term developer base
> >> and not got lost in all this wishy washing, glorified, .NET, C#
> >> dependency. That's all good, but they need a commitment (and as I will
> >> go as far as saying LEGAL commitment) to their WIN32 developer base.
> >>
> >> The link would be the WIN32 support statement. I am now interested in
> >> googling it so I can have a copy on record. They should restate it and
> >> make it clear what are the plans.
> >>
> >> The same goes for the WIN 3.1 SUB-SYSTEM and DOS SUB-SYSTEM.
> >>
> >> --
> >> Hector Santos, CTO
> >> Santronics Software, Inc.
> >> http://www.santronics.com
> >>
> >>
> >> "Tony Proctor" <tony_proctor@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
> >> message
> >>
> >> > Does anyone know of a link that describes Microsoft's official stance
> >> on
> >> > backwards compatibility?
> >> >
> >> > The terms upwards and backwards compatibility are a little ambiguous,
> >> and
> >> > depend on which way you're looking through the telescope. In this
> >> context, I
> >> > refer to the expectation that products compiled on a higher O/S
> >> version can
> >> > be distributed and run on older O/S versions.
> >> >
> >> > Most people would expect upwards compatibility. For instance, if you
> >> > compiled a well-behaved program under W2K then it should run under
> >> W2003.
> >> > Few people who have been involved in large-scale software
development,
> >> > across different platforms (e.g. UNIX), would expect the latter. For
> >> > instance, if a "versioned" struct had been changed in size then older
> >> > versions of the O/S may not know how to handle it.
> >> >
> >> > I personally would not expect backwards compatibility (as defined
> >> above)
> >> > because I've seen the issues that can arise. However, I'm looking for
> >> a link
> >> > to any statement on the subject in relation to the Windows O/S
> >> >
> >> > Tony Proctor
> >> >
> >> >
> >>
> >
> >
>
>


.