"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++?

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

-ralph

Mike

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

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.

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

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

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

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.

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

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

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

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.

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.

...

--
/~\ The ASCII
\ / Ribbon Campaign
 X  Against HTML
/ \ Email!

Remove the ns_ from if replying by e-mail (but keep posts in the
newsgroups if possible).

Interesting thread. After MS pulled the plug on VB6 I decided to go the
PHP route for our web-based stuff, instead of learning .NET and counting
on MS to not change directions again in a few years. So my question is
this:

Other than in an intranet setting, where each desktop is tightly
controlled and presents a uniform installation environment, is anyone
really writing desktop applications using .NET? From an installation
viewpoint, it seems like ensuring the .NET framework would be correct on
every target machine would make this a support nightmare. Anyone have
any experience with this?

Jeff

*** Sent via Developersdex http://www.developersdex.com ***

It would seem more logical to ask this question in a .NET newsgroup if you
are in fact after responses from people using .NET.