SHP Forums

Hi all,

I'm trying to use the QFG 95 editor that's linked here, but when I try to install it, I get this error:

"The program can't start because MSVBVM50.DLL is missing from your computer. Try reinstalling the program to fix this problem."

I checked and I do have the dll. I even put it in the same directory as the install directory but it doesn't work.

Would anyone have an already installed version of the program that I can try using? Or a way to get it to install properly? Thanks.

That is a Visual Basic runtime file. Perhaps it is not registered? Try going to the Microsoft downloads and get the VB runtime installer.

Sorry for reviving this months dead thread, but I stumbled across this thread today, and I felt compelled to add my 2¢.

I'm the original author of the Quest For Glory Importer '95, and Collector is absolutely correct about needing the VB5 Runtime. There was a time when you didn't need to manually install the VB5 Runtime files before you could run the *installer* but those times have apparently passed.

I've just personally tested this in Windows 7 (which leads me to believe the same will apply to Vista and 8), and if you download/install the VB5 Runtime files (http://download.microsoft.com/download/ ... vbvm50.exe) before running the QFG Importer's SETUP.EXE, it should all work as intended. If that link stops working, you should be able to still get the file from this page: http://support.microsoft.com/kb/180071.

Collector, if you have the bandwidth to spare, it might be worthwhile to include the msvbvm50.exe file in the QfGCharacterImportEditor.zip file, as I think anybody wanting to use it today will need it. If you don't have the bandwidth then maybe just a link to either of the above from the download page?

Frankly, I'm surprised that *anybody* still tries to use it, given how long ago I wrote it. But it has given me pause. I did a little digging around on my computer, and I discovered I do still have the source code. I'd be pleased to release the source code if you have any desire to host it.

Thanks for responding. I had thought about repackaging it in a modern installer with the MSVBVM50.DLL included, but never got around to it. The runtime does not need to be registered. All that is required is to include a copy in the installed folder. If you have the source, I would happily host it. I might even look into porting it to the .NET framework to remove the old VB runtime dependencies. It shouldn't be too hard as long as it is not too reliant on outdated APIs.Might be easier to do it in a two stage process with VB.NET as an intermediary step, if I can get my mind to think in VB.NET again.

BTW, didn't you use to go by "Unknown Hero" on the old WebX Sierra board?

I did. Those were fun times.

Unfortunately, it isn't just the MSVBVM50.DLL file that needs to be registered. That's needed for the installer (as well as the program), but the program also needs COMDLG32.OCX registered.

In my (admittedly brief) attempt at troubleshooting it, I just placing COMDLS32.OCX in the same folder didn't work, and my attempt at manually registering it with the below command was only met with failure. Even in a command prompt that was elevated to Administrator privileges.
As a "what-have-I-got-to-lose" effort, I tried Microsoft's VB5 runtime distributable (linked in post above), and that solved all the problems I had running it, so I'd definitely recommend that as a "path-of-least-resistance" solution.

I thought of up-converting it from VB5 to .NET myself, but then we're just trading one set of dependencies (VB5 runtime) for another (.NET runtime), which both have an almost equal chance of already being on somebody's system (as in neither one's guaranteed, but .NET is arguably much more active today). You're certainly welcome to give it a go, of course. I'll PM you the source code in a few minutes (providing I can attach 1.3MB zip files).

Welcome to SHP. You should find some familiar names here.

Charles wrote:placing COMDLS32.OCX in the same folder didn't work, and my attempt at manually registering it with the below command was only met with failure. Even in a command prompt that was elevated to Administrator privileges.

That is odd, as it works for me. As to registering the OCX, remember that this is a 32 bit file,. and as such it resides in the SysWOW64 directory instead of the System32. If you try copying it to the System32, it will be redirected to SysWOW64. For some reason manually registering it Regsvr32 will not find it unless you give it the full path to the OCX. Make sure that it is in the SysWOW64 directory and use the full path, i.e. If this is done via an installer, Windows will automatically redirect everything to the right place.

As to the VB runtimes vs the .NET framework, that will not be an issue for some time to come. Vista onward comes with the framework and would not run without it. Most drivers no require it. C#, one of the most popular languages today, requires it. Five or more years ago and earlier, .NET apps usually came with a warning that the framework needed to be installed, but no one bothers anymore as it is assumed that most already have at least one of the earlier versions.

Thanks for the source. The games are still fairly popular, so there may still be some demand. Whether I will have the time to try to port this remains to be seen. Currently all of my spare time for such endeavors is spent on a fairly large C# project. On my old machine I still have VS2008 installed, which should do most of the work of porting to VB.NET. Usually, it does not take that much going from VB.NET to C#, where I'll feel more comfortable.

Here it is ported to .NET. It requires no antiquated dependencies.

That was quick work. Looks good.

I did run into a small bug, related to the save dialog.
Couple minor things, actually:

• the save as type is blank
• appends an extra .sav to the filename
• cancel button saves anyway
• after save msgbox takes the variable as a string: i.e. Character creation in " & dlgCommonDialogOpen.FileName & " Successful.
• Then an "Error 5. Value cannot be null," and the program hard crashes.

It does create the file successfully before crashing, and everything else looks like it works as expected.

It was just a very quick and dirty porting. I didn't bother to do any testing to speak of. The code just has too much antiquated VB stuff to make it an easy conversion to C#, where I would feel much more comfortable in working out issues. As it was, I just disabled unneeded stuff rather than fixing it. You had a startup script to display the splash screen that was coded in a way that would close the main form on load. I just made the main form the startup form.

What I disabled was the registration and hiding of features and the System info. Registry handling is done differently in .NET. That part would be easier to recode than to port and really serves no purpose for this tool. Radio button handling is done very differently in .NET. Just placing radio buttons in a groupbox now automatically handles the deselection of other buttons when a different one is selected. VB.NET allowed the old method to work using VisualBasic.Compatibility, but that is not an option with C#. The storing of images can be be done natively in the assembly's resource. The VB PowerPacks is another obstacle to an easy C# conversion.

I did port to C#, but there were too many incompatibilities to get it to compile without a lot more effort. When I have more time, I'll have another go at a C# port. I did port it to C#, but it will take a fair bit more effort to get it to compile. It might help to update the all of the obsolete stuff in VB.NET before porting, but I don't really like working in VB. It may be easier and faster to simply rewrite it from scratch in C#.

It may be easier and faster to simply rewrite it from scratch in C#.

Given how long ago I'd written it, how much I've learned in the decade since, and how ridiculously simple a program it is, I couldn't agree more.