5

Are only basic VB6 Applications running on WIN8? Are any API's different in use like GDI+, Keyhooks, FileSystem or RtlMoveMemory Apis.

VB6 is x86, Win8 is x64.

I already read: VB6 Running on Windows 8?

Community
  • 1
  • 1
tbe
  • 86
  • 1
  • 6

3 Answers3

7

Windows 8 does not change the basic APIs for Windows desktop apps. (except, of course for Windows RT)

Future versions of Windows also won't; any changes to those APIs would break compatibility with all existing applications.

SLaks
  • 868,454
  • 176
  • 1,908
  • 1,964
  • There are a lot of changes like the interfaces for anything. Are you sure the VB6 x86 Apps will work with x64 Win8 API's? – Nasenbaer Nov 23 '12 at 13:57
  • @Nasenbaer: What are you talking about? He's asking about basic Windows APIs. – SLaks Nov 23 '12 at 13:59
  • EVERY VB6 App is x86 and EVERY Win8 is x64. I thing that needs to keep in mind. And Also there has changed some stuff in Win8 which is not the same as in Win98, WinXP, Win7 ... I don't know but perhaps API's had changed too or are no more supported? – Nasenbaer Nov 23 '12 at 14:04
  • 5
    @Nasenbaer: Wrong; WIndows 8 is also available as x86. Also, Windows x64 can still run x86 apps. And, Windows 8 does not break compatibility. – SLaks Nov 23 '12 at 14:08
4

We have just started testing our VB6 app on Windows 8 x64. The app is huge and complicated. Things generally seem to work, even older third-party OCX controls, etc. ADO/MDAC works fine with various versions of SQL Server. There are lots of Win32 API call that seem to work fine, too. We were also able to install the VB6 IDE on Windows 8 x64 for testing and debugging.

The very first problem, though, was a generic 50003 error and a message saying it couldn't create the main application form or something like that. Further investigation revealed that Windows 8 for some reason doesn't like some of the icons embedded in forms (they are stored in the form's accompanying .frx file and embedded in the .exe at compile time). It appears it may be related to icons with transparent backgrounds.

The app has approx. 100 forms that are affected. Once this problem is fixed the app seems to work fine. But this one thing breaks our distribution executable that runs fine on Windows 7 (and Vista and XP and all server versions, and older versions ran on 2000, Win98 and Win95). It can be easily fixed, but we were hoping to not have to do anything. Sigh.

I'd be interested if anyone else has seen this or has any tips or suggestions.

P.S. @Hans Passant, the Windows 7 SP1 ADO problem is fixed with KB2640696.

R. Neal
  • 41
  • 2
  • Figured out the problem. Some forms have 16 bit color depth icons embedded. Changed them to have 256 color and RBG/A and it seems to fix it. Wish we didn't need to do this. – R. Neal Dec 15 '12 at 15:43
3

Keeping old VB6 programs running is definitely getting harder. Windows 7 SP1 deployed a long overdue update to ADO which will stop old VB6 dbase apps from working. There were two critical security patches for MSCOMCTL.OCX this year, one of them changed the guids.

While you could keep old machines running an old VB6 app by just skipping these updates, Windows 8 is going to have them in place and you can't revert. You'll have to rebuild your app on a machine with these updates so it uses the new type libraries. If that's not an option then a virtual machine is the way to keep it going. I however don't see support yet for Virtual XP Mode.

Community
  • 1
  • 1
Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • x86 ADO typelib on Win8 is backwards compatible just ok, so they basicly undid/fixed the change made with Win7 SP1. Win7 SP2 will probably revert ADO typelib on Win7 too. – wqw Nov 23 '12 at 16:12
  • 1
    And MSCOMCTL.OCX is never installed as part of any version of Windows, so no problem there. You only get into trouble if you installed one of those multiply-broken "security rollup" attempts they've been trying and failing at since 2008 onto your dev machine, and you are deploying the live copy of the OCX from your dev machine (a no-no) instead of from the Redist folder or a standard merge module. – Bob77 Nov 23 '12 at 16:30
  • @Bob: Ahaaa, so even these patched MSCOMCTL.OCX are just fine on client machines if VB6 app is compiled against "good" versions of it on dev machine? – wqw Nov 24 '12 at 09:12
  • 1
    The only way a broken version of MSCOMCTL.OCX gets onto a client system is that somebody has deployed it there. Once somebody has contaminated the machine your own program only has one chance: an isolated assembly. Windows Update does not push these broken libraries to clients, they were intended only as developer updates. Sadly they're defective. ADO vs. Win7PS1 is a different case, involving Type information used at compile time. Those are not a problem if you compile against a good typelib. – Bob77 Nov 24 '12 at 13:09