Life after Windows 7

Future of VB 6 has some troubling statements.

Quote:

---

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.

---

Quote:

---

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

Quote:

---

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.

---

Quote:

---

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

3. I am not interested in any language, such as the .NET lanuages, that can be decompiled.

4. Many of the programs use Microsoft Office, so the language has to be good for this.

5. Seems that VB 6 is kaput after Windows 7.

Offhand I wouldn't go into "worry" mode about this just yet. VB6 works fine under Vista and is promised to be supported in Windows7 which ain't even out yet.. Adoption of Vista has been relatively slow and even if Windows 7 is quicker you are still likely to have an audience for your application for quite a long time to come.

Back in 2000 they were warning us that everything had to be converted to .Net. I was starting to worry about it back then too. That was, what, 9 years ago?

Go and [happily] write your code. You've probably got 5 or 10 years before you really have to worry about this, if then. I have an internal contact at Microsoft that tells me they are not 100% convinced they made the right decision (originally) to dump the VB6 line so people using it have not been forgotten in Redmond. As long as Windows supports desktop development and COM/ActiveX you're going to be able to write VB6 applications. There are MILLIONS of applications out there using that technology. Even Microsoft isn't stupid enough to just cut that off. It will take YEARS.

The company I work for is no Microsoft and even we can't just dump our legacy VB6 code. A lot of our stuff has been rewritten for ASP.Net, yeah ... but we have hundreds of thousands of lines of code in VB6 that the company simply can't afford to just sit down and rewrite. Microsoft knows this ... I would be extremely surprised if they ever really dump support for VB6. Heck, even most DOS applications still run in the command shell. Orphaning VB6 like that would be like shooting yourself in the foot.

I guess they could do that later on down the road, but it would be business suicide.

Do the programs you write still run on your customer's machines? Have you started getting complaints that they won't install or run anymore? Have any of your clients asked that dreaded "Have you rewritten our program in .Net?" question yet? (Hint: you're not likely to get that question often, if at all). Your customers want the program to run on their computer. Beyond that, who gives a rip if you wrote it in VB6 or in COBOL, eh?


-Max :D

VB6 has been kaput for quite a while in terms of mainstream usage and support. If you don't want .NET then I suppose you'll have to go for C/C++/VC++ however the only languages that were ever good for working with Office were VB6 and the .NET ones.

There are issues of immediate concern:

1. If the VB IDE is not supported in 64-bit Vista, that can make life difficult if I have to determine why a prog does not work with Vista, but works with other OS. In this case, the prog uses Excel, so I might need to test the version using Excel in Vista 64-bit.

I really do not want to purchase a 32-bit Vista system.

2. I intend to sell 1 program as shareware. I feel obligated to inform folkes that the program is written in VB 6, so might not run after Windows 7.

3. When Windows 7 is released,must I get a 32-bit Windows 7?

Having no plans beyond Windows 7 doesnt mean they wont, just that they havent started on the next OS since Windows 7 is soon to barely go RC 1.

You can not install VB6 development studio on a 64 bit OS like Vista 64 or Windows 7 64 bit. You can install a virtual machine, install 32 bit XP/Vista and then install VB6.

VB6 is by no means "kaput"

Quote:

---

Originally Posted by mendhak

VB6 has been kaput for quite a while in terms of mainstream usage and support. If you don't want .NET then I suppose you'll have to go for C/C++/VC++ however the only languages that were ever good for working with Office were VB6 and the .NET ones.

---

Delphi is good for working with Office as well.

It's kaput because of the struggle to get VB6 apps working on newer OSes as opposed to .NET framework apps. This thread needs to be tagged VB6 and kaput :p

Lets just say that its on the downward spiral but definately not out....yet.
the runtimes are still supported so writting apps in VB6 will need to be done on 32 bit OS' or VMs and then they can be deployed. Note: there are some special situations that you have to handle for 64 bit

Quote:

---

Originally Posted by RobDog888

You can not install VB6 development studio on a 64 bit OS like Vista 64 or Windows 7 64 bit.

---

People tell me they've done this. I haven't had the need or inclination myself however so I can't say whether it is true.

As far as I know the only obstacle is that the VB6 service packs are packaged using 16-bit installer bootstrap code. This just means you have to extract the contents on a 32-bit machine or VM first.


Windows 7 should be good through 2019 or so. That's one heck of a good run for a compiler that was originally supposed to be replaced after 2 years (but never was).

I havent heard anyone getting it to install on 64 bit without using a VM. There may be some tweaks possibly but havent had the need. Guess where there is a will there will always be a way

Quote:

---

Originally Posted by RobDog888

I havent heard anyone getting it to install on 64 bit without using a VM. There may be some tweaks possibly but havent had the need. Guess where there is a will there will always be a way

---

I have VB 6 IDE installed in 64-bit Vista, but have not used iteough to see problems.

What did you do to get it to install? Others will want to know. did you install VS SP-6 too?

I do not recall doing anything special, but I did this last May/June, so I may have forgotten.

I installed only VB 6 Enterprise,then installed SP 6.

In the Compatibility properties, I have checked "Run the program as an administrator".
No other Compatibility option is selected.

When I start VB, I get the "An unidentified program wants access to your computer" window.

I tell Vista to Allow access.

In another web forum, last year, I learned the answer.
Apparently, the thread is no longer complete. i.e., my, and other postings are missing.

However, I did save a copy of the thread, so I will try to reproduce my posting below the dashed line.
--------------------------------------

Quote:

---

Originally Posted by JPB View Post
VB6 and Vista are "compatible", if you follow these steps:

1) Install VB6 by exploring the CD and then right-click the setup file and select "Run as Administrator".
2) Install the latest Service Pack using "Run as Administrator"
3) After VB6 is installed, right-click on the VB6 icon and click Properties. On the Compatibility tab select "Run this program as an administrator", "Disable Desktop Composition" and "Run this program in compatibility mode for Windows XP (Service Pack 2)". Then click OK.

