Postings are provided as is with no warranties, and confer no rights. Opinions expressed here are my own delusions; my employers at best shake their heads and sigh, at worst repudiate the content with extreme prejudice, whenever it manages to appear on their radar.
This blog is unsuitable for overly sensitive persons with low self-esteem and/or no sense of humour. Proceed at your own risk. Use as directed. Do not spray directly into eyes. Caution: filling may be hot. Do not give to children under 60 years of age. Not labeled for individual sale. Do not read 'natas teews ym' backwards. Objects in mirror are closer than they appear. Chew before swallowing. Do not bend, fold, spindle or mutilate. Do not take orally unless directed by a physician. Remove baby before folding stroller. Not for use on unexplained calf pain.
A nice FLAIR (FLuid Attenuated Inversion Recovery) view from the not-too-distant past. Every abnormality you can see on this scan (and there is more than one!) is asymptomatic at present. Alongside is a picture of me walking the walls at Fremont Studios, a sign of a damaged brain.
There are some fascinating aspects of language that cross into the practical needs of software products.
One of them is the field that that the terminologists occupy.
There is even an alias within Microsoft that I used to belong to for terminology issues.
I say "used to" because I realized what I was interested in was conversations about and behind word choices, and the alias had reached a very practical pinnacle which mainly amounted to someone asking What's the word for ________? and having people chime in, usually one per language, giving the word or phrase in their language.
Although this is obviously a practical requirement being fulfilled and although occasionally disagreements about the best term to use when more than one person had different opinions within the same language, on the whole this wasn't exactly what I was looking for.
But the area is still one I find interesting. :-)
Anyway, I was recently pointed to some (externally available) blogs from various language Microsoft terminologists that I thought I'd share:
From the English one, a question about Fatherland vs. Motherland came up that kind of had me wondering about the forces in culture that have me associating where I live with "father" and what I speak with "mother" -- thus the question in the subject of this blog....
Plus someone pointed out a minor Wikipedia error in the comments, which is always fun.
That made me wonder what the word is to describe a Wikipedia error? Wikipederror seems unlikely to catch on, but the dynamic nature of Wikipedia kind of implies of a constant state of motion that usually, hopefully moves into accuracy should have a word for that phenomenon before or between accuracy where something can be not quite right....
This blog brought to you by ߡ (U+07e1, aka NKO LETTER MA)
If you watched Saturday Night Live way back when, you might have remembered the Mike Myers skit involving Simon, the one who was always calling the viewer a "cheeky monkey".
I was thinking about this the other day when Paul asked over in the Microsoft VOLT user's community:
I added the Ol Chiki glyphs to a font (U+1C50..U+1C7F) as well as others newly assigned code points in the Unicode 5.1 standard.The glyphs are definitely present in the TTF file (I checked with TTX and Microsoft's Font Validator), but they don't show up in the Windows XP "charmap" application (Start / Run / charmap, then choose a font).Does something have to be added to a TTF file in Volt or some other tool to have Windows consider newly defined code points to be valid?
I looked around, and there are a few fonts out there like Code2000 that support Old Chiki.
Here are the characters, you can see if your browser supports them (assuming you have the font installed, I mean):
᱐᱑᱒᱓᱔᱕᱖᱗᱘᱙ᱚᱛᱜᱝᱞᱟᱠᱡᱢᱣᱤᱥᱦᱧᱨᱩᱪᱫᱬᱭᱮᱯᱰᱱᱲᱳᱴᱵᱶᱷᱸᱹᱺᱻᱼᱽ᱾᱿
But as Paul mentioned, the XP Character Map program does not show them:
In the advanced view, you try to Go to Unicode 1C50, and nothing is there (the lowest one closest to the requested character is U+1e00).
Now the good news is that the same font in Vista will show the characters in the script:
Note that the name is not there -- it lists the character as "Undefined" -- the string that getuname.dll (which has been mentioned previously) returns when it does not know about a character. The only fix for that would be some future version of Windows after Unicode 5.1.
I asked some people if they knew what might have changed, people did not seem to recall a targeted change that was aimed at this problem (and none of the bugs resolved really jumped out for me as the fixer), so it may have just been one of those "fixed by accident" kind of bugs.
So Paul, the good news is that there is nothing you need to do. Of course the bad news is that there is nothing you can do. :-(
There are some other interesting issues here, like one I found in RichEdit, that I'll talk about soon....
This blog brought to you by Ḁ (U+1e00, aka LATIN CAPITAL LETTER A WITH RING BELOW)
Y-u may recall when I first wrote the Backf-rmati-n -f deity bl-g, back in April.
Y-u kn-w, when I talked ab-ut the interesting way that replacing God with G-d, intended in part to h-ld deity seperate , actually saw the argument s-mewhat hurt by using g-ds in place of gods.
Well, there exists n-t an argument that regular reader reader John Cowan can't c-mplicate! :-)
In resp-nse to my Summer vacation, the 2nd bl-g, in particular the f-ll-wing bit:
I'll blather about this and that and maybe even do a Tech Talk, bog willing.
J-hn c-mmented:
"bog"? I think you mean "B-g".
Hmmmm.
N-w we may n-t really kn-w the true religi-n in which Manuel Garcia O'Kelly Davis Long believes, but we can be certain (in carefully reading The Moon is a Harsh Mistress and Time Enough For Love and To Sail Beyond the Sunset) that it is n-t Judaism. Given that, taking the deity he invokes, Bog and making it B-g seems like yet another interesting backf-rmati-n of deity.
F-r my own usage, I d-n't tend to think of the true deity atop all creati- n to be named Bog, and given that in my c-ll-quial use of his name I felt unc-mf-rtable with the en-bling capitalization, thus I used bog. :-)
This particular bl-g y-u are n-w reading is being d-ne respectfully f-r th-se w-rshipping the deity kn-wn as The Big O, a sect where every member spends their wh-le entire life searching f-r The Big O and thus finds the letter 'O' in text to be distracting and pe-ple using it being s-mewhat minimizing the difficulty of their search -- thus they replace the letter in words with a hyphen....
I c-uld explain the sect further -- its use of Shel Silverstein "Missing Piece" t-mes as prayerb--ks and h-w they n-te the general tendency pe-ple, even if n-n-believers, have -f inv-king deity in their own achievements in their search f-r The Big O -- but this bl-g is already disrespectful en-ugh as it is, thus I will end it n-w....
This blog brought to you by O (U+004f, aka LATIN CAPITAL LETTER O)
WARNING: if you are easily offended, LEAVE NOW. Get out. Get the hell out. Do not read this particular blog any further. If you are still here then the implicit assumption is that you are not offended, or are irretrievably stupid (since a smart person who is easily offended would have left!).
The subject of this post may not be the most strikingly unusual communication related to this Blog that I have ever received, but I will admit that it is definitely within the top five....
Self-described occasional reader and lurker Cliff was interested in understanding about the difference between a lexicon and a glossary in order to understand whether the word lexicon was being used correctly in a specific context.
His question? Well, he asked me if I
Given the final question, I was almost disappointed when I had to respond that I hadn't actually seen the movie (and was not entirely sure about the actresses mentioned), which knocked me out of all of the rest of the inquiry.
But I asked whether he could send me a sample list with some of the words in it (and whether they included definitions), assuming they were "safe for work" (this was an adult film, after all); perhaps I could answer the question even though I did not have the DVD?
He told me that every word was on its own (one per screen) with a definition running from 1-4 sentences, and he provided the full word list, saying that it was small enough include, and should be safe [enough] for work.
I will reprint the list he sent, here:
It stayed pretty clean until the end, and never got too bad even then....
Now if you look at the definitions for glossary and lexicon in Wikipedia, they might provide some context:
Glossary -- a list of terms in a particular domain of knowledge with the definitions for those terms. Traditionally, a glossary appears at the end of a book and includes terms within that book which are either newly introduced or at least uncommon.
Lexicon -- In linguistics, the lexicon (from Greek Λεξικόν) of a language is its vocabulary, including its words and expressions. More formally, it is a language's inventory of lexemes. The lexicon includes the lexemes used to actualize words. Lexemes are formed according to morpho-syntactic rules and express sememes. In this sense, a lexicon organizes the mental vocabulary in a speaker's mind: First, it organizes the vocabulary of a language according to certain principles (for instance, all verbs of motion may be linked in a lexical network) and second, it contains a generative device producing (new) simple and complex words according to certain lexical rules.
Now looking at the word list Cliff sent, there are clearly aspects of both in there -- items that are really disconnected terms whose definitions probably help one understand their use within the movie that would be most at home in a glossary, and items that appear to really be based on lexemes (e.g. those built with lexemes CHIP, SIM, GRID, and SKIN) that really do seem more lexicon-esque.
I admit that I am shocked at how a pornographic movie could truly have this much backstory.
I mean glossary or lexicon, either way this looks like a lot of information to have to take in!
In the end, I think that given that there are those many lexicon-like entries the term lexicon may well make sense, though it certainly seems to be structured like a glossary (perhaps if it had more cross references between those lexeme-built terms might cause me to change my opinion here?).
He then volunteered that the DVD included a PDF file with the screenplay, which was 75 pages long. I was starting to wonder if he was on commission or something? :-)
My final question for him (remembering the navel pouch from Robert A. Heinlein's Friday) was who in the movie had the DERMAL POUCH, exactly.
He said Hillary Scott, and added that it was an important plot point, and reminded him of the Heinlein novel as well.
Oh, and he forwarded this image of the movie's cover to me, after assuring to me that everyone in the cover was clothed:
and told me that Hillary Scott was actually the girl on the left and Eva Angelina was the one in the middle, though the names on the top of the people in this image might tend to mislead on that point.
This whole lexicon thing and the 75-page screenplay (assuming it was lots of dialog rather than just position directions?) makes me wonder about the bonafides of the movie as a movie. At least superficially it looks like someone put a lot of thought into all this, including a bit of linguistic thought.
Cliff also said the casting info on Disk #3 where they made sure the people casted could handle the lexicon's words was also quite amusing from a linguistic standpoint. I agreed to take his word on that.
I don't know whether to be delighted, disgusted, entertained, or terrified -- I really doubt this sort of thing is covered quite so colorfully in undergraduate linguistics classes!
This blog brought to you by 𐇕 (U+101d5, aka PHAISTOS DISC SIGN WOMAN)
So there is good news and bad news. Gather around boys and girls and I'll tell you what's what....
The good news?
Aimee Mann's upcoming new album (@#%&*! Smilers, which I mentioned previously in When in doubt, blame it on the @#%&*! SMILERS), is available to be streamed from Rhapsody.
You can check it out here....
I cannot verify any of this due to the requirement to install a "Real" player and all, but that is just a "me" issue, I assume most of my readers won't have such a philosophical problem
The bad news?
It is reportedly not available if you are outside of the US. :-(
In other news, if you are an iTunes kind of person then a special version of @#%&*! Smilers that is iTunes-only, with three bonus tracks that are not even available in the special limited edition copy of the CD:
Meanwhile, th Zune store only has the Freeway single so far. Way to hustle there, people.
The good news is that Zune content is at least available in three languages and the site is available in at least two -- and at least Canada is also supported now. I know there is a long way to go here but both two and three are greater than one, so at least it is the right direction. :-)
(The Zune store, like SiaO, is a Microsoft-hosted venture.)
In case anyone doubts that online music is changing the shape of things, online music and the many ways one can package a CD make my old habits (e.g. buying imports to pick up extra tracks) seem pretty tame.
But when the music is perfect I'll buy 'em, and when it is good I'll pick the most appealing package. :-)
Hopefully the "US only" thing from Rhapsody is an aberration, though I suspect the licensing issues have not quite caught up to the online world just yet....
This blog brought to you by ♭ (U+266d, aka MUSIC FLAT SIGN)
The whole thread started innocently enough, with a simple question:
Check out this shell command I typed & the result it got. Note the stuff in red. C:\>dir d:\enlistment\chef*.* /s /b d:\enlistment\LHC\tools\check_imports.cmd d:\enlistment\tools\check_imports.cmd C:\>Is this correct behaviour?Interestingly, though “chef*.*” finds things it shouldn’t, two variations (“chez*.*” and “cher*.*”) didn’t.I’ve attached a screen shot of a cmd window where I saw it.I’m using 64-bit Vista. I’ve attached a screen shot of my Computer/Properties window so you can see a more detailed description of the version.I’ve attached a *.cpp file a coworker wrote which demonstrates the behaviour by calling FindFirstFile directly. He sees the same behaviour on 32-bit Vista.
You can probably guess what's going on here -- the miracle of short file names (both of the "found" files have a short name of CHEFB4~1.CMD, which of course fits into the wildcard quite nicely....
Now if you stop right here, it's a nice little story about the assumptions we all make about wildcards from time to time.
And then of course someone pointed out:
This is really unfortunate for people doing deletes with wild card characters.
Then someone else responded:
Unless they do a dir /x foo* and then want to turn around and do a del foo*. It’s all a matter of perspective.
The original person asking then had a follow-up question:
Is there a way to make FindFirstFile ignore the 8.3 names? Maybe a flag we can set?
Of course someone pointed out KB 121007 (How to Disable the 8.3 Name Creation on NTFS Partitions).
Uh oh!
Luckily someone else was there to start listing some of the downsides in that plan:
Sorry, but that’s not great advice.1. Just because they’re not auto-created doesn’t mean that they don’t exist2. Doesn’t help for existing volumes or network access etc.3. Not very well tested; use at your own risk. E.g. as far as I know nobody ever runs any automated test passes with this feature disabled.The only real answer is that you need to look at the set of files that you get back from FF as candidates and then apply your own filter.
This is of course in addition to the ones given in the KB article itself. Though someone who perhaps had not read #1 or #2 or the ones in the KB article asked:
Just curious, can’t we stop generating them automatically? How many 8.3 applications do we still support?
There is of course the huge appcompat burden here, plus #1 and #2 above, plus a sample of an attempt to do something like this that I mentioned in Our non-Unicode heritage, plus on top of that how such a thing would break the auto-path shrinking work the Shell folks did that I mentioned in Sometimes what a person really wants is a LACK of size that deals with the MAX_PATH issues.
So in summary, in order to go to an 8.3-less world, one would have to solve all of the following issues:
Now maybe if the entire Windows team did nothing else beyond solving all of the problems associated with these three issues, for real, we might be able to ship the next version of Windows within 5-6 years after that.
And the most compelling feature to describe would be that we solved three problems that most people don't really understand exist until after you explain them and even then would not be very impressed that it would be a terribly compelling release to them.
Of course one could go the Apple route, and start over completely, changing the new one to have none of the above problems. Screw the backcompat crowd and start with no limitations at all.
I suspect we'd end up with an Apple-sized install base, with most people wanting the version of Windows that didn't tell people who merely wanted stuff to keep working to just get bent.
Anyway, the moral of the story? Beware the simple questions!
This blog brought to you by ঝ (U+099d, aka BENGALI LETTER JHA)
The other day, MVP Mike asked me via email:
Hi Michael,Have you heard about this problem? It's starting to make the "rounds" since XP SP3 came out. It appears to be a very serious problem, and the only reason (which is selfish) that I'm bringing it up now is that it is starting to affect my shipping app (been out for years). After reports of it started coming in, I did a quick google search and came up with this (even mentions the hotfix where this was introduced which was rolled into SP3): Font problems since installing SP3.I was wondering if anyone in the font team is aware of any problem like this or if you are already tracking it, and why it only seems to happen in certain apps, but not others.ThanksMike
I checked with people on the Typography team, and they are indeed now tracking this issue (they were unaware of it originally).
Some interesting (related) trivia about the face -- here it is the Font Picker dialog in Notepad before the install of SP3:
And here it is on a machine after SP3 has been installed:
Do you see how the order of items in the font style list changed?
Believe it or not, this is related!
The font was updated, and apparently a bit was set incorrectly when it happened.
As a workaround when it is in interactive UI, it is apparently in most cases possible to go to the font picker dialog and explicitly choose the "Regular" or "Bold" styles (both of which are bold in this "heavy" font) rather than the "italic" choice that seems to be getting picked up.
Thus won't help for applications and such, obviously
But the problem has been reported now so they are working on determining what is going on and how the particular hotfix described in the text of KB892598 (The middle dot character is not centered correctly if you use the Arial Black font or the Impact font on a Windows XP-based computer or on a Windows 2000-based computer with Service Pack 4) found its way into the XP service pack and how best to address the issue going forward.
This blog brought to you by · (U+00b7, aka MIDDLE DOT)
(A continuation after Summer vacation, the 1st, and there may well be a part 3 though perhaps in a later season)
The wedding was amazing, as was the whole weekend, really.
I'll be posting a bunch of pictures on facebook soon and I might even change my profile picture if one with the tux looks suitable. :-)
As per the usual, the Glazer family rocks, and as it turns out the Ogans rock too, and I have never been so proud as when I noticed that Jenny did not update her facebook status after the last "Jennifer is getting married!!! (this really warrants the triple exclamation)." one. Plenty of time for that stuff after they get back, and the whole point of work/life balance is to occasionally embrace LIFE....
Truly a wonderful visit to Cleveland, despite the lack of dancing on my part.
Though as vacations go it did fail in a couple of respects:
Obviously one of these caused the other (you can take your pick which one is the cause) but the reason I always come so close to losing vacation time at the end of the year is that I never manage to take the days. So it seems worth fixing that....
My next vacation will be in Sunny Orlando, next week -- about the same time as the developer half of Tech·Ed 2008 North America. Just before sunny Seattle becomes a more regular phenomenon, which kind of defeats the purpose, I know.
Just going as me (who happens to work for Microsoft) not as me representing Microsoft and my group. There is a difference, though the distinction will be lost in people who don't understand why someone in Windows wouldn't have access to Office code. Which is more than a few people out there....
I'm not speaking at the conference and probably won't be at Tech·Ed the whole time, but I will be at some of the parties and at a few of the events. I'll blather about this and that and maybe even do a Tech Talk, bog willing. I'll say hi to a bunch of people I haven't seen for a bit, and if I can swing it I will be at a minimum of one presentation in particular that I was invited to be at, to support a friend nervous about last-day placement.
If you are going to be at Tech·Ed and want to say hello then drop me a note via the Contact link (or even in a comment here if you want) and let me know, I'm sure we can probably find a way to meet and greet or get a drink or a meal or whatever. Especially those of you who live in the same city as me but I never see unless I am on the opposite side of the country, for whatever reason that happens.
If I do or say or hear anything interesting while I am there, I'll be sure to blog about it here in the Blog.
I'll let you know how it goes. :-)
This blog brought to you by ꄱ (U+a131, aka YI SYLLABLE TUX)
Self-identifying software developer and SQL Server database administrator Julia asked via the Contact link:
Last November you talked about Windows only cultures providing a potential solution for the collation differences between SQL Server and the .NET Runtime. Do you know whether this solution will be used in the upcoming version of SQL?
Fascinating question, Julia!
The blog she is referring to is When yesterday's workaround becomes tomorrow's potential solution... from the end of November of last year.
In it I pointed out how Windows-only CultureInfo objects, where .NET's CultureInfo is synthesized via Win32 NLS API function calls, open a fascinating conceptual door.
Because all SQL Server would have to do is re-expose their own internal collation functions to the CLR, and this would allow some future version of .NET to support "SQL-only CultureInfo objects", for lack of a better term.
And this design would solve the current problem where .NET's collation behavior does not match SQL Server's, even when one is including managed code in one's stored procedures.
Conceptually, this seemed to me like the geek equivalent of what basketball fans might think of as a three-pointer. If you know what I mean....
Alas, as any people playing with the SQL Server 2008 CTPs (including me, as I pointed out in On changing the world, or at least the way people order things in it) can testify, this is really not what is happening in SQL Server 2008, mostly.
The "mostly" refers to an interesting exception -- if one is
then one can actually get comparable results in their managed code running in their stored procedures.
I don't think there was specific intent behind this, though -- it looks more like a bunch of components behaving as they are designed to running into a somewhat fortuitous circumstance.
It would take a bit more overt work, in future versions of both SQL Server and the .NET CLR's Base Class Libraries, to completely "hook up" this solution and allow the results to be not just comparable but truly equivalent....
Now I have no idea if this is planned for the future or not, though I do know that until and unless that happens, in the meantime all of the built-in .NET CultureInfo objects and there CompareInfo objects will be much further away from the new 10.0 collations in SQL Server 2008.
I'll be talking more about this topic another day....
This post sponsored by ག (U+0f42 a.k.a. TIBETAN LETTER GA)
Regular reader Jan Kučera asked over in the Suggestion Box:
Hi,Okay, this might be a little bit non-technical question, but... every day, somebody wants a _strong_ password from me. The best one would be of course kilometer long, with some crazy stuff like _-*!#$ in it.Well, I have nothing against special 'symbols' in the password, but why on earth only ASCII characters are supported? I don't know how about eg. banks in USA, but for my short life I haven't found any web site allowing me to enter (um... support) unicode password.Am I missing something fundamental here? :) Jan
My experience has been similar to Jan's though slightly different:
Thus when you look at MSDN topics like Strong Password Enforcement and Passfilt.dll, they say things like:
The following complexity requirements are enforced by strong password enforcement: Passwords may not contain your user name or any part of your full name. Passwords must be at least six characters long. Passwords must contain elements from three of the four following types of characters. Character types Examples English uppercase letters A, B, C, … Z English lowercase letters a, b, c, … z Westernized Arabic numerals 0, 1, 2, … 9 Non-alphanumeric characters (special characters) $,!,%,^ Unicode characters €, Γ, ƒ, λ
The following complexity requirements are enforced by strong password enforcement:
Having a nod to Unicode seems nice, and it is a welcome addition to the world of password complexity.
But I have a hard time having four categories apply to a subset of the first 27 characters in Unicode and then having just one category apply to the other 65,000+ characters in the BMP.
The fact that
seems to not be considered.
Articles that put more verbiage and justification into the issue, like Strong passwords: How to create and use them, somehow just seem worse, with the only nod to the bulk of Unicode being isolated suggestions like
Your password will be much stronger if you choose from all the symbols on the keyboard, including punctuation marks not on the upper row of the keyboard, and any symbols unique to your language.
or
You can use symbols that look like letters, combine words (remove spaces) and other ways to make the password more complex. Using these tricks, we create a pass phrase of "MySoN 8N i$ 3 yeeR$ old" or a password (using the first letter of each word) "M$8ni3y0".
But say if I tried to make a password based on random Unicode characters, such as:
ফཛڰװෝܣ໓ᄝឲౠफ़ဏஇฬほᢎሄ
sites like the Microsoft Password Checker consider this password to be weak.
To me, this seems like an analogue to audio encryption that uses frequencies beyond human auditory ranges, and hardly "weak".
Unless the checking is done for sites that convert the string to the system default code page, which would turn most of these to question marks....
This blog brought to you by ཛ (U+0f5b, aka TIBETAN LETTER DZA)
Some questions, I find myself holding my breath as I am reading them.
Confirmatory questions (questions where one has a hopeful assumptgion about the answer but with some [perhaps lingering] doubts prompting the interogatory statement) in particular.
This is because I start to worry (as I am reading) that the question is going in a direction that will require a "negative" answer -- an answer that deviates from their hopeful assumption.
A good example came through the other day:
Reviewing the info on the Unicode website, we see different up-casing rules, based on locale (i.e. Greek, Hungary). We also know customers can install different MUI packs on Windows and change the default locale for both user accounts and the system account. However, we think the up-casing rules in l_intl.nls do not change, regardless of the MUI packs installed and the locale set for user or the system accounts. Is that correct? Installing different MUI packs and changing the locale for user and the system accounts won’t change the up-casing rules software which depend on l_intl.nls won’t see a change in up-casing rules?
Luckily I got to exhale, realizing that my answer could help them realize that I did not have confirm their fears.
Because it is true that sometimes between versions of Windows the casing table has changed.
And it is true that if you pass the LCMAP_LINGUISTIC_CASING flag that the casing table has some specific changes for Turkic languages in particular.
But the changes the questioner was worried about? They don't happen. :-)
Of course the episode then inspired a bit of philosophizing on my part, since I wondered why it would bother me, what with so much of my job being about telling people how they are doing something wrong or bad or crazy or weird or dangerous or politically offensive.
And then having them thank me for doing it.
Why does the simple question and the fear of having to dash hopes cocern me when there is no emotional investment, if it is not going to bother me when I am working with a team more prominently?
It turns out the reason is fear of rejection.
If I am invested with a team then they know who I am and something about me, and they usually listen and seriously put thought into whatever I recommend. They may choose to ultimately not take the advice, but when they do they have reasons for their choices and I have confidence that they did their due diligence and have an understanding of the consequences.
When there is no such investment and I confirm their original plan's validity then again there is no worry -- they go along on their merry way feeling good about their decision.
But when there is no such investment and I confirm their fears, things don't always go as well. They might dismiss my words without the extra consideration, and then I have to fear how much of my own reputation or approach may have influenced their decision.
No one likes their opinions rejected, and although for the most part I don't care, the fear that a bad decision could be made due to someone dismissing the nature of a message's "envelope" rather than its content does cause concern, for me.
Since I seem to have such a polarizing envelope, sometimes. :-)
Luckily things were okay this time. But this is all kind of stressful so I should figure out a long term solution to this fear of rejection (or more accurately, fear of the potential negative consequences of the rejection) just to keep my own stress level down....
I have some reflections about this as well, but I will save them for another time since I thjink I have buried the technical question enough for one blog. :-)
This blog brought to you by ѐ (U+0450, aka CYRILLIC SMALL LETTER IE WITH GRAVE)
Have you ever done something in a wild, partying social situation when you wee younger that seemed like a great idea at the time, but then you just woke up the next morning and realized it was not such a great idea?
Extended this slightly inappropriate metaphor allowed me to give a good conceptual model for the answer to a technical question. :-)
This was a fun question from the other day:
Our code no longer has to support anything earlier than XP. I'd like to remove all of the references to WC_NATIVEFONTCTL, but I do not know if the reference is still needed?
A quick look at the code seemed to imply that it only worked at all in COMCTL32 v.5 and was present but non-functional in COMCTL32 v.6, but I thought I should ask some of the experts over in the Shell. Raymond Chen volunteered some useful historical information, plus info on the implementation:
The native font control was a hack... ...back in the days before font linking. It has been useless for a decade. I don't know whether it's been formally deprecated, but it is deprecated in practice.Vista with comctl v6 -> native font control exists but does nothingVista with comctl v5 -> native font control exists and does stuff, but who knows whether it "works" - it makes some assumptions which probably haven't been true for years
He then pointed to some documentation that is also way out of date on this control, in a topic called Localization Support for the Common Controls.
On top of all of that, it does try to involve itself in both GDI font linking and GDI font association and not much else, which means it really only ever does anything "useful" for East Asian platfoms....
Though on the other hand, I ranted a bit on the problem with font association in A more definitive definition of[ Font ]Association (a technology that helps us put the backward in backward compatibility!). Which kind of covers how I feel about the theoretical "usefulness" here.
But the whole idea of having the control do absolutely nothing of consequence appeals to me as a great way to do the deprecation -- it reminds me of when Scott Adams talked about how the people who complained about the performance hit of The Dilbert Zone when advertising was added were kind of set up a little, since hidden ads had been running for some time with no one complaining. How can people be upset if they didn't notice it wasn't working anyway (and didn't need to work since the OS now did a whole bunch of work anyway). :-)
Most people use COMCTL32 v.6 these days, so luckily this not entirely useful control is not entirely used. And sooner or later the documentation should catch up.
And you (the developer) should treat it like that really bad idea one might have gotten involve with when one was young and foolish. Now, as an older, wiser, and more mature person, you should do the right thing -- and not take this one home....
This blog brought to you by ⺋ (U+2e8b, CJK RADICAL SEAL)
Now with gas prices being what they are, there may be some real advantages to considering riding the tricycle instead of the Porsche, especially if one can fit in the smaller space and one does not have to take it as far. And if one does not need the extra features.
But in the end one still has a tricycle. And one might not fit in it very well, and has to decide if it is the best plan....
The mail from the other day via the contact link was:
Someone posted this:---------- CREATE TABLE #TEMP (name varchar(80)) INSERT INTO #TEMP values ('Malteser Schloßschule') INSERT INTO #TEMP values ('Malteser Schlossschule') CREATE TABLE #TEMP1 (name nvarchar(160)) INSERT INTO #TEMP1 values ('Malteser Schloßschule') INSERT INTO #TEMP1 values ('Malteser Schlossschule')Query 1: SELECT * FROM #TEMP WHERE name ='Malteser Schlossschule'-- Results :- 'Malteser Schlossschule'Query 2: SELECT * FROM #TEMP1 WHERE name ='Malteser Schlossschule'-- Results :- Malteser Schloßschule-- Malteser SchlossschuleThe collation of tempdb is SQL_Latin1_General_CP1_CI_AS. I'm using SQL Server 2005.---------------------------Why does this happen? I'd expect that it would work in the reverse way. 2 rows with varchar and 1 with nvarchar.
This is actually quite expected, believe it or not. There are several contributing issues here:
First, as described in SQL Compatibility collations are a bit too retro for me, the order in the SQL compatibility collations is not a very good one. Among other things is the fact that they do not support the German Sharp S in any real sense, which makes them kind of bad for German. There are many other examples, but this is the basic reason why the first query returns one row.
Second, as described in Unicode and SQL Collations have nothing to do with each other, there is no Unicode support in the SQL compatibility collations. The server is forced to go with the closest Windows collation in this case, and all Windows collations have the Sharp S support in the default table, which is why the second query returns two rows.
Thirdly, as described in SQL Server: compatibility collations vs. Window collations, there are a whole lot of differences between these two when they are compared head to head -- it isn't just like comparing apples and oranges; it is like comparing bicycles and earmuffs.
There really is no way to put these two different kinds of collations in an attempt to compare them. They are way too different....
In the end, even non-Unicode data is better with a Windows collation -- just like even the toddler who fits well in the tricycle is better off getting a ride to preschool from a parent in the Porsche. Sure there is a bit of extra work with car seats and such, but it is much better for getting the job done than trying to force this less adequate mechanism to do everything.
This post brought to you by ር (U+122d, a.k.a. ETHIOPIC SYLLABLE RE)
Joost van Doorn asks (via the Contact link):
Hello Michael,Since your name appears in a lot of MSDN questions on International application programming, I ask my question directly to you. I'm working on an application that supports various languages. It is a C++ (Borland Builder) application. One of the aspects involved is the addition of extra keyboard. I use the API function LoadKeyboardLayout and I can add, for example, French with a french keyboard. However our PCs are always sold with a US-International keyboard. So I would like to, for example, French with a US-Internal keyboard.I have tried two approaches:1. Use the LoadKeyboardLayout function: This does not work. I always get the return value "04090409" (I run XP - English).2. Changing the registry: Changing the HKCU\Leyboard layout properties is no problem but getting the new settings active - without rebooting - is a problem.I have posted some question into the MSDN newsgroups but up to now no answers. This is really important to me so could you please help me.Best regards,
The registry mucking is a truly bad idea -- I highly recommend against that approach.
It is true that LoadKeyboardLayout won't work here -- it only works for loading a specific keyboard when the language it is to be under matches. Having the LANGID in the LOWORD of the keyboard's KLID not match the language the keyboard is under? LoadKeyboardLayout isn't able to help. :-(
Though as I mentioned in Cutting the cord, revisited -- and documenting how to get the job done!, there is now a documented method for getting this done: the InstallLayoutOrTip function in input.dll. This is new in Vista and supports these "mixed language" scenarios.
Though some have read Not exactly reverse engineering... and been intrigued by those [NONAME] exports, all I can say is that this new Vista function is not one of them -- so that isn't the most productive line to pursue. For earlier versions there is really just one answer that is documented/supported - the InputLocale keyword in an intl.cpl unattend call describead in KB289125 (mentioned in blogs like this one, previously) -- note that the first value is LANGID of the language for the Language Bar, and the second is for the KLID representing the keyboard.
This post brought to you by ಊ (U+0c8a, aka KANNADA LETTER UU)
The title of this blog is yet another episode in the grand tradition of titles that do not match the content they introduce, with no substantial comment about either the Office Assistant in general or the pregnancy scandal in particular beyond the intro, in red. Clippy, originally referred to in Office 97 Beta 1 as a "Thin pulsating wire", ended up alongside Scribble, the paper cat. Earl the Cat (shown below) was an out-of-the-box Office Assistant known for being a bad boy who was willing to hook up outside his species but did not overlook the "pulp-based morsel" (his words) in the Office box, who helped Scribble end up in a family way with a pack of Post-it notes. Please note that (as of a few minutes ago) not even the Wikipedia page on the Office Assistant refers to either of the latter two characters or others like Super Pup and certainly never discusses the more sordid aspects of the existence of Clippy or Earl or Super Pup (aka Nazi Pup), a topic for a future blog that some speculate I lack the pair to write. Given the untrustworthiness of this Blog as an official source according to my management, neither this blog nor any of the content therein is suitable as Wikipedia source content unless other corroborating sources are found.... Please note that the use of they in the first sentence of the introductory note is not an example of "Singular They" since they was referring to the plural noun titles. Actually, It is actually a well-known fact in my bizarre dialect of English that every blog or title that I write that is clever is female and the rest are male (welcome to my world, we have shirts that 23-year-old girls are reportedly willing to wear). Since (due to the aforementioned rule) the gender of my blog content is always known, "Singular They" is as unnecessary as (in the words of Connecticut's own Tom Troy, the man who taught me everything I had no real need to actually know including how to make a divorce take a lifetime to accomplish) tits on a bull, and further "Singular They" is only seen in this blog periodically because I am not plagued by consistency and I am plagued by a desire to tell language mavens to get bent anytime they complain to and/or about me....
The title of this blog is yet another episode in the grand tradition of titles that do not match the content they introduce, with no substantial comment about either the Office Assistant in general or the pregnancy scandal in particular beyond the intro, in red.
Clippy, originally referred to in Office 97 Beta 1 as a "Thin pulsating wire", ended up alongside Scribble, the paper cat. Earl the Cat (shown below) was an out-of-the-box Office Assistant known for being a bad boy who was willing to hook up outside his species but did not overlook the "pulp-based morsel" (his words) in the Office box, who helped Scribble end up in a family way with a pack of Post-it notes. Please note that (as of a few minutes ago) not even the Wikipedia page on the Office Assistant refers to either of the latter two characters or others like Super Pup and certainly never discusses the more sordid aspects of the existence of Clippy or Earl or Super Pup (aka Nazi Pup), a topic for a future blog that some speculate I lack the pair to write. Given the untrustworthiness of this Blog as an official source according to my management, neither this blog nor any of the content therein is suitable as Wikipedia source content unless other corroborating sources are found....
Please note that the use of they in the first sentence of the introductory note is not an example of "Singular They" since they was referring to the plural noun titles.
Actually, It is actually a well-known fact in my bizarre dialect of English that every blog or title that I write that is clever is female and the rest are male (welcome to my world, we have shirts that 23-year-old girls are reportedly willing to wear). Since (due to the aforementioned rule) the gender of my blog content is always known, "Singular They" is as unnecessary as (in the words of Connecticut's own Tom Troy, the man who taught me everything I had no real need to actually know including how to make a divorce take a lifetime to accomplish) tits on a bull, and further "Singular They" is only seen in this blog periodically because I am not plagued by consistency and I am plagued by a desire to tell language mavens to get bent anytime they complain to and/or about me....
Singular They is a pretty well-known and described phenomenon. Whether one looks at the article on Wikipedia, the three articles on the new Language Log site, the 46-some articles on the archive Language Log site, any of the other places on the Internet where you might go for such things, or even the one singular time I mentioned it here, there is little that is left to be understood about it.
Except maybe on Facebook.
Now almost everyone I know who I am friendly or cordial with who is under the age of 60 is on Facebook now, with only a few exceptions that contain in them enough venom to fell any normal man, even though most of them are not on my actual "friend" list.
I'll include here the people who have unfriended me, including the special subgroup of passive/aggressive twits who did so without saying a word, which is simply too weird for me to even try to analyze; given that those who informed me they were doing it had good reason, I suspect the others of lacking either (a) the guts to do so or (b) the spine to hold up their guts long enough to do so, and I just write them off.
Just the other day, Eric Bakovic was talking about it in Singular they on Facebook, though he gave Facebook a little too much credit, claiming:
So, for example, a news item from a specified-male Facebook friend will show up on my news feed like this: John Doe added "fried chicken" to his favorite foods. An item from a specified-female Facebook friend will show up like this: Jane Doe added "pizza" to her favorite foods. And an item from an unspecified-sex Facebook friend will show up like this: Kim Doe added "burgers" to their favorite foods.
So, for example, a news item from a specified-male Facebook friend will show up on my news feed like this:
John Doe added "fried chicken" to his favorite foods.
An item from a specified-female Facebook friend will show up like this:
Jane Doe added "pizza" to her favorite foods.
And an item from an unspecified-sex Facebook friend will show up like this:
Kim Doe added "burgers" to their favorite foods.
Yet I routinely see notices like this one whether people have noted their sex or not
I don't see it as much any more, which suggests the remaining times might actually be Facebook applications rather than Facebook itself.
(Other Facebook coverage on Language Log other places like here and here -- which cover other examples of what I am talking about here)
But if Facebook is going to take the time to handle her/she and him/he differences in addition to distinguishing the possessive cases, including the generic issue between he/she/they, I wonder why they can be so silly as to introduce phrases such as they has.
Couldn't they go the last mile to take care of these few additional cases? :-)
On the other hand, they still can't handle simple locale stuff like I mentioned in Saying you want to be 1,00,000 strong may not be (and often is not) a typo! or non-Facebook complicated stuff like I mention in In a much better position to handle inserts, so why should I expect the complicated English stuff to be handled well?
English is really hard, obviously. You has no idea how hard, probably (don't feel bad, since neither does they).
This post brought to you by p (U+0070, a.k.a. LATIN SMALL LETTER P)