Decent Installer for VB6 Apps

[BenMillard]

I've made a few simple VB6 applications, some are general purpose and some are specific to GTA. At the moment I don't provide an installer for them, so people just dump any .ocx files used by special controls into the same folder as the .exe. Also, the .exe.manifest file which sets up the XP theming gets dumped in the folder for all to see.

 

This is very ugly.

 

Worst of all, the FileSystemObject which I use for opening files, validating paths and so on isn't included with any VB runtime packs. It is contained in scrrun.dll which isn't included with some distributions of XP. Users have to get the file from the web and regsrv32 it manually for my programs to work with files on their machines. I only found this out today but have had many reports from people who can't use my programs because of it.

 

So, I need a decent installer/uninstaller which will include all these dependancies and will install them with minimal effort for the user. And won't use a stupid interface to do it.

[DexX]

I'd try the Nullsoft Installer. Its free, and very thorough.

[K^2]

If you load the functions from DLL yourself, simply link the DLL into your executable staticaly. Then all the functions you need will be in the code, and you won't have any dependancies. If you simply use the libraries that have DLL dependancies, either find better libraries, or wirte your own code that works with the functions from DLLs. Idealy, get rid of all the DLL functions, and just write your own code.

[BenMillard]

I don't know what you mean about linking DLLs in statically. Is that possible in VB6?

 

Also, I see no reason (and have no time nor sufficient skill) to reinvent the wheel. The objects and libraries have already been built by better coders than me. I just need an installer which will make sure they are installed correctly on the user's machine.

 

I am going to a friend's house from Tuesday to Friday, so hopefully I'll try out the Nullsoft installer next week of there are no other ideas.

[K^2]

I don't know for sure if VB will allow you to link dynamic libraries statically, but if it does not, it is even worse of a compiler than I thought. (Edit: Even if it can be done, this would only work if you are loading DLL with your own code. If a library does it, it will still try to load a DLL, even if you load all of it staticaly into the code.)

 

What are you using dynamic libraries for anyways? I do not see anything in these programs that would require one. The only times I get an urge to use dynamic libraries is when I want the code to be customizable, and half of these times it turns out to be easier to simply have a separate binary file for each function and load them into RAM manualy, rather than messing with DLLs.

 

Pretty much the only good excuses to use DLLs are if you are making a game with modable behavior, using a DLL for audio/video encoding/decoding, or accessing 3D graphics functionality. The later is usually done through a staticaly linked library anyways. In all other cases, standart and OS static libraries should be sufficient.

Edited June 5, 2006 by K^2

[BenMillard]

The FileSystemObject isn't available in Visual Basic 6.0, it's part of a VBScript DLL (scrrun.dll). Without it, there are no object-oriented file handling capabilities easily available in VB 6.0 apps.

 

I'm using it because it makes the code easier for me to write. I can do things like this:

 

strCurrentLine = objFile.ReadLine(Counter)

It's easy for me to understand that (load the specified line from an object-oriented file reference into the strCurrentLine string variable). Creating a class and figuring out API calls or using the clunky native file handling in VB 6.0 isn't.

 

If I had the time and expertise, I'd use a C-based language. If I had the money, I'd pay to go to university and learn immacculate coding techniques. But since I have none of the above, using the prefabricated object-oriented file handling available in scrrun.dll is the best option for me and many other hobbyist coders.

 

Similarly, using prefabricated controls like the Microsoft Flexible Grid control (MSFlxGrd.ocx) in CFG Studio is a more pragmatic approach for my skill level than creating a new control specifically tailored to what CFG Studio needs.

 

If these dependancies can be incorporated directly into the EXE that would be neater, yes. However, VB is made up of many runtime libraries and objects. Incoporating all these into one EXE could end up being rather larger. As long as the prefabricated VB libraries and objects get installed onto the user's machine correctly (if they don't have them already), users will be unaware of the dispersed code under the hood.

 

I hope this helps you better understand my requirements and limitations. The best option available to me is to find an installer which can ensure the dependancies my programs have are installed correctly.

Edited June 5, 2006 by Cerbera

[K^2]

This... This is like using duct tape to build a cupboard. VB has built in File I/O that is more than sufficient for your needs.

 

VB6 costs money. C++ compilers, such as Dev-C++ are free. There are also plenty of on-line tutorials on C++, which are also free. If you want to learn to program in C/C++, you do not need a cent.

 

I don't mean to push you, or anything. I only want to point out that there are much better solutions than what you are using. It's your choice, though.