by Michael S. Kaplan, published on 2006/06/08 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/06/08/621213.aspx
When I hear someone has a problem involving VB5/VB6 and strings that involves language issues, I can usually make a good guess at what is going wrong....
So the other day, when Christopher used the contact link to ask me a question, I had a notion of what might be happening:
I've got an interesting regional settings situation that I thought you might have some knowledge of (there is a question somewhere in here...). I've got an app that makes use of some fancy VB6 code to dynamically execute some assembly code stored in a string (for CPU info stuff). It had worked fine until XP SP2 and all the various DEP issues. I've now fixed them. Or so I thought.
It seems that the DEP problem is fixed on English setups, but if I switch to Thai or Hebrew (the two that I tested, could be others), I get a DEP warning! By switched, I mean change the setting in both Standards and Formats and the non-Unicode Language field.
I don't run any code that is locale/language/etc specific. It should run the same on all scenarios. So my question is: What in the world goes in there that would cause DEP warnings on Thai/Hebrew, but not in English? Does VirtualAlloc/Protect/Free have any code internally that depends on the regional settings? It seems very odd. Any chance the fantastic Kaplan knows what sort of actions are taking place? :) If there is something weird here, there might be more than a few developers that would want to know about it...
-Christopher J. Thibeault
I don't think I'm fantastic or anything, but like I said I think I know what is going on.... :-)
Now the XPSP2 DEP (Data Execution Prevention) functionality does not itself have language-specific hooks in it. As a feature, it just keeps you from executing code that is actually sitting in a data section of a binary (a "feature" that is unique to x86 and which is used in some of security exploits that have been seen in the past related to buffer overruns on the heap).
But any time you are using strings in VB <= 6.0 and you are not taking special care to avoid it you are going to see a lot of string conversion via the default system code page (which is directly affected by the default system locale, also known as the language for non-Unicode programs.
It boils down to the same problem behind the whole Double Secret Unicode thing I have talked about before. Basically, a VB string being passed to a Win32 API, which VB will automatically convert from and to Unicode using the default system code page, andall of that conversion is basically either (a) useless or (b) destructive to the data.
In this case, where a string is being used in a Curland-esque running of assembler, any operation that is potentially destructive of the string is potentially very dangerous, and can certainly do things that were not intended.
It was a good thing DEP was there to protect the computer, when you think about it!
Of course it is hard to answer more specifically what to do here to fix the problem than what the Double Secret Unicode post talks about, but keeping that principle in mind it is usually easy enough to see where Visual Basic might be doing a bit of that evil conversion on data that ought not to be converted....
This post brought to you by ଏ (U+0b0f, a.k.a. ORIYA LETTER E)
# dumb programmer on 8 Jun 2006 4:38 PM:
# Michael S. Kaplan on 8 Jun 2006 7:54 PM:
# Christopher J. Thibeault on 8 Jun 2006 10:49 PM:
# Michael S. Kaplan on 9 Jun 2006 1:52 AM:
# Christopher J. Thibeault on 9 Jun 2006 2:42 AM:
go to newer or older post, or back to index or month or day