3

I have Win 7 on my laptop and I would like to use it as a VB6 dev environment when travelling.

Are there any reasons not to do this? At present I am mainly targetting XP systems.

CJ7
  • 22,579
  • 65
  • 193
  • 321
  • Not a duplicate, but see also [this question about **how** to install the VB6 IDE on Win7](http://stackoverflow.com/questions/2339536/has-anyone-had-success-with-visual-studio-6-on-windows-7), rather than whether it's a good idea, and [this about the IDE on Win7 64-bit](http://stackoverflow.com/questions/2501061/does-the-vb6-ide-run-on-windows-7-64-bit) and of course [does Windows 7 support the VB6 runtime](http://stackoverflow.com/questions/447007/will-windows-7-support-the-vb6-runtime) – MarkJ Feb 02 '12 at 12:44
  • Are you asking if Win7 will support VB6? Numerous supporting links already exist to answer this question: [here](http://stackoverflow.com/questions/2501061/does-the-vb6-ide-run-on-windows-7-64-bit) and [here](http://stackoverflow.com/questions/447007/will-windows-7-support-the-vb6-runtime) – JimmyPena Feb 03 '12 at 00:25
  • Just realized @MarkJ already posted those links. **facepalm** – JimmyPena Feb 03 '12 at 00:27

1 Answers1

5

Are there any reasons not to do this?

Not really, no. Although the VB 6 IDE is officially unsupported and has been since 2008, the Windows and VB teams worked overtime to make sure that it works properly on Windows 7 and Server 2008.

I used to have VB 6 installed on my old dev machine running Server 2008 R2 64-bit and can personally testify that I did not experience any issues whatsoever with such a configuration.

Honestly, developing in Windows 7 will probably make you a better developer. UAC will actively prevent you from doing things that you shouldn't have been doing in the first place, like saving data in the Program Files folder. If you run into this type of problem when testing your application, don't blame VB 6 or Windows—the real problem is your code, and the bug is that it ever worked in the first place. Take this as an opportunity to fix those gaping problems (or at least make a note of them so that they can scheduled for an upcoming fix), even if it's going to work properly on XP anyway.

In a pinch, you can always force the application to run with administrative privileges and/or enable XP compatibility mode by right-clicking on its shortcut. But I certainly don't recommend this as a matter of general practice.

Cody Gray - on strike
  • 239,200
  • 50
  • 490
  • 574
  • Good points. My only concern is in the opposite direction. Will developing in Win 7 potentially cause problems when deploying to XP? – CJ7 Feb 02 '12 at 03:10
  • @CraigJ: No, how could it? The only problem would be if you called a Win32 API function (which you'd have to declare yourself, of course; the VB 6 libraries haven't been updated in years) that is only supported in a more recent version of Windows and doesn't exist on XP. That will work fine on your dev machine, but will blow up when you try to run it on XP. Not really a big deal though, considering that 1) the SDK docs tell you the supported operating systems for each function, and 2) you should always test the app on XP before deploying anyway. Using a virtual machine is a great option. – Cody Gray - on strike Feb 02 '12 at 03:13
  • 2
    If doing database (ADO) development on Win7, you may well come accross [this problem](http://stackoverflow.com/q/9094786/588306) but it's an easy fix. – Deanna Feb 02 '12 at 09:00
  • Actually there are a number of new ActiveX components as part of Vista and later too. Once again just be aware of them and avoid using them in programs meant to be deployed to downlevel systems, or be careful to deploy the redistributable version of the component where one exists. The InkEdit control is the first one that comes to mind, a Unicode RichTextBox that supports "pen" input on XP Tablet Edition or any Vista or later OS. There is a non-ink compatible version for deployment to non-tablet XP. – Bob77 Feb 02 '12 at 16:59
  • The one problem I have seen most is an ADO program compiled on Windows 7 breaks on XP. Microsoft found the problem and has fixes for it (http://support.microsoft.com/kb/2517589), but this is one of those odd problems that will completely baffle you when it happens. The issue is VB6 is no longer being updated while Windows continues to evolve. Microsoft goes to extraordinary lengths maintaining backward compatibility (IMHO), but things get overlooked. I have many VB6 programs that I have to maintain still, but I work on an XP virtual machine specifically to avoid this kind of problem. – jac Feb 02 '12 at 21:13
  • 1
    Deanna already addressed this above. This is not a VB6 problem, but an ADO issue caused by Microsoft's attempts to square ADO with their Office x64 model. It has nothing to do with "VB6 no longer being updated" and will impact any development environment early binding to ADO. – Bob77 Feb 05 '12 at 22:56