Post by RalphPost by Michael D. OberIn that case, you should have put that in your original answer - not the
generic "VB doesn't exist in VS 2005" that the VB 6 fanatics spew. The
reality is that VC++ doesn't exist in VS 2005 in the same manner as it
existed in VS 6. I know because I have programs in both VB 6 and VC++ 6.
The VB 6 code has ported to VB 2005 a lot easier than the VC++ code did to
VC 2005. At some point, VB 6, with its mixed 16/32-bit COM model, will
not
Post by Michael D. Obereven be able to run on Windows. The end to VB 6 is definitely on the
horizon given that Longhorn (Windows 2008) will be the last version of
windows running 32-bit processors.
Mike.
Your enthusiasm for the future can be appreciated but your observations and
prophesies are a bit exaggerated.
The VC++ compiler included with VS2005 is quite capable of generating C++
sans any managed environment. The "reality" is while the IDE has changed
(features have different names, colors, placements, &etc.) there is no
substantial differences between VS6 and VS2005 when it comes to VC++. While
with VB the language itself has changed, VC++/CLI is an option.
The VC++ linker uses a new interface which means that older libraries cannot
be used. This is a major change, especially when forced to use older
libraries. If there is a switch that will allow this, please let me know.
Post by RalphThe statement that VB6 code ports to VS2005 easier than VC++ code can not
possibly be based on any concrete personal experience. Pure fantasy.
That VB6 uses a 'mixed 16/32 bit COM model' is an extraordinary observation
and definitely would come as a surprise to any VB6 programmer.
Take a look at the limitations of the ActiveX controls that shipped with VB
6. At least one of them, the progress bar control, is a 16 bit control. It
won't handle values longer than 2^15-1 for max value. I suspect there are
other controls with similar issues.
Post by RalphAs for the demise of VB6 - I think everyone is well aware that the VB
development platform is already over the horizon as far as MS is concerned.
However, the VB IDE and applications are supported on Vista, and according
to MS, apps will be supported on Windows Server 2008. Considering a support
life-time of 5 to 7 years, that means it will be at least 2013 before
current VB6 programmers need to be concerned.
[Which by the way, makes VB6 support almost 5x longer than "VB.Net - VS2003"
was supported. <g>]
Bravo - MS actually did something right with regards to VB 6. Personally, I
suspect that VS 2002 & 2003 were designed to be a "throw away" answer to Sun
Microsystem's Java. In the VB world, you lost a lot of IDE features going
from VB 6 to VB 2002/3. Features that have almost all been restored in VB
2005. Also, the framework and ASP.Net changed dramatically from 1.x to 2.0,
yet the change from 2.0 to 3.0 was 100% backwards compatible.
Post by RalphIt is true that MS has announced that "Windows Server 2008" is the last OS
to support 32-bit *processors*, BUT that doesn't mean 16-bit or 32-bit
*processes* won't be supported, or that 16/32-bit processors/processes won't
be supported with newer workstation OSs.
64 bit Windows OSs cannot run 16 bit programs, which eliminates many VB 6
program simply because their installers are 16 bit. This effectively
eliminates the ability for most people to install and run VB 6 based
programs on 64 bit Windows. Yes - I think it's a lousy solution since the
64 bit processors still have the ability to emulate an 8086.
I am definitely one of those people who feel VB 6 got shafted with the
introduction of VB.Net. Many of the features in VB 6 could easily have been
incorporated into VB.Net, yet MS deemed it either too difficult or not worth
the effort. It is interesting that the VBA for Word and Excel was actually
based on the VB 6 Control Creation Edition, which makes me wonder if MS had
always felt that VB 6 was a throw away language.
Mike.