Once you've completed those steps, VB6 should work under Vista (I am using it on my computer using these settings).

---

Merci!

I did not do the first two steps, only the 3rd, and this corrected the problem described below:

Quote:

---

Installed VB 6 Enterprise in Vista.

Copied over some projects from Windows 2000 system.
Thus far, all but 1 .exe has executed correctly.

And, same result when running from source code.for several of the projects.
However, in ALL cases, when I close VB 6, I get an error

"Visual Basic has stopped working"

Looking at the details, I see:

Problem Event Name APPCRASH
Application name vb6.exe

Have others seen this problem?
Is there a solution?

---

That is to install on Vista/Windows 7 64 bit? Its the same as 32 bit. Seems to be missing the fix

Quote:

---

Originally Posted by RobDog888

That is to install on Vista/Windows 7 64 bit? Its the same as 32 bit. Seems to be missing the fix

---

The instructions I posted were from a discussion about VB 6 and Vista.
Know not what would work for Windows 7.

I kinda understand the concern. That's the one and only one thing I don't like about .NET programming; that the executable you create really isn't a true binary, they're binary IL which can be easily decompiled. It's just the nature of the beast and doing everything through a framework.

Some day though, machine binary decompilers will get to the point where optomised C++ code won't be safe from one-click decompilation into well structured source so it's really a moot point and the entire software industry will have to adapt accordingly to that as well. It's just an unexpected "convenience" that compilers are for the most part "one-way".

It makes me wonder how the world of computing would have turned out if from the get-go they were reversible and all it would take was a few simple commands to have a 1985 era machine produce the complete source code of MSDOS.

Any discusion of decompiling, ethics, etc., should be in a separate thread.

I long ago starting putting ALL VBA code in DLLs, using only stub VBA code to invoke the code in the DLLs.

Quote:

---

Originally Posted by howardkaikow

I long ago starting putting ALL VBA code in DLLs, using only stub VBA code to invoke the code in the DLLs.

---

Sort of hard since there is no VBA compiler to create a DLL with, isn't it? ;)

Quote:

---

Originally Posted by Jenner

It makes me wonder how the world of computing would have turned out if from the get-go they were reversible and all it would take was a few simple commands to have a 1985 era machine produce the complete source code of MSDOS.

---

It sure would have done wonders for the makers of anti-seizure medication.

You can already decompile binaries fairly well, but you can't do a good job of getting around the issue that variable names are lost. The biggest problem with ASM wasn't the lack of high level features, it was the difficulty of keeping track of what code was doing. You needed to comment like a maniac to keep it straight, or else you'd come back to it a couple days later and would take hours figuring out what you had done. You can get to the same place with C, C++, VB6, and VB.NET with one simple step: Use random characters as names for all variables and methods. Structure won't make much difference, as you'll go through hell trying to keep straight what the purpose for those bizarre characters are (actually, a good use of OO principles would make C++ code and VB.NET more comprehensible than the others, even with garbage names). It wouldn't be impossible to figure such a thing out, but it would take considerably more time. Decompilation back to a state such as described, is probably available. It isn't impossible to decompile an exe, it's just very annoying. If you're willing to take the time, then you can do it.

Quote:

---

Originally Posted by dilettante

Sort of hard since there is no VBA compiler to create a DLL with, isn't it? ;)

---

Office XP Developer Edition. ;)

Quote:

---

Originally Posted by RobDog888

Office XP Developer Edition. ;)

---

Got me there!

Wasn't this a free add-on for one version of Office, instead of buying an Office Developer Edition? I sure can't find the download anymore.

And then they discontinued it to try to force everyone to VSTO/VSTA later (Office 2003?) I think.

