Re: Statement on backwards compatibility?

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


.

Relevant Pages

  • Re: Statement on backwards compatibility?
    ... MS made a very profound statement about WIN32 compatibility many moons ... No compile errors or warnings and I was able to run it all ... > refer to the expectation that products compiled on a higher O/S ...
    (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)
Loading