I can't help, just guessing: try to change compatibility settings for SMath,
right-click the exe icon, click Properties, and then click the Compatibility tab.

The message indicates that the 64-bit managed application is trying to load some 32-bit dll. As SMath is AnyCPU program, it works as 64-bit on 64-bit OS, and 32-bit on 32-bit OS. If some extension, or other required dll happens to be built as x32, then it will work just fine on 32-bit OS, and give this message on x64.

I could just advise to use somemthing like procmon to check which dll is being loaded when this error happens.

Ioan, did you try this exe provided by Uni ?
http://en.smath.info/for...FI-plugin.aspx#post10324

I hope not, this relase doesn't work for me, dies immediately...

As Uni had already explained, this problem is directly caused by his mcadefi plugin. No need to look for another cause. And the problem is clear and straight: the plugin is a wrapper around an ancient 32-bit dll. The plugin is loaded by Smath, and the dll is loaded by plugin. So, effectively, the SMath process (that is 64-bit on x64 OS) tries to load 32-bit dll. This is not permitted under .Net. No way. There are workarounds: one is simple and is implemented as "1-bit replacement cure". This means that SMath is explicitly marked as 32-bit, and runs in 32-bit .Net environment, thus being able to load 32-bit ancient dll. Another workaround, that is very difficult, prone to bugs and inefficient, but more universal, is to write another program that would be 32-bit, ant it would load the problematic dll, and the SMath plugin would then communicate to that external process using inter-process communication (something like sending requests and getting replies over network).





There are a number of advantages here. First, current extensive use of SMath as 64-bit program ensures that there will be no problems when 32-bit support will finally come to end.
Second, the program may use the 64-bit CPU advantages (memory, arithmetics, etc...), which may be useful in math tasks. And even if the program itself still isn't coded to use this advantage, its 64-bitness (or, more precisely, it is AnyCPU process) enables the plugin writers to write extensions that can use this said advantage.

Simply refusing to have these goodies just to enable using some exotic old and rarely used stuff that could be replaced by another contemporary free analogue, would be simply silly.

So here is the issue