http://mdn.microsoft.com/en-us/vbrun/ms788708.aspx states:

"The Visual Basic team is also committed to the Visual Basic 6.0 development
environment running on Windows Vista, Windows Server 2008 and Windows 7."

However, it also states:

"The Visual Basic 6.0 IDE will be supported on Windows Vista and Windows
Server 2008 as part of the Visual Basic 6.0 Extended Support policy until
April 8, 2008. Both the Windows and Visual Basic teams tested the Visual
Basic 6.0 IDE on Windows Vista and Windows Server 2008. This announcement
does not change the support policy for the IDE."

No mention of Windows 7

And

"64-Bit Windows

Visual Basic 6.0 runtime files are 32-bit. These files ship in 64-bit
Windows Operating Systems referenced in the table below. 32-bit VB6
applications and components are supported in the WOW emulation environment
only. 32-bit components must also be hosted in 32-bit application processes.

The Visual Basic 6.0 IDE has never been offered in a native 64-bit version,
nor has the 32-bit IDE been supported on 64-bit Windows. VB6 development on
64-bit Windows is not and will not be supported."

And

"However there are no plans to include VB6 runtime in future versions of
Windows beyond Windows 7."

So, I have at least the following concerns:

1. I have the VB 6 IDE installed on 64-bit Vista. What problems can I
expect?

2. Is it time to start converting programs to C/C++?

<snipped>
Nothing more that the usual when migrating an application to Vista - most
will concern working with new UAC, Aero, etc. Check out
microsoft.public.vb.vista.compatibility if you have a specific problem.

The classic VB (VB6 and lower) windows development platform has been dropped
by MS. It has lasted longer than MS themselves probably would like it to and
will likely continue as long as 32-bit applications are supported. But it
has been dropped. At some point you may need to move to another development
platform.

What language you chose will depend on the development platform you migrate
to.

-ralph

For myself I am retired from work and programming is just a hobby, and am
too long in the tooth now to change anyway, but for others I think it's time
to start converting to any programming tool that is not a product of a
single company, especially if that company happens to be Micro$oft.

Mike

And that the tool used is not proprietary to that company.


Show quoteHide quote

Hi Howard,

I've been running VB6 IDE on Vista x64 for a long time now and no real
issues. You don't need to run it as admin unless you are using activex for
the first time or are developing activex controls/dlls.

As to your second question, the answer really depends on what you want to
do.  If you want to write 64 bit code then you will have to use something
other than VB6. Personally I'd recommend VB .NET.  But if you don't need 64
bit, then within the current limitations of VB6 today, you can continue to
use VB6 for a long forseeable time.  Windows 7 is really Vista the way it
should have shipped, so there isn't much changes there. Beyond that they
aren't committing to VB runtimes being shipped or working, but realistically
I believe they will either natively with the OS like we see today or as part
of some app virtualization.  I'm *guessing* but think Microsoft is looking
hard at how to isolate legacy problems in the OS whilst maintaining legacy
compatibility, hence the non commit past Windows 7.



Show quoteHide quote

Howard, do yourself a favour and ignore this guy.  He's feeding you serious
misinformation and he's doing it on purpose.

This is bad advice.  You will be seriously limited in what you can and
cannot do with VB.  It would be in your best interest to run VB6 as
administrator and follow the guidelines for a least priviledged environment.
As long as you do this, everything will be fine.  Not running VB6 as admin
will seriously limit what you can do with VB, which is what MSFT and their
hired stooges, like McCarthy wasnt you to believe so they can pitch their
"alternative".

This is exactly why you are being misfed information that is wrong.  As you
can see, the pitch has already started.  You cannot port your existing VB6
code to .NET.  It will require a complete rewrite and a commitment to learn
a new language.  And regardless what the MSFT stooges say, it is a new
language.  A few of the more reputable folks left here will back me up on
this.

That is a complete and total lie.  MSFT has already started the VB runtime
will be shipped and will be compatible with Windows 7.  True, it may not be
"supported" in the MSFT sense of the word.  Again, you're being misled about
the truth in order to pitch that mislabed  lump of garbage called .NET.
Remember, you are being fed lies by a MSFT puppet who gets paid to do so.

No reason to reply to the best, because it's  ::chuckle::  bull$h1t.

For the record, named like Bill McCarthy, Cor Lightbert (or however it's
spelled), Paul Clement and Mike Davis are .net fanatics who have an agenda,
which is to turn as many people off of the REAL VB and force their .NET
version on you.  Be very leery of anything they say, because it's not in
your best interest...but rather theirs...and their master's, MSFT.

Cheers

I am developing a VB 6 app that uses the Excel object.
Intended to work with Excel 97, 2000, 2002, 2003 and 2007.

I build the app using VB 6 in Win 2000 with Excel 97.

Thus far, no problem using the .exe on Vista 64-bit with Excel 2007.

My concern is, what if I have to debug in the VB 6 IDE in Vista to verify a
Vista, or Excel 2007, issue.

I've also noticed the  .exe runs faster if I compi;le on the Vista platform
and Excel 2007.
I may wish to make that .exe available as well. Of course, this .exe could
not be used by earlier versions of Excel.

You will most definetely need to run VB as admin, because of the use of
refences to Excel, which requires admin privs to access the registry.  So
again, Bill was wrong.

This way, debugging in the IDE should be fine.

Hi Howard,

No problem at all.  You don't even need to run as admin for that as you are
referencing an activex dll. It's only the first time you reference ocx's you
need to run as admin so as the oca can be written.


That's most likely the Excel 2007 library is faster than referencing the '97
library for excel 2007.

Right,  but that's more to do with the excel model you reference than Vista
or Windows 7 etc.

As to looking forward, for windows 7 you should have no problems. Beyond
that, as I said earlier, I am guessing virtualization will come in so your
code will still work.  The only potential issue I can see moving forward is
if Office moves to 64 bit.  For  Excel, Access and maybe even Outlook, there
may be some benefit in having a 64 bit version, but *if*, and I think that's
still a big *if*, they do make a 64 bit version of office, I'd expect them
to include a 32 bit version as well alongside, and/or some thunking layer of
some sort so as 32 bit apps like your VB6 app can still call on a 32 bit
Office object model.

In article <ugXFHs$pJHA.5***@TK2MSFTNGP05.phx.gbl>, kai***@standards.com
says...

....

Delphi.

Rubberband Line with ScrollBar
Active X and Vista
Why there is a limit of 65,536 bytes when writing to file?
Value > Long Data Type
How to make this call from form to control
Differences between VB amd VBA and VBA Education
Application.Quit but Word remains open in Task Manager
VB App fails when log reaches 65536
HOW IS Memory Used by a VB App
NET Required ???