There is a huge difference between designing an application that makes use
of system APIs prevailing on a limited series of operating systems and
thereby restricting the systems those will run on, and designing the
operating system so as to prevent applications in existence and that do not
utilize those newer underlying APIs from running. IOW, office might be
written to target a set of APIs specific to certain Windows versions,
whereas VB applications and the VB runtimes, which don't know of those APIs
(because they were developed around the time of Win98), will function with
the older APIs. If you check the MSDN, while there are a lot of APIs that
have been depreciated over the history of 32-bit windows, none I can think
of have been removed. Enhanced, yes.
To do so would shoot corporate <enter country here> right in the balls, as
mission-critical apps, once debugged and deployed, are never upgraded just
for the heck of it.
--
Randy Birch
MVP Visual Basic
http://www.mvps.org/vbnet/
Please respond only to the newsgroups so all can benefit.
"Mike Minor" <mm*******@earthlink.net> wrote in message
news:eQ*****************@newsread1.news.atl.earthl ink.net...
: If you don't think they can kill off backward compatibility, then go and
: look at all of the recent releases of MS Office products....they clearly
: state on the package that they will only run on W2K or WinXP...they
: certainly seem to want to make you upgrade OS to by new applications. If
so,
: then why would you think they won't drop support of VB6 on new OS's...I've
: certainly seen it happen in other programming environments from other
: companies, not nearly as big and all powerful as M$...
: I don't think MS respects anyone or anything other than the mighty
dollar...
:
: Thank you,
:
: Mike Minor
: Z-Code Systems, Inc.
:
: "Rick Rothstein" <ri************@NOSPAMcomcast.net> wrote in message
: news:nu********************@comcast.com...
: > > > IMHO, ms can not afford to exclude corporations whose legacy
: > applications
: > > > are developed in VB4, 5 and 6. So I don't foresee any issues with
: > longhorn
: > > > and the ability to run existing applications.
: > >
: > > I hope you are right, I just don't see any reason to believe that.
: > >
: > > I didn't think they could afford to do what they did to the VB product
: > > line but they did. VB.Net totally shattered any trust I had that MS
: > > has any respect for the VB development community.
: > >
: > > I can easily see legacy apps running in some sort of crippled fashion
: > > preventing them from using new features or getting performance
: > > benefits from the new OS or newer hardware. I can also easily see
: > > many legacy apps not running at all until they are rewritten.
: >
: > I might, and I emphasize "might", agree that your first thought could
: > possibly occur (although I seriously doubt it); but, like Randy, I just
: > don't think they can afford to kill off backward compatibility
completely.
: > If Microsoft is going to make everyone rewrite their home-brewed legacy
: code
: > as well as require major updating of existing 3rd party software, then
: given
: > the major change and cost that entails, they would seriously have to
worry
: > about defectors. Companies would have two choices (assuming they decide
: not
: > to follow like sheep)... one, stay with the current working operating
: system
: > and not move up to Longhorn or, two, decide Microsoft has stabbed them
in
: > the back once too often and spend their money moving over to LINUX
(which
: > appears to be quite stable; even IBM is pushing it) instead. I don't
think
: > Microsoft can take the chance on encouraging either of these two
: scenarios;
: > their bottom-line won't allow it. I think they will have to find a way
to
: > make legacy applications work... and without incurring a severe
: performance
: > hit.
: >
: > Rick - MVP
: >
: >
:
:
