[WLX] MMedia 2.62 x32/x64 Unicode/ANSI (Sep 2014)

[LonerD]

Do you have an entry:
x64DisableRedirection=1
in your wincmd.ini?

Yes, of course, I have this entry. Because if x64DisableRedirection=0 - then TCx32 work buggy in Windows x64

[Dalai]

Yes, of course, I have this entry. Because if x64DisableRedirection=0 - then TCx32 work buggy in Windows x64

Would you mind to explain that a little further? AFAIK it's the other way around because the loading of DLLs and stuff could fail since 32 bit programs can't load 64 bit DLLs (and vice versa).

Regards
Dalai

[HolgerK]

Yes, of course, I have this entry. Because if x64DisableRedirection=0 - then TCx32 work buggy in Windows x64

The only advantage of constantly using "x64DisableRedirection=0" is the navigation inside windows\system32 (The 64 Bit System32 which can also be reached under the path Windows\SysNative). On the other side this may result in many problems like .e.g Plugins or shell extension which are not able to load additional dlls.
As Dalai wrote: Its the other way around.

It's much better to create a button with cm_SwitchX64Redirection and activate it only if you need to search files under the SysNative folder.
Or simply use the 64 Bit TC version.

Regards
Holger

[iana]

A question about MediaInfo.dll
a few other plugins that use MediaInfo.dll (some wdx plugins) and come in both 32 and 64 bit versions use/set mediainfo's name as MediaInfo_x64.dll for the x64 bit version, as I keep both 32 and 64 bit wlx in the same folder can mmedia x64 search/use MediaInfo_x64.dll as mediainfo's name.
I have this option set in mmedia.ini
MIPath=C:\totalcmd\wlx\mmedia\MediaInfo_x64.dll
but mmedia.uwlx64 still can not find MediaInfo_x64.dll,
yet mmedia.uwlx uses MediaInfo.dll and that one is not set in the ini file.
Is this a bug, could the 64bit version search for MediaInfo_x64.dll or at least use it as an alternative name?

[milo1012]

...I have this option set in mmedia.ini
MIPath=C:\totalcmd\wlx\mmedia\MediaInfo_x64.dll...

I'm not sure what he does in his code, but from my experience with MediaInfo he seems to be using the default DLL header provided with the package.
But this uses a hard-coded name, which is one of the reasons I don't like the DLL interface at all.
So I think MIPath sets only the path where to find the DLL, but not the absolute path including the DLL name!

So you probably have no choice but to keep the 32- and 64-bit versions separate for now.

[fg_2002fr]

I have this option set in mmedia.ini
MIPath=C:\totalcmd\wlx\mmedia\MediaInfo_x64.dll

this should work. to test, I changed the name of the mediainfo DLL and copy the same at the MIPath in mmedia.ini. Restart TC. it load the new named DLL.
But if the given dll is not found some automatic actions are done :
searching
- mediainfo_i386.dll in the same path
- mediainfo.dll in the current and system path
- mediainfo.dll in the plugin dir
- path of mediainfo.exe in the registry

in your case, if mediainfo.dll is loaded instead the given MIpath, check if the path or the name of the library are correct

[iana]

I'm talking about the 64bit uwlx64 plugin
I set the mi path as
MIPath=C:\totalcmd\wlx\mmedia\MediaInfo_x64.dll
in the version info box the plugin displays
Not detected
the 32 bit works fine, it ignores the MIPath and uses the 32bit dll
C:\totalcmd\wlx\mmedia\MediaInfo.dll
I don't have mediainfo.exe in the registry
can't I set a name different then mediainfo_i386.dll or mediainfo.dll in MIPath?

[iana]

I renamed the 32 bit dll to mediainfo_i386.dll and the 64bit to MediaInfo.dll, I set
MIPath=C:\totalcmd\wlx\mmedia\MediaInfo.dll
the 64bit plugin can't find MediaInfo.dll
and after renaming the dll's the 32 can't find MediaInfo_i386.dll it tries to load the 64 MediaInfo.dll and fails, a suggestion for future builds can we have 2 options
MIPath=C:\totalcmd\wlx\mmedia\MediaInfo.dll and
MIPath64=C:\totalcmd\wlx\mmedia\MediaInfo_x64.dll
?

ps I'm using the unicode /MD 32 and 64 builds of mmedia 2.6.2.0 as
C:\totalcmd\wlx\mmedia\mmedia.uwlx
C:\totalcmd\wlx\mmedia\mmedia.wlx64

and MediaInfo 0.7.76 in the same folder as
C:\totalcmd\wlx\mmedia\MediaInfo.dll 32bit dll
C:\totalcmd\wlx\mmedia\MediaInfo_x64.dll the x64

