Is it possible to run an application compiled with VB4 on Windows 7 x64?

Question 1

I am running VB3 applications with no problems on ... XP Vista 32-bit Win-7 32-bit Win-8 32-bit Win-8.1 32-bit Win-10 32-bit

Microsoft may not SUPPORT this but it works OK. So I'd suggest that VB4 16-bit applications should work OK on all of these operating systems as well.

I'd guess that VB4 32-bit applications should work OK on both the 32-bit and 64-bit versions of Windows.

The easiest way to find out would be to write a very simple APP in VB4 32-biut and try to run it on the target system and see what happens. Assuming that this works OK you can try converting your application and see what happens.

I'd agree that you'd be better off going directly to VB6 though rather than just to VB4. I haven't tried to migrate VB3 to VB4 but I have migrated VB3 to VB6 and it was a nightmare.

My VB3 apps have in excess of 500,000 lines of code. I keep bumping into memory problems with them because of this.

My conversion process is to (1) copy the VB3 source files to a new directory. (2) I then run a global search and replace on those files to replace the control type names with the VB6 equivalents and make changes to the format of the *.FRM files to look like VB6 forms. I did try to just open them in VB6 and had conversion issues. (3) Open the project in VB6, allow it to make any changes and then save it. (4) run another global search and replace to correct issues that I know are still a hassle. (5) open the project in VB6 again and try to compile it - correct each error as it is encountered and keep going until it compiles. (6) Once it actually compiles then start the debugging process.

Many of the controls have different property names and so the debugging is tiresome. I also used 3rd party controls (eg Truegrid) and their 32-bit equivalents are totally different. Even the Microsoft standard grids have different properties. Spin buttons in VB3 become UpDown controls in VB6 etc.

I tried to convert my VB3 programs several times and gave up because I ran out of time before I could get them to compile. In the end I rewrote a lot of the programs in VB6 rather than converting them.

When I say I did a global search and replace - I actually wrote a VB6 program to do this as it wasn't a simple process.

MSAccess database commands are also different especially if you move to ADO instead of DAO. This wasn't too much of a problem for me as I had already encapsulated all of these functions in my own subroutines with standard error checking etc so I only had to change the actual database commands within my standard routines and not in the bulk of the program. I had done this because of my history where every time a new programming language version came out or was run on a different brand of machine then the commands were different (back in the old days before even MS-DOS) so I wanted to protect myself from this. It also means that if I wanted to use the BTrieve engine instead of Access or Sybase or MySQL etc then I could just change the subroutines and the rest of the program should work OK. Over the years I've used about 20 different database engines.

Question 2

This runtime is not supported on Windows 7. In fact I am astounded that you are working on such an old version. The only "classic" VB runtime which is supported on Windows 7 is VB6 SP6. Furthermore, I am not sure if any controls other than Common Controls are supported.