October, 2005

Last week, over in the microsoft.public.platformsdk.mslayerforunicode newsgroup, Dan Mitchell asked:

We have a unicode app (working just fine with unicows) that needs to check the version of one of our DLLs. The DLL is non-unicode, and works fine if we load it and call our functions on it. (though none of those functions pass strings as parameters).

The problem is that if we call GetFileVersionInfoSize() on that DLL, we get an error back and GetLastError() returns 120 ("the function is not supported").

It works fine on WinXP etc, so it seems to be just something about unicode. (and it didn't do this before we switched our main app to unicode).

Is there anything we can do about this? If I try guessing that 64k should be enough as a safe fake return from GetFileVersionInfoSize(), the call to GetFileVersionInfo() fails the same way (getlasterror=120), and I don't think I can usefully spoof the call to that.

thanks,

-- dan

Of course, last week was pretty busy with the MVP Summit and all, so I did not see the message right away. Luckily, David Lowndes was checking the group in the evenings. He ran through some of the basic troubleshooting steps that I would have done, such as:

• Pointing out that it really ought to work (helps morale!)
• Asking if the call work with other DLLs, or even the EXE that it is being called from (it wasn't)
• Finding out if the 'A' version of the function works (it was)
• Asking what version of the DLL was being used (it was 1.1.3790, the latest one)

Now that is the point where I finally had a chance to check out the group. Now the above questions are pretty typical ones to ask and I probably would have done the same had I been around, luckily David saved me the trouble. :-)

So I realized based on the problem description and the answers what might be going on. It was one of two possibilities, with the second one being the most likely:

The error 120 (ERROR_CALL_NOT_IMPLEMENTED) is what the MSLU loader returns when it is unable to do the LoadLibrary/GetProcAddress on the function.

Of course the reason for that is that it is the same thing that a Win9x OS will return if you call its "W" stub.

The most likely cause is improper linking to unicows.dll -- the best way to check is to do a dumpbin on the imports of the file calling unicows, and see if GetFileVersionInfoSize is there -- if it is, then that means that the unicows.dll one is not being called....

See http://blogs.msdn.com/michkap/archive/2005/01/24/359555.aspx for more info on the MSLU Loader....

And a few days later (yesterday, in fact!) Dan answered back:

That's the problem alright. I have no idea what's wrong with it, though -- the last time I hit this problem it was openssl that was pulling advapi32.lib in, which was solvable by rebuilding openssl.

I have no idea what's pulling version.lib in this time; it doesn't seem to be any of our libraries, and I don't think it's openssl. I guess it's just a matter of poking around until I find where it's coming from.

It is an interesting problem when some other library is pulling in the .LIB files in a way that overrides your own attempts to order the .LIBs for MSLU's behavior. Sometimes the key is even to include a .LIB file more than once, though that is a solution that is really best avoided if possible since it makes things a lot more complicated. In many cases, careful reordering can do the trick. I'll cover one of the more awful examples of this issue another time....

Special thanks to David who allowed me to swoop in and look like a genius. :-)

This post brought to you by "Ю" (U+042e, a.k.a. CYRILLIC CAPITAL LETTER YU)

There Cathy and I were, early on Saturday morning, the last day of the 2005 MVP Summit.

All day yesterday, Mike and Mihai, our two 'internationalization' MVPs (technically Platform SDK MVPs, but both with a definite internationalization focus) spent the day with the GIFT team.

It was kind of funny to think about -- all of the other MVPs were moving around from place to place for the various presentations they had on their schedule. Our MVPs, on the other hand, got to stay in one place and all of the people from the GIFT team came to where the MVPs were all day. The GIFT team members thought it was great to meet with the MVPs and get opinions and feedback on short-term and long term-plans. And both of the MVPs though it was great to be given an awesome day with so many meetings. Everybody won!

It was a lot of fun to put together and it was great to be a part of it all.

So anyway, now it was Saturday, and a day that Cathy did all the planning for -- a presentation covering all of the great internationalization features in Vista.

Technically, she really had the harder job than I did for the day she had planned, since I did not have to do any slides while she had to do a 90 minute presentation, followed by a 90 minute panel.

We knew that the almost 90 Shell MVPs who were inivited had three choices for the day:

• Cathy's presentation
• A presentation given by some people in PSS
• Sleeping in after the Summit party that went until midnight the night before

Since no one had even registered for which option they planned to do, we had no idea what to expect, but we had a decent crowd, anyway. :-)

