Member Avatar for chandrasekar_N

Hi,
I have a VB6.0 application, which is functioning in windows XP operating system,
And I’m going to use the application in Windows 7 operating system.

In this application I am using the following OCX controls,
• Keysta32.ocx
• Grid32.ocx
• Threed32.ocx
• Mschart.ocx

The "Support Statement for Visual Basic 6.0 on Windows Vista, Windows Server 2008 and Windows 7" of Microsoft says that these runtime files will not be supported in the Windows 7 OS

Refer: http://msdn.microsoft.com/en-us/vbrun/ms788708.aspx

But I can able to register these OCX files in Windows 7 OS, can able access the properties, methods and events of these controls, and working fine in a sample VB6.0 application.

I need to know,

What are the risks involved in using these Unsupported OCX controls in my application when moved to Windows 7 OS?

If there are any issues then is there any solution / replacement for these OCX controls.

Let me know the detail of the compatibility issues of these OCX controls in windows 7 OS.

Thanks,

  • 3 Contributors
  • 3 Replies
  • 280 Views
  • 9 Hours Discussion Span
  • Latest Post Latest Post by Suspishio

Dani AI

Generated

Short answer: Microsoft’s VB6 support statement explicitly lists the controls you named (keysta32.ocx, grid32.ocx, threed32.ocx) as unsupported runtime files, while mschart.ocx is in the “unsupported but updates/upgrades available” category. That means those OCXs can sometimes be registered and run on Windows 7, but Microsoft will not guarantee fixes or servicing for them — and VB6 runtime behavior is 32‑bit only (runs under WOW64 on x64 OS). (learn.microsoft.com)

Main risks to plan for:

  • No vendor/MS fixes if a Windows update breaks the OCX or exposes a security issue (you’re on your own unless the OCX vendor supports it). (learn.microsoft.com)
  • 64‑bit Windows: 32‑bit OCXs must be registered in the SysWOW64 context and often fail if dependencies are missing. Run the 32‑bit regsvr32 from SysWOW64 when needed. (support.microsoft.com)
  • UAC, installer/registration mistakes, COM registration conflicts, or missing transitive DLLs can cause “works on dev machine but not on user machines.” Use dependency and runtime tracing tools to find those. (learn.microsoft.com)

Practical mitigation and replacement options:

  • Short term: test the exact app on clean Windows 7 VMs (x86 and x64), install elevated, register OCXs from the correct regsvr32, and exercise all features (as recommended). Use the Application Compatibility Toolkit and Process Monitor to capture failures and create shims/mitigations. (learn.microsoft.com)
  • Mid term: bundle only supported VB6 runtime/extended files (Microsoft published a runtime-extended rollup you can use for some controls such as MSChart). (support.microsoft.com)
  • Long term: replace unsupported ActiveX with supported alternatives (for example, move charts/grids to .NET equivalents — the .NET Charting library and DataGridView — or third‑party supported controls) or migrate the app to VB.NET/.NET using Microsoft’s upgrade guidance. ’s “upgrade” advice is the most future‑proof route. (learn.microsoft.com)

Quick checklist to follow now:

  1. Build two Win7 VMs (x86 and x64).
  2. Install app with an elevated installer; register OCXs using the correct regsvr32. (support.microsoft.com)
  3. Reproduce every feature while logging with Procmon and (if needed) Dependency Walker. (learn.microsoft.com)
  4. If anything breaks, decide: package+shim it for short term, or plan replacement/migration for long term. Note: Windows 7 itself went out of mainstream support (see Microsoft lifecycle), so plan upgrades rather than indefinite reliance on an unsupported OS. (learn.microsoft.com)

This expands on ’s findings and ties into ’s testing suggestion and ’s upgrade suggestion with concrete next steps and Microsoft references.

Recommended Answers

All 3 Replies

Member Avatar for Suspishio

It might be asking too much for others to tell you the risks of using specific OCX controls under Windows 7.

The questions you ask about replacements for the unsupported OCXs is reasonable. Have you put the questions to Microsoft?

On the principle of using unsupported OCXs, you'd be doing this forum a useful service if you run your application on a testbed system under Windows 7, in a variety of scenarios such as concurrent Office applications and then report any noteworthy effects, issues or successes.

Good luck.

Member Avatar for cguan_77

upgrade your app to vb 2008

Member Avatar for Suspishio

upgrade your app to vb 2008

Yeah - the simple solutions are the best solutions!

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.