Topic: BassCD: Project looks for wrong dll

[murspieg]

We have a project containing the basscd.bas and bass.bas modules.  We are in process of upgrading the project from 2.3 to 2.4   (32bit IDE environment, VB6).

Basscd.bas starts with ' BASSCD 2.4 Visual Basic module
Bass.bas starts with ' BASS 2.4 Visual Basic module

In the same directory as the project are bass.dll and basscd.dll taken from the respective *24.zip files. 

The project.vbp file contains:
Module=modBass; bass.bas
Module=BASSCD; basscd.bas
 that is, it's using the bas files in the current directory.

Yet when run, the error box (written by BassCD) says "Incorrect BASS.DLL version (2.3 is required)"

What are we overlooking? Why is the project pulling a bassCD that wants 2.3 (what our old project code used)?
Tnx

[Chris]

Can you make a "File-Search" if in a SearchPath is a old basscd.dll ? (e.g Windows\System32)

[murspieg]

Even if this were the case, wouldn't the project first look in its current directory?
(i haven't put any of the bass dlls in system directories - just project-specific ones)

[Ian @ un4seen]

That does look like an old BASSCD.DLL version is being loaded from somewhere. Do you definitely have the latest version alongside your app? You can check the file's properties in File Explorer to confirm.

I'm not a VB6 user myself, but I believe you need to set the current directory to the app's path rather than that being automatic? The BASS examples all include this in their Form_Load functions:

Code: [Select]

    ChDrive App.Path
    ChDir App.Path

If you are already doing that but not calling any BASSCD functions until later, then you could try adding a BASSCD function call (any will do) there to force VB6 to load BASSCD at that point (in case the app later changes the current directory).

[murspieg]

Solved, sort of.  But with a question.

For testing purposes, I had the prior basscd in the same directory, but named basscd-2.3.dll.  I naturally thought it would not be read.

But the author of the project had this code in a class initialization function.  I do not understand what it's doing, but when it read the basscd-2.3.dll, the later function calls threw up the "Incorrect BASS.DLL version" error.

Code: [Select]

lngFile = FindFirstFile("bass*.dll", udtFileAttributes)
    If Not lngFile = -1 Then
        Do
            If CBool(udtFileAttributes.dwFileAttributes And vbDirectory) = False Then
                lngPlugin = BASS_PluginLoad(Mid$(udtFileAttributes.cFileName, 1, lstrlen(udtFileAttributes.cFileName)), 0)
                If lngPlugin Then
                    udtPluginInformation = BASS_PluginGetInfo(lngPlugin)
                End If
            End If
            lngAdditionalFilesAvailable = FindNextFile(lngFile, udtFileAttributes)
            DoEvents
        Loop Until lngAdditionalFilesAvailable = 0
        FindClose lngFile
    End If
Even when I renamed the file basscd-2.3.dll-HOLD, the FindFirstFile function read it and I got the wrong version error.  How can I modify the find file string to only look at files with a dll extension?  And I don't know what issue this code is trying to prevent.   [I inherited this project, but am nowhere near as conversant in VB as he was.]

[murspieg]

On second thought [at 2 am :--)], I realized we should consider a different approach.

When we distribute a project update along with version 2.4 dlls, we might have users that accidentally don't overwrite the older dlls.  If that happens, this routine would pick them up, complain they need bass 2.3, and our program will exit/crash. 

Instead, if we rename the new dlls (bass24, basscd24, basswma24, bass_fx24), then the FindFile pattern can be bass*24.dll, and the routine will do its BassPlugin stuff without interference from the older dlls.

Do you see any reason why that won't work?  Will these BassPlugin calls do everything necessary to make sure the libraries are installed in the project.  Or is there a better way to accomplish that goal?

[Ian @ un4seen]

The add-ons (eg. BASSCD.DLL) specifically link with BASS.DLL, so that file cannot be renamed. I would recommend simply replacing all of the old DLLs.

[murspieg]

Thanks for letting me know; that's very important.
Some of our users will surely overlook this, so the project will need to check the version number before the program crashes. 

Q1: What's a simple way that VB can check the bass.dll version number?
Q2: Can at least the addons be renamed?

[jpf]

Q1:

If you're not positively sure that there isn't any wrong dll version in the search path you'd better not let VB6 load it automatically. VB6 does that at your back when you first call a function in that dll, for instance calling BASS_GetVersion. Once a dll is automatically loaded you can't get rid of it; it remains loaded and being called until the end of the app.

Instead check the version without loading it using the GetFileVersionInfo API function. Then when you find the correct version load it explicitelly using the LoadLibrary API function. VB6 won't try to load it automatically then. Once you did this you can safelly call any function in it.

Do that also for all of the plugins if there's any risk of having wrong versions in the search path.

This is true for whatever dll, not just for bass dlls.

I had this issue more than once. It's more common than you may think.

I don't know about the plugins calling bass.dll functions at your back. I guess you can't control it from inside VB6.

[murspieg]

Tnx for reply.  I'm sorry: I wasn't able to find any doc or examples using GetFileVersionInfo.

Here's how I'd like to use it:  I will check that bass.dll exists [Dir(filepath)] in the user's current directory.  Then use the GetVersion call to check that it's 2.4; if not, issue a warning msg to the user and exit.

Can you explain (code snippet, variable definitions, return codes) how to call GetFileVersionInfo within VB?

Much appreciation for your help.

[jpf]