I volunteered to be on the panel, and also to be the slide boy and do a demo (Matt was also there, to do another demo). The presentation was awesome, and covered a lot of ground (I am sure the slides will get a lot of use over the net while!).

And we had a bunch of people from GIFT there for the panel, it was really cool.

We then got some really awesome questions, and some bugs and suggestions to follow up on (Perhaps I'll blog about a few of them at some point!).

Then for Saturday night the Access MVPs invited me to a dinner, which was also really nice -- like old times, seeing old friends.

All and all the Summit was a really nice event (much bigger than ones I have been to in the past!).

Though I think it would make sense to put a little more flexibility into the scheduling of some internationalization talks, opening it up to more of the MVPs if they are interested. I think there may be a fair amount of interest across many of the products covered by the various MVPs, so it would be cool to offer up something as an option to a larger group of them. Ah well, some ideas to pitch to the planners, perhaps there will be some interest....

This post brought to you by "₡" (U+20a1, a.k.a. COLON SIGN)

Jonathan Wilson asked via the suggestion box:

What features are in the ELKs and ELK building kit?

You have mentioned on this blog a few times how more languages are being added to windows via the ELKs and how an ELK kit is being worked on to enable people to build their own ELKs.
Can you post some more about what goes into an ELK, what the "ELK kit" will contain/will do and what makes releasing said "ELK kit" now so hard? (I am guessing that various parts of ELKs currently require changes to windows system libraries that only microsoft can make)

If you look at what goes into a new locale, you may find that you can build such a list yourself:

• All of the locale data
• A keyboard
• A font

Of course, fonts have been something that can be created for quite some time (though looking to Vista there are fewer times that you may actually need a font!). If you do then you can look to the Microsoft Typography web site, for both information and tools for creating fonts and links to foundries....

Keyboards have also been available for the masses for a few years now with the shipping of MSKLC. :-)

The locale data is the one piece that has always required the updating of system files, but as of Whidbey the feature of custom cultures is available, and as of Vista they can act as custom locales. So no system file update is needed to get a new locale that you create yourself on a machine or lots of machines. Now obviously this is an answer for developers who write code, so to be a complete answer there is going to have to be some effort to making it more generally accessible as a feature. I can't talk too much about those efforts yet, but the people who are interested may want to send some contact info to me via that Contacting Michael... link, and I will forward it on to the appropriate people.

In looking back at Jonathan's question, I honestly don't remember such a thing as an "ELK kit" specifically. But if you imagine some effort to try to bundle the information about these many different technologies, it may qualify. I am not sure whether that would in fact make sense or not, but it is the sort of thing that a lot of people are thinking about right now.

This is definitely an issue you will be hearing more about, in any case....

That is right, the Unicode train is leaving the station. You might want to make sure to get on board!

I have mentioned before that NLS is not writing new 'A' APIs. We are also recommending the same to other teams; if you are writing new functionality, it is time to remove the additional complication of converting string parameters.

Another factor that I discovered while meeting with MVPs on Friday -- new C++ projects written in Visual Studio 2005 are Unicode by default. So a lot of people will be calling the Unicode functions anyway.

Also in VS 2005, the Resource Editor can understand Unicode .rc files!

Now unfortunately Unicode .RC files are not the default currently; I would love to see this change in a service pack for VS2005 -- maybe someone should suggest it over at the MSDN Feedback Center so people can vote on it? :-)

I'll be posting more on other plans to help with this long-term migration, as they become available. But both inside and outside of Microsoft, the time has come for Unicode....

That is right, if you want to get results from windowssdk.msdn.microsoft.com for new Vista NLS API functions like GetDurationFormat, Google is not really able to help very much at the moment, though start.com and search.msn.com are. Yet another reason to keep an open mind about search engines -- you never know who is going to have what indexed. :-)

The funny part -- Google does have my blog indexed and after that crawl has gotten the skinny on new functions I have blogged about like FindNLSString. I am curious how long it will take them to pick up the rest of the new functions that no one has given them the links to yet? :-)

Yesterday I was with our international MVPs all day as they were meeting with various people all across GIFT and GPTS. It was exciting for me because I had the chance to learn about a lot of things that I do not usually get exposure to, if you know what I mean....

One of the interesting points that came up is the difference between these two technologies (linking vs. fallback), both of which are intended to help with the same problem -- you select a font and then try to use that font to view characters that do not exist within it. But how they work in Windows is very different.

I will limit things in scope at the moment, but soon I will expand it to talk about differences in MLang, Office, and maybe even Avalon....

