Still celebrating National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17


Getting an XP program to run with Win7

Posted on 2014-07-25
Medium Priority
Last Modified: 2014-08-03
I’ve skated around this issue here with various questions, but now I have to get serious.

I have a couple of rather large programs that I created some time back with VB6 running under XP. People depend on them.

I’m looking for some guidance here. What’s a good way to create a setup.exe installer that will allow my programs to run on Win7? I’ve used “inno”. Is there a better one? Inno seems easy enough to use.

There are other alternatives. I understand that an XP emulator can be installed on Win7.

I don’t know the best way to proceed.

Multiple opinions will be appreciated.

To my knowledge, the major difficulty is MSFLXGRD.OCX
Question by:NormaPosy
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 5
  • 3
  • 2
  • +1
LVL 98

Assisted Solution

by:John Hurst
John Hurst earned 400 total points
ID: 40220793
You can try to run the programs in compatibility mode. Select XP compatibility in the program run properties.

If that fails, you can get XP Mode for free for Windows 7 Pro and above.

But XP Mode is not available in Windows 8 or 9 (soon to come). Windows 7 is at the end of mainstream life in 6 months. So then an XP machine running in a virtualizer such as VMware is a better long term choice.

Then think about modernizing your program.
LVL 14

Expert Comment

ID: 40220805
Have you tried manually installing the OCX in Win7? Copy the file to the system32 directory, then run this command:
regsvr32 C:\windows\system32\MSFLXGRD.OCX

Open in new window

If the OCX is 32bit, but Win7 is 64bit, then copy the OCX to C:\Windows\SysWOW64\ and use this version of the command
regsvr32 C:\Windows\SysWOW64\MSFLXGRD.OCX 

Open in new window


Author Comment

ID: 40221619

How do I determine the 32/64 bit size for this ocx, and my Win7?
I have Win7 "Home Premier".


Will this upgrading/back compatibility issue always be with us?
Simplifying Server Workload Migrations

This use case outlines the migration challenges that organizations face and how the Acronis AnyData Engine supports physical-to-physical (P2P), physical-to-virtual (P2V), virtual to physical (V2P), and cross-virtual (V2V) migration scenarios to address these challenges.

LVL 98

Expert Comment

by:John Hurst
ID: 40221621
As long as you are using old legacy VB then yes, you will always have to figure out compatibility. The world turned 64-bits for good now.
LVL 14

Expert Comment

ID: 40221869
The OCX is probably 32bit. For Win7, the C:\Windows\SysWOW64 folder only exists on 64bit Win7. If you have that folder, use the instructions I gave you for 64bit. If not, use the 32bit instructions.

Author Comment