If you plan to just exit your app if the wrong version was loaded I see no harm in letting VB6 automatically load a wrong version. After the warning and exit the user would just delete the wrong version from the app folder, get the right one from Un4seen, copy it onto the app folder, restart your app and get it working. That's the way it's done in VB6 bass examples.

Now, if you want 2 or more bass.dll versions to coexist in the app folder, and be able to decide which one you want to load, then you must know which is the right one before loading it.

I don't know if bass.dll files can be named differently (so to be able to coexist in the app folder) and still be called by the addons. I wouldn't trust that it's possible.

A different approach would be to place the correct bass.dll and all of the correct addons in a custom folder you create (maybe inside the app folder) and not in the search path. For instance you may name it "bass24" or whatever. Then before calling BASS_GetVersion to automatically load bass.dll and all the plugins, you change the current folder to that folder like this:

Code: [Select]

ChDrive App.Path
ChDir App.Path & "\bass24"So bass.dll and all the addons will be loaded from that folder. That reduces the chance of the wrong dll being loaded. Be sure to do that at the very begining of your app. Otherwise there's a chance that you overlooked previous calls to the dlls. That's likely to happen if it's a huge project and you're not the original coder.

I did something like this for a VB.NET project that would run at 64 bits on a 64 bit Windows and at 32 bit on a 32 bit Windows. I just checked the bitness of the OS and switched to the folder containing the correct bitness files before explicity loading them.

I can't find here at home the code I used for GetFileVersionInfo. I guess it was a project for the radio station I worked for for 43 years. Now I'm retired.

Anyway, I found 2 code snipets here:
https://stackoverflow.com/questions/49063839/how-to-get-file-properties-in-vb6
There should be others floating around.

I think that code is enough self-explaining but if you have doubts get back to me. If you're a C programmer you could read about the functions used in Msdn. It's all very clear there.

Those examples are maybe a bit cumbersome for you. There's a posible way of doing the same thing using the FileSystemObject, but that would create a dependency. If you don't mind that, here's the thread:
https://www.vbforums.com/showthread.php?505137-RESOLVED-Get-EXE-Version
Look for post #2 in the thread.

[Ian @ un4seen]

Q1: What's a simple way that VB can check the bass.dll version number?

BASS_GetVersion gives you the loaded BASS version number.

Q2: Can at least the addons be renamed?

They can be (except for BASSenc if also using BASSenc_MP3/etc), but I wouldn't really recommend that either. Surely it's better to just replace the old add-ons rather than leave them hanging around with no purpose.

By the way, the "Incorrect BASS.DLL version" message won't necessarily result in a crash. If it's in a BASS_PluginLoad call then it just means that call will fail (return 0), and the app can continue running.

[murspieg]

*I* can certainly deal with the different versions of the dlls.  OTOH, our users are not that sophisticated; they're very tech unsavvy :-(    That's why I need to guard against someone not copying the right files.  I will try the suggestions offered.

[As for why hang onto the old dlls:] We may have an unfortunate situation where users might need to [temporarily] run an old version of our sw for a bug work-around - in that case, we really do need to check which bass.dll they have.  Until we nail down this pesky bug, they need the old dlls. 

My plan is to rename the addons (eg basswma24, etc), so at least the addons won't conflict.  The old sw will load in the 2.3 dlls, the new sw will loads new ones.  If the bass.dll in the app directory is the wrong one, we'll exit with instructions.

Thank you all for the help and suggestions.

[murspieg]

           [Perhaps this thread should be renamed upgrading BASS 2.4 -) ]

1) Specific to upgrading:
The 2.4 upgrading documentation  for StreamCreateFile only mentions two params are now QWORDS.   But our call got a Runtime error: type mismatch.  (Of course within your code, the call is reconfigured to a call to BASS_StreamCreateFile64)

As mem is FALSE in our version 2.3 code, the old call had a filename string for 2nd parameter and that worked.  For 2.4, seeing the definition parameter (* file) and the example VB code for bass_fx, we discovered the parameter must be StrPtr(file).

Unless we missed the info somewhere else, the doc for upgrading is incomplete.

2) As mentioned above, our unsophisticated users may need the old dlls for other conditions, so we wanted the new plugins named as bass*24.dll (eg basscd24.dll, etc)

However, even tho we had loaded them in, the call to BASS_CD_StreamCreate causes the error File basscd.dll not found.

We thought the PlugInLoad calls below would bring them in.  Are the names of the plugins indeed hardcoded; must they in fact be called basscd.dll, etc?

Code: [Select]

' read in plugins:
  lngFile = FindFirstFile("bass*24.dll", udtFileAttributes)
  ...
  lngPlugin = BASS_PluginLoad(Mid$(udtFileAttributes.cFileName, 1,
      lstrlen(udtFileAttributes.cFileName)), 0)
  udtPluginInformation = BASS_PluginGetInfo(lngPlugin)


[murspieg]

Modifying prior comment based on add'l testing:
Of the plugin dll's we're using, it looks like basswma and bass_aac can be renamed, but basscd can't be.  Not sure why there's that difference, just FYI.

[Ian @ un4seen]

Simply renaming the DLLs will be fine when using BASS_PluginLoad, but if you call functions from a DLL directly (not via the plugin system) then you will also need to modify the function declarations (eg. in BASSCD.BAS) to reference the new filename so that VB6 knows where to find them.

I still say it'd be best to just replace the old DLLs

[murspieg]

Understood, thanks.

As we slog thru our upgrade from 2.3 and 2.4, note there may be an undocumented difference btw 2.3 and 2.4 wrt Bass_StreamCreateFile (requiring StrPtr).  Perh add that to the upgrading notes.