Difference between 32/64 bit Unicode-only content plugins

[Lefteous]

While converting a plugin to Unicode-only I noticed that it's okay to remove ContentGetValue from the list of exported functions when compiling to 64 bit. For the 32 bit version this will result in very strange errors over and over - especially in the following scenario discovered while testing.

1. Install plugin in the 64 version of TC.
2. Start the 32 bit version of TC using shared ini file (so plugin is already correctly installed).
3. Do something with the plugin -> crash

Not really a big deal but maybe you can remove this inconsistent behavior by eleminating the need for ContentGetValue in 32 bit or at least handle the resulting errors described above.

[ghisler(Author)]

Since all 64-bit operating systems are Unicode, there is no need for ANSI functions at all. Therefore the 64-bit plugin may be Unicode only (or ANSI only).

However, the 32-bit plugin MUST support the ANSI functions. Only exception: If you create separate ANSI and Unicode versions (with the Unicode version having extension .u*), the the Unicode version does not need the ANSI functions.

[Lefteous]

2ghisler(Author)
I know the way it works currently. I agree it's really better to support ContentGetValue if a Windows 9x user starts the plugin.
Anyway the current error handling is really 'improvable'.

[MVV]

I agree that it shouldn't crash, it should check if function may be exported from library before calling it.