[Gamester17]

Please consider adding an operating-system 'ID tag' (for Xbox, Linux, Windows) inside each .vis and .xscr file and enable XBMC's DLL-Loader to check those tags and thus know which DLLs are for the current platform it is running on so it can filter out (not display under the GUI settings) any visualisations and screensaver that are not supported under that platform.

It might also be a good idea to add additional 'tags' to indicate if it is "32-bit" or "64-bit", and also to indicate hardware platform like "x86" or "PPC", (both those tags to make the vis tags more future proof, in case XBMC ever gets ported to the PS3, Xbox360, or PPC for Mac OS X someday).

Code:

<vis_tags>
  <os>windows</os>
  <version>all</version>
  <cpu>x86</cpu>
  <bits>32</bits>
</vis_tags>

Code:

<vis_tags>
  <os>linux</os>
  <version>all</version>
  <cpu>x86</cpu>
  <bits>32</bits>
</vis_tags>

Code:

<vis_tags>
  <os>linux</os>
  <version>all</version>
  <cpu>x86</cpu>
  <bits>32</bits>
</vis_tags>

Code:

<vis_tags>
  <os>linux</os>
  <version>10.5</version>
  <cpu>x86</cpu>
  <bits>32</bits>
</vis_tags>

Good idea or not?

[jmarshall]

Not. .vis files are dll's (or shared libraries) so XBMC won't be able to load them anyway.

Instead, we simply divide them up per platform and have the build scripts take care of just installing the appropriate ones.

[Gamester17]

How about a simple subfolder structure then?

\xbmc\visualisations\linux_x86_32bit\*.vis
\xbmc\visualisations\linux_x86_64bit\*.vis
\xbmc\visualisations\osx_x86_32bit\*.vis
\xbmc\visualisations\osx_x86_64bit\*.vis
\xbmc\visualisations\win_x86_32bit\*.vis
\xbmc\visualisations\win_x86_64bit\*.vis
\xbmc\visualisations\xbox_x86_32bit\*.vis
and
\xbmc\screensavers\linux_x86_32bit\*.vis
\xbmc\screensavers\linux_x86_64bit\*.vis
\xbmc\screensavers\osx_x86_32bit\*.vis
\xbmc\screensavers\osx_x86_64bit\*.vis
\xbmc\screensavers\win_x86_32bit\*.vis
\xbmc\screensavers\win_x86_64bit\*.vis
\xbmc\screensavers\xbox_x86_32bit\*.vis
etc.

[jmarshall]

Something like that, yeah. Though probably not quite as verbose as that.

Cheers,
Jonathan

[Gamester17]

.vis files are dll's (or shared libraries) so XBMC won't be able to load them anyway

What if you were to implement a 'tag' reader into XBMC's DLL-loader, then it could read those tags from the DLL files similar to how an MP3-player can read the ID3 tags from an MP3 files without opeining the whole file. These 'tags' could maybe also be used for the DVDPlayer and PAPlayer, and their DLL files (such as codecs, etc.).

If you under a Microsoft Windows operating-system look under properties at a Micorsoft DLL file you with see that the version tab contains at least:
File version:
Description:
Copyright:
Company:
Language:
Product name:
Product version:

FYI; a patch has been posted to the FFmpeg-devel mailing-list which adds versioning information to DLLs:
http://lists.mplayerhq.hu/pipermail/ffmp...47340.html
http://lists.mplayerhq.hu/pipermail/ffmp...html#47340

This patch adds support for generating .rc files and then linking them with the dlls created by ffmpeg. This information can be used to identify the product version by the user and is also available to installer programs for ease of updating etc.

Before it was submit as a patch in the above mailing-thread adding .rc files for win32 was discussed in this other mailing-thread:
http://lists.mplayerhq.hu/pipermail/ffmp...47268.html
http://lists.mplayerhq.hu/pipermail/ffmp...html#47268