[QUOTE=RobDog888;3484219]Office XP Developer Edition. ;)[/QUOTE

As I recall, only Office 2000 and Office XP had developer editions.

If you wish to compile for Office 97, or editions after Office XP, then you gotta do so outside of Office.

Also, it may be that there would be a problem compiling version dependent code in office developer. For example, using office developer XP you may wish to include code f or Office 2003. THere are ways to do this outside of Office develop, do not recall whether you can do this within office developer.

Also, there are better setup packages available (e.g., Inno Setup) for building a solution outside of office developer.

Quote:

---

Originally Posted by dilettante

Got me there!

Wasn't this a free add-on for one version of Office, instead of buying an Office Developer Edition? I sure can't find the download anymore.

And then they discontinued it to try to force everyone to VSTO/VSTA later (Office 2003?) I think.

---

It was not free, and there were editions only for Office 2000 and Office XP.
We are taking about building VBA-based applications. VSTO, etc. does not apply.

I believe that MSFT realized that most professional Office programmers were already using VB (or C++ or DElphi or ...) to compile and a developer edition was not necessary.

Indeed, as I recall, it was more cost effective to purchase a stand-alone VB 6 than to purchase an Office Developer edition.

Quote:

---

Originally Posted by howardkaikow

It was not free, and there were editions only for Office 2000 and Office XP.

---

There was most certainly an Office 97 Developer Edition (ODE 97) as well as 2000 (MOD 2000), and XP (MOD XP/2002). There was even Access Developer's Toolkit 7.0 (ADT 7/95) and even earlier.

I guess I was thinking of the Access 2007 Developer Extensions and Runtime which are free.

Quote:

---

Originally Posted by howardkaikow

We are taking about building VBA-based applications. VSTO, etc. does not apply.

---

My point was that Microsoft began to push people away from VBA beginning with Office 2003.

Quote:

---

Originally Posted by howardkaikow

I believe that MSFT realized that most professional Office programmers were already using VB (or C++ or DElphi or ...) to compile and a developer edition was not necessary.

Indeed, as I recall, it was more cost effective to purchase a stand-alone VB 6 than to purchase an Office Developer edition.

---

Well I think that's just wrong. Generally you needed the Office Runtime components, which only came as part of the Developer SKUs - at least in ealier versions of Office. Otherwise you might create add-ins or other DLLs, but not stand-alone applications that don't require Office to be installed.

Quote:

---

Originally Posted by dilettante

There was most certainly an Office 97 Developer Edition (ODE 97) as well as 2000 (MOD 2000), and XP (MOD XP/2002). There was even Access Developer's Toolkit 7.0 (ADT 7/95) and even earlier.

I guess I was thinking of the Access 2007 Developer Extensions and Runtime which are free.


My point was that Microsoft began to push people away from VBA beginning with Office 2003.


Well I think that's just wrong. Generally you needed the Office Runtime components, which only came as part of the Developer SKUs - at least in ealier versions of Office. Otherwise you might create add-ins or other DLLs, but not stand-alone applications that don't require Office to be installed.

---

Office has to be installed whether you use an Office Developer product, or automate Office via, say, VB.

Quote:

---

Originally Posted by howardkaikow

Office has to be installed whether you use an Office Developer product, or automate Office via, say, VB.

---

This isn't true either, at least for Access. I haven't used the Developer Editions (or in 2003 the Access 2003 Developer Extensions) but users do not need Office to use Access applications developed with these tools.

Obtain and deploy the Access 2003 runtime

Quote:

---

Access provides a rich platform for developing database management solutions. To distribute those Access solutions so that they run without requiring a full installation of Access 2003, you must package and distribute your application with the Access 2003 runtime. The Access 2003 runtime is essentially a full version of Access 2003, but with certain design-time features disabled.

---

Quote:

---

You can deploy an Access application to users who do not have an installation of Access 2003 by packaging and distributing the application with the Access runtime. To package the application, you use the Package Wizard included in the Access 2003 Developer Extensions to create an installation package. Your installation package will include your application and the Access 2003 runtime, and will specify a number of installation parameters, such as the folder in which to install the application and whether to create application shortcuts.

---

Quote:

---

Originally Posted by dilettante

This isn't true either, at least for Access. I haven't used the Developer Editions (or in 2003 the Access 2003 Developer Extensions) but users do not need Office to use Access applications developed with these tools.

Obtain and deploy the Access 2003 runtime

---

Yes, Access has runtimes that can be distributed, but the other apps cannot be distributed.

IN any case, I expect that most Access developers use VB, or whatever, rather than an Office developer product.

Quote:

---

Originally Posted by howardkaikow

IN any case, I expect that most Access developers use VB, or whatever, rather than an Office developer product.

---

An application that happens to use a Jet database is not an "Access application." There is a big difference and it isn't just semantics.

Quote:

---

Originally Posted by dilettante

An application that happens to use a Jet database is not an "Access application." There is a big difference and it isn't just semantics.

---

I was not referring to using Jet databases.

I was referring to using the Access object from within VB 6, or whatever.