ID: 40227975
32 bit Win7 ok
Copied the OCX to C:\windows\system32
Got a message box telling me that I need administration privileges to copy there. (Not sure of wording exactly, didn't write it down). But proceeded anyway. The OCX appears in  \system32 all right. But it may have been there from a prior attempt at application setup using "inno" setup builder.

Ran regsvr32.  (Checked spelling carefully).

Got a message box saying MSFLXGRD.OCX wasn't there.

By the way: I take it that, when the application runs, it knows to look in the \system32 folder for the OCX, Reason why I mention this: I have several copies of that OCX in various folders holding various versions of the application. I suppose they are all just taking up space. The one in \system32 is the one actually used when the application is launched. Is that right?

I appreciate your help.
LVL 14

Accepted Solution

ThomasMcA2 earned 800 total points
ID: 40228178
Registering the file with regsvr32 creates a link to the file so that applications can find the "published" version in the system32 folder.

To see if the file is there, run this DOS command:
dir C:\windows\system32\MSFLXGRD.OCX

Open in new window

You should get output similar to this:
 Volume in drive C has no label.
 Volume Serial Number is D467-3BD9

 Directory of C:\windows\system32

10/10/2008  06:06 PM           259,912 msflxgrd.ocx
               1 File(s)        259,912 bytes
               0 Dir(s)  19,672,698,880 bytes free

Open in new window

Is the file there? If so, continue with the next step.

Copy and paste the following command to confirm the registration process (it doesn't hurt to run it again.)
regsvr32 C:\windows\system32\MSFLXGRD.OCX

Open in new window

You should get a popup that says "DLLRegisterServer in C:\windows\system32\MSFLXGRD.OCX succeeded."

Then try your application again.

Author Comment

ID: 40236885
Sorry for the delay getting back to you.
Too much going on here.
Your guidance is appreciated.
I should have results to report by end of tomorrow (Sunday).

Author Comment

ID: 40236886
I hit "Submit" again. Sorry.
LVL 38

Assisted Solution

BillDL earned 800 total points
ID: 40237345
From what I can determine, MSFLXGRD.OCX is not native to a standard installation of Windows XP with SP3 and all Windows Updates, IE8, and Office 2003.

An OCX or DLL file is only "self-registerable" using REGSVR32.EXE if it contains registry data.  You can usually get a quick insight into an OCX file by opening it in Windows Notepad and scrolling down looking for the layout to change from gobbledegook symbols and double-spaced uppercase into indented programming code with loads of opening and closing curly brackets.  Usually this comes immediately after you see:
 R E G I S T R Y  A V I  T Y P E L I B

Registry data in an OCX or DLL often creates Class Identifiers for the process, in which case you will see lines like this:

      CLSID = s '{22D6F312-B0F6-11D0-94AB-0080C74C7E95}'
      val 'EditFlags' = d 65536

If you don't see any of the typical registry-related lines when you view the file in a text editor, then the file is probably not self-registerable.

When you compile a program so that it is compatible with specific Operating Systems, development applications like Visual Basic avoid creating superfluous and repetitive code by assuming that certain native Windows "libraries" (DLLs, OCXs, etc) will already be present and available for the program to call upon and use.  Where a program is compiled for different Operating Systems that have different versions of those files, the installer package is written to detect the OS and install the correct versions where necessary.  To avoid version conflicts, as used to happen in Windows 98, Windows XP started using the "Side-by-Side" folder (C:\Windows\WinSxS) folder to store different versions of DLLs, etc in separate sub-folders along with manifests to inform programs and the OS about the versions.

What you often find with a program and companion "library" files (DLLs and OCXs) written for Windows XP before Windows 7 was released, is that certain shared library files installed by Windows 7 are significantly different from those on XP and the cross-talking calls between them are unable to find the resources needed in a named DLL, or cannot find the specified "Entry Point" into them to get to the named resource.

One program that can walk through and simulate all the calls to and from files to determine such issues is Dependency Walker which will flag up failed calls to and from the file.  It came in either the Support Tools or Resource Kit for XP, but was always available from:
where it is said to be supported by Windows 7.

If you copy MSFLXGRD.OCX into the System32 folder of a Windows 7 computer and load the program's EXE into Dependency Walker, you should get an idea if it is failing anywhere, especially when calling MSFLXGRD.OCX.

If MSFLXGRD.OCX does not exist in the System32 folder, then just place a copy of it in the same folder as the program EXE and test the EXE with Dependency Walker.

Personally I see no problem with having separate copies of MSFLXGRD.OCX in each of the program folders for the different versions of the program as long as they are either the same version or, if different versions for each version of the EXE, that you don't run more than one instance of the EXE from separate folders.  That's where version conflicts can manifest themselves as they used to in Windows 98 when numerous programs would all create copies of different DLL versions in different folders.  Admittedly part of the issue with Win98 was that the OS didn't release DLL resources from memory once finished with them, and XP improved this, but you can still get issues in newer operating systems.

One other potential issue is if your program has a "legacy" Windows 98/XP *.CHM Help File.  Windows 7 needs a compatibility add-in:
and this may also be relevant:

Author Closing Comment

ID: 40237867
Deep gratitude!

John: I'm going to look into XP emulation when I get some free time.

Thomas: Your kind replies took care of my specific immediate problem.

Bill: Good tutorial. Clear and concise. I learned a lot.

Discussion: A lot of people depend on these two applications I developed, and it is essential that I get them to run on newer OSs. They are rather large, and re-writing the code in a "modern" language is a forbidding task. I'm supposed to be retired, but happy to do what I can to provide "legacy" support. I'm not up to a full re-write.

I've advised the "higher-ups" that sooner or later they will have to hire a professional to do a re-write of the code. But it is their call. As long as I'm recompensed in a legacy support role, it is ok by me.

Thank you all again - - Norma
LVL 38

Expert Comment

ID: 40238362
Thank you Norma.

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

If you need to start windows update installation remotely or as a scheduled task you will find this very helpful.
When you try to share a printer , you may receive one of the following error messages. Error message when you use the Add Printer Wizard to share a printer: Windows could not share your printer. Operation could not be completed (Error 0x000006…
Show developers how to use a criteria form to limit the data that appears on an Access report. It is a common requirement that users can specify the criteria for a report at runtime. The easiest way to accomplish this is using a criteria form that a…
The Task Scheduler is a powerful tool that is built into Windows. It allows you to schedule tasks (actions) on a recurring basis, such as hourly, daily, weekly, monthly, at log on, at startup, on idle, etc. This video Micro Tutorial is a brief intro…
Suggested Courses

688 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question