Author Topic: x64 BASS_PluginLoad on valid x64 plugins returns BASS_ERROR_FILEFORM  (Read 134 times)

Timtam

  • Posts: 18
Hi,

i'm currently using C++ to develope a tool which should be released as x86 and x64 alike.

This tool loads all related plugins within a directory and collects multiple information from it, like the extensions it supports and stuff.
It works all fine under x86, no matter if I use std::string or std::wstring or, the C approach, char* or wchar_t * (properly encoded of course).
Now, using the x64 version of BASS (same version number, the files are from the same downloaded zip files), no plugin wants to load (plugins are all the official file format add-ons from the un4seen website and just from the same zip files as the x86 ones, just as BASS).
I tried using UTF-16 and ANSI paths here as well, the C++ and C way, but both don't work. Asuming that it doesn't error that the file couldn't be found, but instead that a plugin format error occurred (error code is 41, hence BASS_ERROR_FILEFORM), I guess there must be something wrong with either the x64 version of BASS, or the zip archives (especially the x64 plugin builds).

Can you check if you can reproduce the error on your end or give me some hints if I can further debug this issue?

Best Regards.

Timtam

Ian @ un4seen

  • Administrator
  • Posts: 20845
Are you sure you are loading the x64 DLLs in the BASS_PluginLoad calls? Trying to load x86 DLLs instead can result in a BASS_ERROR_FILEFORM error.

Here's an x64 build of the PLUGINS example that you can try:

   www.un4seen.com/stuff/plugins-x64.exe

Timtam

  • Posts: 18
Hi,

thanks for that example. It works flawlessly when put into my plugins folder and simply loads all x64 dlls, ignoring the x86 dlls within the same folder. It uses the exact same dlls I use right now, and I still got problems I cannot identify. Here's the plugin function I use to load all plugins within the plugins folder, it works under x86, but not under x64. Debugging the fullpath content, either using MessageBoxW with fullpath.wstring().c_str() or MessageBoxA() with fullpath.string().c_str() shows just the correct path... do you have any other ideas?

Code: [Select]
void AudioLoadPlugins()
{
  BASS_PLUGININFO *hPluginInfo;
  HPLUGIN hPlugin;
  HANDLE hFind = INVALID_HANDLE_VALUE;
  unsigned int i;
  std::experimental::filesystem::v1::path currentdir{GetModuleDirectory()};
  std::experimental::filesystem::v1::path fullpath;
  std::experimental::filesystem::v1::path searchpattern{currentdir};
  WIN32_FIND_DATAW ffd;
  // append the wildcards
  searchpattern.append("plugins");
  #ifdef _WIN64
    searchpattern.append("bass*_x64.dll");
  #else
    searchpattern.append("bass*_x86.dll");
  #endif

  // searching all plugin files
  hFind = FindFirstFileW(searchpattern.c_str(), &ffd);
  if(hFind == INVALID_HANDLE_VALUE)
    return;

  do
  {
    if(ffd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)
      continue;
    else
    {
      fullpath = currentdir;
      fullpath.append("plugins");
      fullpath.append(ffd.cFileName);
      hPlugin = BASS_PluginLoad(fullpath.c_str(), BASS_UNICODE);
      if(!hPlugin)
        continue;
      hPluginInfo = (BASS_PLUGININFO*)BASS_PluginGetInfo(hPlugin);
      for(i=0;i<hPluginInfo->formatc;i++)
        __ParseExtensions(hPluginInfo->formats[i].exts);
    }
  }
  while(FindNextFileW(hFind, &ffd) != 0);
}

Ian @ un4seen

  • Administrator
  • Posts: 20845
Are you sure your app is 64-bit, eg. Task Manager confirms it by not saying "*32" next to it in the "Processes" list? If so, the next thing to check is how you are loading BASS.DLL. Perhaps you are renaming the 64-bit version? If so, that won't work because the add-ons import functions from BASS.DLL, ie. it needs to be called "BASS.DLL". You can avoid conflicts by putting the 32-bit and 64-bit executables (EXEs and DLLs) in separate folders. There will be no need to rename them then.

Timtam

  • Posts: 18
Hi,

thanks, that will be the problem then I guess. I'm currently delay-loading BASS due to issues with file names (I need to decide if I want to load x86 or x64 on runtime), because of external dependencies, the x86 and x64 version of my dll need to be in the exact same folder, so I need to decide between x86 and x64 BASS, which I thought renaming the x64 bass to bass_x64.dll would solve the problem. Thanks for that, guess I will put x64 and x86 bass into separate folders (including their plugins) and load them dynamically from there, keeping their filenames bass.dll anyway.

Thank you :).

Best Regards.
Timtam