Re: Statement on backwards compatibility?

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

.

Relevant Pages

  • Re: Statement on backwards compatibility?
    ... You have just described a problem of upward compatibility ... >> this fundamental statement of WIN32 compatibility guarantee. ... No compile errors or warnings and I was able to run it all ...
    (microsoft.public.win32.programmer.kernel)
  • Re: The New Roadmap
    ... Language compatibility between .Net and Win32 and even versions of the ... The only way code compatibility comes into play is if you're a Delphi ... unlike Winforms. ...
    (borland.public.delphi.non-technical)
  • Delphi refocussing on .Net - good or bad?
    ... It's intersting to see an indication that they will be focusing more on cutting edge than compatibility. ... Personally I'm ) starting to think that .Net is not just a new "version" of Win32. ... So Delphi for .Net should probably be considered a completely separate product, like JBuilder or Delphi for PHP, rather than just a new version of Delphi for Win32. ... So, in that respect, compatibility is probably rather unimportant, compared with keeping up with the .Net versions and other emerging .Net technologies. ...
    (borland.public.delphi.non-technical)
  • Re: Delphi support for generics/templates?
    ... I hope you're right about a Win32 version. ... (that support multiple environments like .NET and Win32). ... > ISTM that the C# syntax is already established and published by Microsoft ... > version for backwards compatibility is very easily possible. ...
    (borland.public.delphi.non-technical)
  • Re: VB6, VB2005, or Something Else?
    ... So any VB6 successor is free to break compatibility to COM ... That doesn't imply that the "old syntax" couldn't be supported and that the new one couldn't support native code compilation. ... But I think it's a myth that you simply can take your native code and compile it to managed one and expect it to be the same as if you would re-engineer the whole application and rewrite it in .NET. ... But I also stated that this would break compatibility in many ways. ...
    (microsoft.public.vb.general.discussion)