We Are GAP Mobilize
Free Assessment Tool

VB6 apps in Windows Store? Wait, what?

by John Browne, on Sep 16, 2016 4:26:54 PM

Scott Hanselman wrote that he used the Desktop App Converter to put a VB6 app in the Windows Store. You can read all about it here

This stirred up a bit of interest among folks with VB6 apps still chugging along (and we know there are a lot of them) because it potentially makes them easier to find and install if they are on the Windows Store. 

Plus once you convert your app to UWP you can add notifications and live tiles. And--at least in theory--the app will run on all Windows 10 devices. 

Full disclaimer: I just read the blog post from Scott and related documentation, but haven't had a chance to actually try this in different scenarios. Yet. 

Since our customers may have questions about this I wanted to briefly summarize my understanding and how it might affect you. 

First of all, how does it work? TL/DR version: app gets referenced inside a manifest; registry and file system I/O are redirected. You have to sign it with a cert so it can be trusted on the Store. Tools Exist.

So here's a quick Q&A for all you VB6 types out there wondering if this will work for you.

Q: Can I put my 15 year old VB6 app in the Windows Store?

A: Maybe.

Q: My app ran on XP (32 bits) and it uses this mossy 16-bit OCX. Will that work?

A: No. (No 16-bitness anymore.)

Q: Are you sure?

A: I'm not sure of anything, except the sun will rise in the east and my code will have bugs. But maybe, just maybe, if you have an old PC with a 32-bit processor and you install the 32-bit version of Windows 10, you can turn on the 16-bit application support (it's off by default) and it might work. YMMV. Note that with a 64-bit processor there is NO way to run 16-bit code. That's a hardware thing, not an OS thing. And Intel hasn't shipped a 32-bit chip in many years. Plus, you can only address a little over 3GB in a 32-bit Win 10 machine and the OS will take up a lot of that. 

Q: What about my 3rd party components?

A: If your installer called regsvr32 to register OCX controls in your original app, I can't see any reason why that won't work now. However, that requires admin level rights, so your installer would have to run in admin mode, not user mode. I think. According to Scott, install tools vendors are updating their kits to make this conversion automatic, but how well they will support some of these low level functions I don't know. 

Q: What about my 3rd party 16-bit OCX?

A: You're hosed (see above).

Q: My app reads and writes the registry. Will it still work?

A: Maybe (this word is getting used way too often in this post). Registry calls are redirected to a file (registry.dat), which you can view with regedit but is not usable for interprocess communication.  

Q: What about file system access?

A: File system access is also redirected to the AppData folder. This is in keeping with other Windows 10 apps so everyone knows where the application's data store is. If you are accessing the file system with hard-coded relative paths I'm not sure what will happen. And, it occurs to me, this might require you to change your install script to account for this difference.

Q: What's a cert?

A: That's out of scope for this blog post. 

Q: I want to run on Windows 10 but not with this. What do I do?

A: Glad you asked.

That is all.



Topics:application migration


Subscribe to Mobilize.Net Blog