[RESOLVED] What needs to be distributed to install VB6 apps?

[cafeenman]

I'm only asking about the intrinsic stuff.

I assume that all the ocx controls are probably on win 10 and such but not sure.

Also, what about DAO 3.6?

I'm asking because I'd like to put the beta of my app on my site with just the exe and whatever datafiles rather than do an install script.

Just so it unzips and is ready to go.

[BenJones]

You should be ok most Win10 and Win11 come with VB6 stuff installed unless your using any thrid party ocx you should be ok, You if your that concerned you chould just upload the VB6 runtimes files. you may also have to sign your exe's all most Virus Killers will kick off.

[cafeenman]

Thanks. I've never signed an exe. I'll have to look that one up.

[BenJones]

Some info on sign https://learn.microsoft.com/en-us/wi...rypto/signtool

https://stackoverflow.com/questions/...63704#52963704

Frontend for sign
https://www.briggsoft.com/signgui.htm

Hope that helps

[cafeenman]

Thanks. I'm reading it. Not sure how to get a certificate. You don't need to reply. I can research it.

Appreciate your help.

[DrBobby]

Having a virtual machine with w10/11 on it can come in pretty handy for seeing what you need to ship with your program. Personally I use vm workstation but you can find free software that can do most of the same stuff.

Any that have snapshot features where you can roll the vm back to before you did anything are more than worth it imho. Makes testing installers and what not much less painful.

[Elroy]

I'm only asking about the intrinsic stuff.

I assume that all the ocx controls are probably on win 10 and such but not sure.

Those two sentences taken together don't make sense to me. The "intrinsic controls" don't have any OCX files associated with them. They're all wrapped into the VB6 runtime, which has been pre-installed with the Windows OS since Windows XP, through Windows 11 (and hopefully beyond).

Also, what about DAO 3.6?

The DAO360.dll isn't intrinsically part of VB6, but it too has been pre-installed with the Windows OS since Windows XP. If Windows has been installed correctly, it should just "be there", all registered and ready to use.

---

Therefore, if you stick with the intrinsic controls and DAO 3.6, you'll have no need for an installer. Your VB6 compiled EXE should be completely portable (excluding any other custom data files your code needs).

[SomeYguy]

The DAO360.dll isn't intrinsically part of VB6, but it too has been pre-installed with the Windows OS since Windows XP. If Windows has been installed correctly, it should just "be there", all registered and ready to use.

---

Therefore, if you stick with the intrinsic controls and DAO 3.6, you'll have no need for an installer. Your VB6 compiled EXE should be completely portable (excluding any other custom data files your code needs).

This ^^^^^. I used to not mind writing an installer, but for the last few years I've gone to great length to keep my applications portable so that they can run directly from a portable storage device if needed.

Another consideration is where to store application settings and such. I was using custom settings files which were created by my programs and located in the application folder but that resulted in settings files sometimes appearing in unwanted places such as the desktop and so I recently moved to using a standard INI file which is stored in the user's app settings folder on the target machine.

[Elroy]

Another consideration is where to store application settings and such. I was using custom settings files which were created by my programs and located in the application folder but that resulted in settings files sometimes appearing in unwanted places such as the desktop and so I recently moved to using a standard INI file which is stored in the user's app settings folder on the target machine.

There are one-of-three (or maybe four) places I always go:

1) the registry, which is specifically designed for "settings" type things;

2) A sub-folder somewhere in C:\ProgramData (using the API to actually get that folder location). This one allows any/all users on that machine to "see" the settings.

3) A sub-folder somewhere in C:\Users\Elroy\AppData\Local (again, using the API to actually get that folder location). This one has the advantage of being specific to the particular user logged in.

4) Or, if we want to acknowledge "Windows Roaming", a sub-folder somewhere in C:\Users\Elroy\AppData\Roaming (again, using the API to actually get that folder location). This one has the advantage of being specific to the particular user logged in, but allows them to use "Roaming" features.

Those areas are very specifically designed to do what you're suggesting.

And just setting down files in the program's folder is absolutely a no no.

[Elroy]

Just for you, SomeYguy:

Option Explicit
'
Private Declare Function SHGetSpecialFolderLocation Lib "shell32" (ByVal hWndOwner As Long, ByVal nFolder As Long, pIDL As Long) As Long
Private Declare Function SHGetPathFromIDListW Lib "shell32.dll" (ByVal pIDL As Long, ByVal pszPath As Long) As Long
Private Declare Sub CoTaskMemFree Lib "ole32.dll" (ByVal pv As Long)
'
Public Enum CSIDL_CODE
    CSIDL_APPDATA = &H1A&
    CSIDL_LOCAL_APPDATA = &H1C&
    CSIDL_COMMON_APPDATA = &H23&
End Enum


