Passing Command Line Arguments to a VB6 program on Windows 7/8


My long national nightmare is over!

Back in the late 90s, I wrote a fax viewer program for my then employer, now client.  It was written in VB6 and has been running  without incident on their fleet of XP machines for well over a decade.

We started to migrate off XP and the fax viewer worked fine, but our ability to “launch by association” went away.  We could open the fax viewer, navigate to our folder full of faxes, open one up and do our thing; but double-clicking on a fax no longer opened the fax up automatically.

The command line was being passed just fine, but for whatever reason, the app just wouldn’t open the file.

MsgBox’s showed me the command line and it was exactly what we were passing… and so I left it as an “inconvenience” – we could still get to the fax, but not as slickly as just clicking on the link in the email.

I looked everywhere – thinking it had to do with security contexts, that the UAC was getting in the way of blahdy-blahdy-blah, I had no idea what.  I didn’t stay up on the intricacies of how the security models changed between “Run it All, All the Time” under XP to the more restrictive security models of Vista/7/8, so I figured it had to be that, and I chalked it off.

Fast forward a bit over a year, and we’re rolling out Windows 8.1 now to the rest of the desks that hadn’t gotten Windows 7.  The fax viewer works the same way on Windows 8.1 and it still drives me nuts, so I dug back  into the code to look again, put back my MsgBox’s to look at the command line arguments at runtime, and it hit me.


WindowsXP passes the command line as C:\TEMP\MYFILE.FAX and Win7/8 passes it surrounded by quotes “C:\TEMP\MYFILE.FAX” and when I did my FileExists checking using the FileSystemObject, the check failed when it was passed the filename wrapped in quotes, so it never loaded the file.

Once I stripped out the quotes from the command-line argument, then it passed the FileExists check, loaded up the document and all was well.

Only took me 13 months, but, dammit, I figured it out!

ADO Problems (Error 430) with VB6 on Windows 7

Lot of numbers in that heading. 🙂

We’ve made the move to Windows 7 and we love it.  However, we haven’t really made the move to VB.NET.  I still like developing in VB6; I know that makes me a little bit of a relic, but I don’t do that much development these days to justify the investment in fully ramping up on VB.NET.

So, I had to tweak a legacy application I wrote which reads an email from a POP3 mailbox and writes the contents into a database.  The program is maybe 30 lines long, and it’s a dream thanks to the w3JMail library and ADO.

I revised the program, ran it on my Windows 7 machine, and all was right in the world.  I went to deploy it back to the Windows 2003 server where it lives, and I was hit with Error 430 errors: “Class does not support Automation or does not support expected interface”

So, after adding line numbers to the code, I was able to track the error down to the line

Set objConn = New ADODB.Connection

That seemed weird.  I tried a bunch of different ADO libraries and nothing.  Then I stumbled upon a MSKB article, with the longest, most specific title I’ve seen in recent memory: “An ADO application does not run on down-level operating systems after you recompile it on a computer that is running Windows 7 SP 1 or Windows Server 2008 R2 SP 1 or that has KB983246 installed

Long story short, if you’re running Win7 SP1 or Win08R2 SP1, then .NET breaks ADO and you need to register some new type libraries on your local machine and then recompile using those type libraries, NOT the usual ADO libraries.

The KB article shows you how to do it easily enough. Put the files where they tell you.  I had to manually navigate to the folders for some reason, but once I did, they registered up like a charm and my programs ran again.