[iana]

I renamed the 32 bit dll to mediainfo_i386.dll and the 64bit to MediaInfo.dll, I set
MIPath=C:\totalcmd\wlx\mmedia\MediaInfo.dll
the 64bit plugin can't find MediaInfo.dll
and after renaming the dll's the 32 can't find MediaInfo_i386.dll it tries to load the 64 MediaInfo.dll and fails, a suggestion for future builds can we have 2 options
MIPath=C:\totalcmd\wlx\mmedia\MediaInfo.dll and
MIPath64=C:\totalcmd\wlx\mmedia\MediaInfo_x64.dll
?

ps I'm using the unicode /MD 32 and 64 builds of mmedia 2.6.2.0 as
C:\totalcmd\wlx\mmedia\mmedia.uwlx
C:\totalcmd\wlx\mmedia\mmedia.wlx64

and MediaInfo 0.7.76 in the same folder as
C:\totalcmd\wlx\mmedia\MediaInfo.dll 32bit dll
C:\totalcmd\wlx\mmedia\MediaInfo_x64.dll the x64

and an ini in the same folder
C:\totalcmd\wlx\mmedia\mmedia.ini (i found a mmedia.ini in tc root but I deleted that one)

[milo1012]

2fg_2002fr
Does that mean you set via MIPath just the search dir, or the absolute path including the DLL name?
I'd say the latter is not the case, since it doesn't work for me also.

In any case, using just one hard-coded name (mediainfo_i386.dll etc.)
prevents using a 32- and 64-bit version in the same plug-in dir,
which is the preferred way for many users IMO.
I agree with iana's suggestion: best use two separate entries.

[fg_2002fr]

2fg_2002fr
Does that mean you set via MIPath just the search dir, or the absolute path including the DLL name?

MIPath is the path (relative or absolute) including the DLL name.
I need to test this on a 64bits OS, but this works well on a 32b and the code is the same.
May be this is due to the MediaInfoDLL.h?

[iana]

MIPath is the path (relative or absolute) including the DLL name.
I need to test this on a 64bits OS, but this works well on a 32b and the code is the same.
May be this is due to the MediaInfoDLL.h?

just checked MediaInfoDLL.h from both the 32 and 64 bit redist's from
https://mediaarea.net/en/MediaInfo/Download/Windows
and they're the same
I tried using MediaInfo.dll as the 64bit name, the 64bit mmedia.wlx64 can not load the 64bit dll MediaInfo.dll, the 32bit works fine.

[milo1012]

May be this is due to the MediaInfoDLL.h?

Well, I don't know your code, or if you changed anything in the MediaInfo header,
but in the default header, when you construct a MediaInfo object, it tries to load the the DLL on itself,
via LoadLibrary() and the hard-coded name MEDIAINFODLL_NAME (= MediaInfo.dll), and tries to unload it in the destructor.

So whatever you added or changed to support absolute DLL paths and the name "mediainfo_i386.dll", it probably interferes with that.

That's one of the reason I try to avoid that interface and use the static lib.
Most changes in in MediaInfo are trivial, and you really don't need to update your plug-in DLL for every tiny new version.
Not to mention that there might be conflicts with different plug-ins that use a MediaInfo DLL on their own.
(I lost count, but we have at least three other plug-ins which use that DLL by now)

[iana]

That's one of the reason I try to avoid that interface and use the static lib.
Most changes in in MediaInfo are trivial, and you really don't need to update your plug-in DLL for every tiny new version.
Not to mention that there might be conflicts with different plug-ins that use a MediaInfo DLL on their own.
(I lost count, but we have at least three other plug-ins which use that DLL by now)

that would make this plugin 10+MiB in size (if you use both32 and 64 bit)
I think the author hasn't tested this on a 64 bit machine, actuelly I'd prefer the removal of mediainfo if it would keep this plugin under 1MiB (both 32 and 64 bit).
I hardlink the mediainfo dll to the plugins that use it and have no issues with it.

[fg_2002fr]

or if you changed anything in the MediaInfo header,
but in the default header, when you construct a MediaInfo object, it tries to load the the DLL on itself, via LoadLibrary()

I change only one thing in the header file, it's the additional support of "mediainfo_i386.dll".
The automatic loading of the dll via LoadLibrary() needs that Mediainfo was correctly installed but many people (as me) prefer just copy the dll.
When I first added the support of mediainfo in MMedia, the 64bits version of mediainfo installed 2 DLL : mediainfo.dll (x64) and mediainfo_386.dll (x32)

That's one of the reason I try to avoid that interface and use the static lib.

this will multiply by 10 the plugin size!!!