OpenSSL v3: fish_inject.dll won't load in today's beta version

[maroonbells]

In the same way that older FiSH versions stopped working in v7.56 due to mIRC migrating from OpenSSL 1.0. to 1.1.1, FiSH can't work in today's beta version, due to the changelog item:

11.Updated OpenSSL library to v3.0.8.

... and the DLL now thinks that I don't have [ssl] item load=1 even though I do.

Hopefully it won't be the same kind of 'fun' as was had in getting FiSH working with v7.56

This is a beta version that few people are testing, and we never know when Khaled will choose to publish a 'stable' version, which is when everyone will notice that FiSH isn't working anymore.

• *

If it's determined that the only way to get FiSH working again is to disable past mIRC versions, perhaps there could be 1 final compile for them, including any pending commits that might be important.

If the new minimum-mIRC-version will be the future v7.73, an FYI about the line length limit change that's in one of the pending commits. I see the source includes

src\mircdll.h

define MIRC_PARAM_DATA_LENGTH 8192

src\mircsendmessageapi.h

const DWORD MAPPING_SIZE = 8192;

These are changes in v7.53 which increased the max length of an mIRC line from 4150 to 8192. Starting v7.62 this was increased again to 10240, so a DLL that works only in versions later than this could increase the number safely.

Even when the line length was 4150, DLL's behaved as if the MAPPING_SIZE was 8192, because requesting a map of 4150 bytes is rounded up to 40962, so if the mapping variable were changed to 10240 it would behave as if it were set to 40963, though the problem would be getting strings to/from the DLL within the mIRC line length limit that sometimes applies to bytes and other times applies to characters.

The character limit for a scripting line is actually 10240+100 to allow for scripting /command names to fit, but it may not be a good idea to be 'greedy'.

Starting in v7.64 the DLL's LOADINFO struct contains the max byte limit for strings sent from the DLL to mIRC using "return 3;", which has been 210240=20480 since then. mIRC still chops strings sent to the DLL at 10240+100 bytes even if that is a string of 'only' 3500 characters* who are all above codepoint 2047 which UTF8 encode as 3 bytes each. And, while you can put 20480 bytes into the return buffer, that is also limited by the 10240+100 characters limit of a scripting line, so will generate a scripting error if the return3'ed 20480 bytes contains too many UTF8 characters. Though I don't know if the Fish 'hooks' would evade that limit.

Generally, the really long strings wouldn't be used for channel messages, but might be used by someone making direct calls of the dll functions to encrypt or decrypt %strings. The longer line lengths were to accomodate IRCv3 tags which could be as long a 8181 by themselves, assuming any of the networks start accepting custom client tags.

[maroonbells]

Just bumping a comment for FiSH users, that today mIRC releases v7.73 which uses OpenSSL v3, and FiSH will not work as expected. While it can send encrypted messages, v7.73 cannot auto-detect and auto-decrypt the incoming encrypted messages created by others.

[XinfitX]

Hope to have an update soon FiSH, there is no reason not to use the latest version mirc 7.73

[flakes]

Started working on the upgrade, almost done. Need to figure out a few more things and we should have a new release soon...

https://github.com/flakes/mirc_fish_10/compare/45ab62376e8be687efd8cdc294edabdcc79965a2...master?w=1

[flakes]

Get it while it's 🔥 from https://syndicode.org/fish_10/