Public Function GetSpecialFolder(ByVal CSIDL As Long) As String
    ' Always includes terminating backslash.
    Dim ppidl As Long
    '
    If SHGetSpecialFolderLocation(0, CSIDL, ppidl) = 0 Then
        GetSpecialFolder = String$(260, 0)
        If SHGetPathFromIDListW(ppidl, StrPtr(GetSpecialFolder)) Then
            Do
                If Right$(GetSpecialFolder, 1&) <> vbNullChar Then Exit Do
                GetSpecialFolder = Left$(GetSpecialFolder, Len(GetSpecialFolder) - 1&)
            Loop
            If Right$(GetSpecialFolder, 1) <> "\" Then GetSpecialFolder = GetSpecialFolder & "\"
        Else
            GetSpecialFolder = vbNullString
        End If
        CoTaskMemFree ppidl
    End If
End Function

Private Sub Form_Load()
    Debug.Print GetSpecialFolder(CSIDL_COMMON_APPDATA)
    Debug.Print GetSpecialFolder(CSIDL_LOCAL_APPDATA)
    Debug.Print GetSpecialFolder(CSIDL_APPDATA)
End Sub

Output:

C:\ProgramData\
C:\Users\Elroy\AppData\Local\
C:\Users\Elroy\AppData\Roaming\

[SomeYguy]

4) Or, if we want to acknowledge "Windows Roaming", a sub-folder somewhere in C:\Users\Elroy\AppData\Roaming (again, using the API to actually get that folder location). This one has the advantage of being specific to the particular user logged in, but allows them to use "Roaming" features.

This is how I do it now, and using an API call to get that folder. Before, I was storing everything in a UDT and then writing/reading from disk in the program directory. Seemed like a good idea at the time - about 15 yrs. ago .

[SomeYguy]

Just for you, SomeYguy:

Option Explicit
'
Private Declare Function SHGetSpecialFolderLocation Lib "shell32" (ByVal hWndOwner As Long, ByVal nFolder As Long, pIDL As Long) As Long
Private Declare Function SHGetPathFromIDListW Lib "shell32.dll" (ByVal pIDL As Long, ByVal pszPath As Long) As Long
Private Declare Sub CoTaskMemFree Lib "ole32.dll" (ByVal pv As Long)
'
Public Enum CSIDL_CODE
    CSIDL_APPDATA = &H1A&
    CSIDL_LOCAL_APPDATA = &H1C&
    CSIDL_COMMON_APPDATA = &H23&
End Enum


Public Function GetSpecialFolder(ByVal CSIDL As Long) As String
    ' Always includes terminating backslash.
    Dim ppidl As Long
    '
    If SHGetSpecialFolderLocation(0, CSIDL, ppidl) = 0 Then
        GetSpecialFolder = String$(260, 0)
        If SHGetPathFromIDListW(ppidl, StrPtr(GetSpecialFolder)) Then
            Do
                If Right$(GetSpecialFolder, 1&) <> vbNullChar Then Exit Do
                GetSpecialFolder = Left$(GetSpecialFolder, Len(GetSpecialFolder) - 1&)
            Loop
            If Right$(GetSpecialFolder, 1) <> "\" Then GetSpecialFolder = GetSpecialFolder & "\"
        Else
            GetSpecialFolder = vbNullString
        End If
        CoTaskMemFree ppidl
    End If
End Function

Private Sub Form_Load()
    Debug.Print GetSpecialFolder(CSIDL_COMMON_APPDATA)
    Debug.Print GetSpecialFolder(CSIDL_LOCAL_APPDATA)
    Debug.Print GetSpecialFolder(CSIDL_APPDATA)
End Sub

Output:

Thanks Elroy, pretty much same as I have implemented in my stuff .

[SomeYguy]

P.S. - About 6 months ago when I was looking at better methods to store & retrieve settings, I toyed with using the registry. But I didn't want my apps to leave zombie entries behind. I realize that they do leave behind an ini file now but lesser of two evils I think.....

[Elroy]

IDK, to me, they're not "zombie" settings if they're settings the user expects to be persistent every time the user sits down at that computer and uses your program.

[SomeYguy]

IDK, to me, they're not "zombie" settings if they're settings the user expects to be persistent every time the user sits down at that computer and uses your program.

True but an example for my case is that I worked for the local YMCA for many years and would often write small in-house tools which would be used maybe 2-3 times on the same machine and then forgotten. And as the Y periodically runs virus scanners and registry cleaners on their machines I wasn't sure of my possible reg entries so I erred on the side of caution .

[AAraya]

I'm only asking about the intrinsic stuff.

I assume that all the ocx controls are probably on win 10 and such but not sure.

Also, what about DAO 3.6?

I'm asking because I'd like to put the beta of my app on my site with just the exe and whatever datafiles rather than do an install script.

Just so it unzips and is ready to go.

The only intrinsic VB6 or Windows file I need to distribute with my apps is the The Microsoft Standard Data Formatting Object Library - Msstdfmt.dll