Originally posted by Anders
*The unicode system plugin needs to default to the W version of functions when autodetecting (foo >> fooW and not fooA)
We actually do default to the "W" version. Let me explain a little with how the "T" versions of the functions work for those who don't know.
We write in our code:
When you look at the definition of CreateFile, you see that there really is no function called "CreateFile" but two functions called "CreateFileW" and "CreateFileA." This is true for MOST of the functions that have both the A and the W versions.
#define CreateFile CreateFileW
#define CreateFile CreateFileA
#endif // !UNICODE
There are functions which only have one name, with no W or A prefixes.
So the logic that is in the system plugin currently is to try to load the function with the name as is, then failing that, try to add "W" for the Unicode build (or "A" for the ANSI build) and try again.
Unfortunately, for older string functions like lstrlen, the lib you are trying to load DOES have a lstrlen which is ANSI only. It's probably there for backward compatibility since it mimics standard library string functions. So for lstrlen, you need to specify kernel::lstrlenW. But as far as I've seen, it's only these string functions that look and behave like the standard library ones that have this problem.
A possible change could be that we always suffix with a "W" or "A" and see if that loads something and try that function first before we try the name of the function unmodified, but I'm uncomfortable with that since I'd rather give the programmer the benefit of the doubt and let him/her decide what s/he really wants to load.
I don't mind the plugin second guessing after failures but I don't want it to think it's smarter than the programmer.
To reduce the NSIS_MAX_STRLEN confusion, we should probably make it really clear in the docs that NSIS_MAX_STRLEN is a count of TCHAR's (Or maybe even rename it). We should also add a predefine for the count of bytes, I suggest we name it NSIS_MAX_STRCB
Both versions currently fail this little test script [/B]
I agree that we should note that NSIS_MAX_STRLEN is in TCHARS. But going through the documentation, they all state that NSIS_MAX_STRLEN means a number of characters
, not bytes. So I'm actually okay with the documentation as-is.
As for adding NSIS_MAX_STRCB, I think that's a great idea, although, it can easily be calculated by NSIS_MAX_STRLEN * NSIS_CHAR_SIZE. I like NSIS_MAX_STR_BYTES better as a name, though.
Unless the NSIS trunk has NSIS_MAX_STR_BYTES, it would be useless for me to add it just to the Unicode version as it's meant for portability across the two versions.
So perhaps we can request NSIS_MAX_STR_BYTES to be added to the NSIS trunk?