by Michael S. Kaplan, published on 2007/01/15 03:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/01/15/1466291.aspx
Maybe you just have a dirty mind....
On the other hand perhaps I just need to get out more.
I am thinking about the maximum length for strings in resources, myself. Especially after Nizam asked:
Do we have a limit on the length of a resource string?
Well, if you head back to Windows 3.0/3.1 the limit is 256 characters (apparently brevity really did used to bet he soul of wit), but the current limit under is documented as 4097 characters for both Win32 and CE/Mobile.
Though Jesper had the comment of the day embedded in his response to the question:
Localizers themselves have a tolerance of roughly 1k. Long strings aren’t fun.
For some reason this one had me laughing. I suspect the reason for this is the way that string resources are usually made available to localizers in tools is not really designed with really long strings in mind (after all, help content that is to be localized does not suffer from the same kind of limitation.
Now given the fact that a target language can often take up more space than a source language, I think it is pretty important for developers to not try to push this limit and use up all of the space (even ignoring Jesper's concerns, there is no way to avoid annoying a localizer if you do not leave them enough room to properly express themselves!
This post brought to you by ᕯ (U+156f, a.k.a. CANADIAN SYLLABICS TTH)
# Philihp Busby on 15 Jan 2007 7:27 AM:
I can't stand limits. Is there any reason for this restriction?
For someone who grew up in a world where we could have functions longer than 8 characters, things like this could get as frustrating as Oracle's 30-character limit on table names.
# Michael S. Kaplan on 15 Jan 2007 8:09 AM:
Is there a scenario where you truly find yourself needing a bigger than 4k string in a string table?
I can understand not liking limits, but this one seems clearly beyond what one would ever reasonably need....
# Mihai on 15 Jan 2007 1:54 PM:
Another (artificial) limit is the length of the text in a dialog label. The resource compiler and the Visual Studio resource editor restrict this at 256 characters.
But this is not a real system limit anymore. Try loading a long string from the string table and setting it as the label text at runtime. All is fine, nothing gets lost!
It would be nice to get VS/RC updated to support what the OS supports. You can often see the effects of this limit in practice:
- English dialogs with a long text split between several labels close to each other, each label with a text fragment, looking like a big text at runtime
- Convoluted English text, so that the result fits in 256 characters (big pain for localization, when English has 253 characters :-)
- Convoluted localization in some labels, because it has to fit in 256 characters
- Truncated strings, because nobody noticed the rc warning that the string is too long
# Rob Kennedy on 15 Jan 2007 8:16 PM:
Any insight into why the limit is 4097? That seems like a strange value. I would have expected a power of two minus one, but what's with the power of two plus one?
# Michael S. Kaplan on 15 Jan 2007 11:02 PM:
If I had to guess, it would be that since the strings needed to be word aligned and the resource format has them as counted strings (length prepended) that this is the only way to make them 4k and avoid wasting a byte?
# Dean Harding on 15 Jan 2007 11:57 PM:
Actually, strings in resource files are not null-terminated (they're length-prefixed), so my guess is that it's 4096 + null-terminator.
# Michael S. Kaplan on 16 Jan 2007 12:05 AM:
They AREN'T null teriminated, so it would be LENGTH + string and they want the max to be aligned.
# Dean Harding on 16 Jan 2007 12:28 AM:
What I mean is that since they're not null-terminated in the file, and they ARE null-terminated when you get them back (in code), you have a maximum size of 4096 in the file, but 4097 in code...
But then, since the length-prefix essentially takes up the first character (WORD) in the string, it would be the same as if it was null-terminated (except length-prefixes make parsing the file simpler).
It doesn't really mention null-termination in that article, so it's kind of hard to say. Anyway, hopefully there isn't much code that is QUITE pushing that particular limit :-)
# Michael S. Kaplan on 16 Jan 2007 1:30 AM:
They aren't null terminated in the resource format -- they add that later....