Font fallback is what Uniscribe uses. With its own internal knowledge of the best fonts to use for the various scripts that it supports, any time it is asked to render a character that is not in the selected font, it borrows the glyph from its preferred font for the script. Note that you can override this choice at any time by simply making sur your initial font contains the characters you want and all of the shaping rules/tables than an OpenType font brings to the mix. If fallback does not do the trick, Uniscribe will fall back to linking.

Font linking, on the other hand, is what GDI uses. It is the value list of fonts under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink that gives the list of fonts to look in if the character cannot be found, and the order to look at them. Again, you can override the mechanism by making sure the initial font you choose has the glyphs.

In this particular case, FALLBACK gets used pretty much exclusively in the case where you have a complex script, something that needs Uniscribe to do its work. And if you look at LINKING, for the most part it is exclusively used to help the East Asian story by allowing the default system locale to choose an ordering for where to look for the appropriate ideograph glyphs in fonts (though the mechanism can be expanded, and sometimes is by ISVs, to cover other languages and scripts).

Now of course the way that the terms are used by other technologies is actually different in some cases, as are their mechanisms -- I will cover this soon (for now I have to get to a presentation for the Shell MVPs, where I am acting as both the 'Slide Boy' and one of the two 'Demo Boys'. :-)

A lot of people do not like South Park very much.

Of course, as it works to shock us, such a reaction can only be expected. Since often the easiest way to shock someone is with some type of vulgarity. And there is no shortage of vulgarity on South Park.

But there is also a very bold tradition, very commonly seen in the Heinlein juveniles and even before that, where the heroes are the children, and the adults can do little more than try to keep up.

I was thinking the other day about the episode that led off the fifth season, entitled It Hits The Fan. In this episode (apparently taking poshots on the NYPD Blue episode with non-censored swear words that had people clamoring for at least a month), the network decides to make a bold move and say the word 'shit' without bleeping it. Suddenly everyone is cursing. And a strange disease also seems to be killing people, too. The boys, who have already realized what the adults and network executives have not (that saying the word was much more exciting when it was taboo to say), run into the ancient Knights of Standards and Practices who are guardians trying to keep people from overusing curse words, lest destruction come.

The folks in the South Park Studios even ran a contest in guessing the number of times the word would be used in the episode -- the final number was 162 (only two off of my own guess of 164).

Anyway, there were several interesting and sometimes (dare I say it?) linguistic points buried in the episode:

• Eric Cartman's insistence that Meekrob was a curse word, since in his opinion it tasted like shit.
• His point being proven later when the word actually was on the list that the knights were working from.
• The fact that it was the young boys who figured it all out and saved the day, realizing that curse words (or words of curse) are actually most interesting because they are used sparingly.
• The idea that censorship should be based on the pragmatic context of who is saying the word -- thus Mr. Garrison as a self-identified homosexual was allowed to say "fag" without being bleeped, while others who were not would be censored.
• Clearly the importance of both content and intent of words should not be underestimated.

But at the same time, the lessons were perhaps a little in conflict with each other (probably a side effect of them not being an explicily intended message!). On the one hand, whether to censor speech specifically depends on whether (by some external criteria) you are qualified (for lack of a better term) to say certain terms. And on the other hand, it is a network executive who repeats the swear word continuously without any specific intent other than to prove he could that leads to the earth opening and a fire breathing dragon to come out. Perhaps the message of the censoring is that a word may not actually be a curse word if it is used appropriately, by an appropriate person...

I wonder how such principles would apply to movies like The Last Boy Scout, in which the use of swear words per capita may even rival this South Park episode. Or even to the first South Park movie, where Matt and Trey are able to insert one of their own little petty hatreds by getting Barbara Streisand's name to be classed as a curse word that is affected by the V-chip. The irony of how curse words (well, Cartman's 'filthy  f***ing mouth') saved the day in the movie while it is the sparing use of and control over such things that saved the day later is also kind of fun.... why be consistent? :-)

Anyway, I guess the message is that words can be so important that you do not need to fully understand them for them to have an impact. In the words of Talk Radio's Barry Champlain, "Sticks and stones may break our bones, but words cause permanent damage."

Indeed they might. So we should all look out for those words of curse. And perhaps reconsider whether or not to order the หมี่กรอบ (Meekrob), which in the eyes of Matt and Trey may have been the most important lesson of the episode....

This port brought to you by "ห" (U+0e2b, THAI CHARACTER HO HIP)