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 several scripts that have the notion of case, like Latin, Cyrillic, Greek, Armenian, Coptic, Glagolitic, and others.
There are some folks like Michael Everson who believe that even if a character does not have both cased variants that they may well have them one day, and should thus both be encoded.
Some people agree with him, others would rather wait for letters to be attested first.
It is a perennial battle. :-)
But anyway, earlier today when I posted See that version there? It is going down, man! #2 (aka Everybody WYNNs), something occurred to me about U+01bf, a.k.a. LATIN LETTER WYNN, which has been around at least since Unicode 1.1.
And that is the fact that Unicode also has U+01f7, a.k.a. LATIN CAPITAL LETTER WYNN, and has had it since Unicode 3.0!
But the Swedish tables do not put these two letters next to each other.
This other letter is on our collation tables, given special weight for Turkmen (0x0442), which does not put it anywhere near the lowercase version.
And our default table does not put them anywhere near each other, either.
Of course in our casing table update in Vista, both characters are there and map to each other (prior to Vista they did not; this is one of the many mappings that was missing!).
And Unicode's default collation table does have them right next to each other.
Now this is somewhere between zero and three problems, depending on whether Swedish/Finnish, Turkmen, or the default table should be putting them near each other. They do not seem to be put together in languages that use one or the other, so it is honestly unclear whether one would expect them to be put together.
Is this yet another time where collation != case (like I have mentioned before), and an interesting one, to boot? :-)
Anyone from Sweden, Finland, Turkmenistan, or elsewhere have any opinions here about this issue with WYNN and CAPITAL WYNN?
And where does U+16b9 (RUNIC LETTER WYNN) fit into all of this? :-)
Clearly the letter is no longer what it was in Old English. But on the other hand, what was it then? Are there any actual bugs here?
Every letter with three characters in Unicode behind it has a story too, I guess!
(more on Wynn, here)
This post brought to you by Ƿ (U+01f7, a.k.a. LATIN CAPITAL LETTER WYNN)
When I posted part one of this two part series, I should have guessed that Dean Harding would have a good answer:
Well, I'd say if the major version changes *either way* you should re-index. If a minor version changes backwards, you probably have to re-index as well. Because otherwise, you basically have to re-index strings that *now* return FALSE for IsNLSDefinedString and you couldn't do that without scanning them all -- so you may as well just re-index everything. To be honest, though, I don't see how you could have done anything differently. If you wanted to skip the "re-index on minor version decrement", I believe you would have to change IsNLSDefinedString so that it returned the minimum version that the string would have been defined in, and I can't imagine how big the data file would have to be to make that possible :-)
Well, I'd say if the major version changes *either way* you should re-index.
If a minor version changes backwards, you probably have to re-index as well. Because otherwise, you basically have to re-index strings that *now* return FALSE for IsNLSDefinedString and you couldn't do that without scanning them all -- so you may as well just re-index everything.
To be honest, though, I don't see how you could have done anything differently. If you wanted to skip the "re-index on minor version decrement", I believe you would have to change IsNLSDefinedString so that it returned the minimum version that the string would have been defined in, and I can't imagine how big the data file would have to be to make that possible :-)
This is spot on correct -- either major or minor version changes would require you to re-index, and there really is no way around that without adding a whole bunch of metadata about the nature if the changes and/or Dean's suggestion (information about character age with the same weight). The only alternative would be if one had actual knowledge of the changes because one happened to be working there, or one happened to hear about the change.
For example -- and this is a not entirely contrived example as it may happen one day -- let's say that the prevailing practice in Sweden were to change along the lines I discussed in Why do we call w 'double u' -- doesn't it look more like a 'double v'? and the Swedish Academy's change to split W and V and give them both primary weights were picked up in some future version of Windows.
To be perfectly honest I expect it to happen eventually, though we could even be looking multiple versions into the future before it was generally expected by the public.
(I am actually curious how fast it will be in these modern times, and whether the inertia surrounding such updates will hold it back and if so for how long!)
Okay, so that is a major version change for sv-SE (0x041d) that may or may not apply to sv-FI (0x081d) and which definitely wouldn't apply to fi-FI (0x040b). But only a major version change in the NLS version, not the defined version -- since the repertoire is unchanged.
We have done it before (ref: The disunification of Norwegian and Danish sorting), so that part is no problem.
I am sure I'll even talk about it here, I may even know a bit of Swedish by then!
In this particular case though, even if that one specific locale (or two specific locales!) change, the change itself actually has no point in worrying about IsNLSDefinedString results since none of them would have changed (this kind of underscores the reason why IsNLSDefinedString results would not be useful!), but it may be worth scanning and only re-indexing strings that contain one of the following characters (these are the ones that move for this change in Swedish/Finnish, I don't know whether the WYNN would actually move in this case or not):
and not touching the rest. Glancing through at a few Swedish corpuses, I think from a performance standpoint it might be cheaper to approach it that way in such a case....
Now clearly this might not be typical. But on the other hand it might be, to strike the proper correctness/compatibility balance!
This post brought to you by ƿ (U+01bf, a.k.a. LATIN LETTER WYNN)
How does that expression go, that you can't keep a good Windows International Open Language tool down?
Well, you may recall back in January of this year when I was saying Please excuse the interruption how the Locale Builder beta had expired.
The tortuous wait is now over, and the Microsoft Locale Builder is now back!
Do you think we should call it MLB or MSLB? I prefer the latter so it sounds like MSKLC, but I'm sure people will have their own opinions....
In any case, you can get it right here from the download center, and I am sure other sites will be up soon (I'll update with additional links as they are made available).
Congrats to all the work behind the scenes to make this happen and thanks! Entirely too many people had to do a lot of work that I can't even talk about to make the tool available again. And I am incredibly glad they did. :-)
I started with a half-hearted version of the Mark Morrison song (Return of the Mack) but my heart wasn't in it (in part because it forced me to use MLB the way it was shaping and in part because the themes of that song don't seem entirely appropriate here!)....
This post brought to you by ᗪ (U+15ea, a.k.a. CANADIAN SYLLABICS CARRIER PE)
When I first started working in Windows and for several years, I did not really act by default like a member of the Windows team -- I kept looking at problems like an outsider and it was an effort of will to look at things from the inside.
For the most part this was very helpful since it helped me to be able to point out times that people were missing out on some external developer scenarios.
But slowly that viewpoint faded, and while I did not forget the work I did before, the viewpoint changed.
Add to that the times that specific scenarios are not ones you have been thinking about, because they did not occur to me and no one else mentioned them.... and if you don't think of them and they aren't in th spec and no tester puts in a bug about them, then how is one supposed to keep them in mind?
I'll now give a good example of this. :-)
When I talked about the recommended process for using the NLS version information to figure out when to re-index, first back in What makes a string meaningful? and then in Collation data - must be stable, but it must not stand still, I was thinking about components that worked on that version of Windows and moved forward when Windows did. That process:
This is all well and good, but there are a few scenarios that are not covered here:
This puts a cat among the pigeons, doesn't it?
Not impossible, by any means.
But also not currently described in the docs or here at SIAO Plaza.
I'll let this simmer for a bit and I'll come back with the additional rules in the morning.
You have a few hours if you want to take a guess on one or all of them, or somewhere in between.
Winners of this contest can read this blog free, for life! :-)
This post brought to you by ឯ (U+17af, a.k.a. KHMER INDEPENDENT VOWEL QE)
I am on the Linguist List.
Now mind you. I don't participate. I just watch the messages go by, and read the one I understand and set the others aside in case I might understand them some day.
Despite my delusionsnotions of lingustic aptitude, I feel kind of unworthy. No, scratch that, I feel very unworthy. :-)
But every once in while something gets posted that I figure it might be worth parroting, like this latest one from Joan Spanne of SIL:
The review period for the 2006 series of Change Requests ended June 30. Of the 120 requests considered, seven are still pending, because either they affect code elements included in both ISO 639-2 and 639-3 or additional information has come to light which requires further analysis. Of the decisions finalized:11 code elements are retired as having been duplicates of another language (2), determined to be nonexistent (2), or merged into another code as being mutually intelligible varieties of the same language (7); 4 code elements have undergone a broadening in their denotation due to merges with other language varieties; 8 code elements have been split into two or more distinct languages, accounting for the creation of 24 new code elements (net gain of 16 individual languages); 49 entirely new language code elements have been created for languages notpreviously accounted for in the standard. Of these, 11 are ancient languages; 47 code elements have undergone name changes and/or additions without any change in denotation. A summary report of changes and outcomes may be viewed and downloaded as a PDF document. Please see http://www.sil.org/iso639-3/default.asp for more information and a link to the summary report.The 2007 series of change requests is now visible via the Change Request Index, http://www.sil.org/iso639-3/chg_requests.asp, which permits sorting in various ways and has links to specific documentation for each change being proposed. Proposals for 2007 will be accepted up until September 1, 2007, and will be formally under review from September 15 - December 15. Outcomes will be announced for these proposals in January 2008. Proposals received after September 1 will be a part of the 2008 series of Change Requests, and will await formal review from September 15 - December 15, 2008. Thank you, Joan SpanneISO 639-3/RA SIL International 7500 W Camp Wisdom Rd Dallas, TX 75236
I know there are a few people who read here who find ISO 639-3 to be interesting, so I thought it might be worth quoting Joan on this one.... :-)
On a slightly more personal note, I have to say that SIL in general and Joan and particular have a lot to learn about managing ISO standards. Where is all of the unreasonable politics, over-entangled processes, difficult bickering, and endless reams of documents? And what's with all of the efficiency! Sheesh!
Just teasing Joan. Thanks for making this one of the most efficient and powerful active standards I know of!
This post brought to you by ㎔ (U+3394, a.k.a. SQUARE THZ)
I'll admit that the logical argument here is incredibly flawed.
The first principle is easy enough to state:
Cats always land on their feet1.
And the second principle is also easily stated:
Buttered toast always lands butter side down.
Combined together, these two principles form the basis of the buttered cat paradox, which combines these two bits of wisdom by attaching a piece of toast atop the torso of a cat with the butter side up, and then dropping them from some height to see which bit of folk wisdom takes precedence.
The third bit is probably not as exalted as a principle or even a bit of wisdom, but is an old expression -- namely, that
There are more ways to kill a cat than buttering it with parsnips.
The imputation might be that the resolution of the buttered cat paradox might be the untimely the death of said cat, via yet another paradox (the whole irresistible forcing meeting an immovable object idea), to the extent that intentionally fashioning a toast overcoat for a feline and dropping both of them from a height could cause such a fatality to be considered "untimely".
Beyond the obvious problems related to animal cruelty implicit in both act of attaching the toast (super-glue? paper clips? Velcro?) and dropping the feline from a height of any significance, there is the underlying problem of the ethicallity of proceeding with any experiment involving buttering a cat with or without parsnips if on has knowledge that it could indeed result in the feline's death -- something that no one would hopefully want to happen.
I had originally thought the title might make an excellent Ph.D. dissertation, but was forced to abandon it for ethical reasons....
1 - In the course of my life I have only had one cat that did not, in fact, land on her feet. It was a decidedly odd situation where she fell off the radiator she was climbing to get the windowsill. She fell,and landed on her side. Quickly getting up and seeing that I witnessed this violation of that which many cat owners (and many more cats!) consider to be a natural law, I don't think she was ever quite the same after that. But let us think of dear Kristina Michelle of blessed memory as the exception that proves this time honored rule.
This post brought to you by Ω (U+03a9, a.k.a. GREEK CAPITAL LETTER OMEGA)
You may have read my previous post on the 'unattend' file format info for Vista, creatively titled Unattend for Regional and Language Options in Vista.
Well, now you can find the official documentation on the subject, in this recently published white paper:
Windows Vista Command Line Configuration of International Settings
This white paper includes all of the ins and outs of the XML file and its expected format possibilities, and lots of tested samples to help people make the best use of all of the important new capabilities in Vista.
Special thanks to Gary, Anna, Shelby, Marie, and Rob for all of their hard work....
Enjoy!
This post brought to you by ໂ (U+0ec2, a.k.a. LAO VOWEL SIGN O)
So I was reading Language Log and saw one of Mark Liberman's latest posts.
After seeing Janet Hyde's quote ("Men are from North Dakota and women are from South Dakota"), I was thinking back to the penultimate third season episode of the West Wing ("We killed Yamamoto").
Donna Moss was sent to a bunch of hearings in North Dakota, as people there were looking at a proposal to drop the word North from the state, just calling it Dakota. A sample bit from it:
Donna: Eliminating the term north from North Dakota is an important state issue and the President feels it should be resolved on a state level. While the President is sympathetic towards the cause and understands the large economics ramifications of this name change, he feels the issue is not yet ripe for national attention. The President wishes you well on your endeavors and thanks you for your support.Guy from ND:Uh, Miss Moss? Are you aware that studies clearly show the word 'north' leaves the impression that this state is cold, snowy and flat, significantly depressing tourism and business startup.Donna: With due respect, sir, your average temperature is 7 degrees. Your average snowfall: 42 inches, and a name change isn't going to take care of that.Girl from MD: We enjoy roughly the same climate as South Dakota. We took in 73.7 million in tourism revenue last year. They took in 1.2 billion. They have the word south.Donna: Also Mount Rushmore.
Now this episode was from May of 2002, and was both very fictional and one of those fun Sorkinian twists on events of not too long before. In this case the actual issue started with a proposal from the GDNA (Greater North Dakota Association -- formerly at www.gdna.com but that is now a porn site as the site itself has been defunct since late September 2004).
The proposal, talking about a big new economic initiative, included the idea of the need to change the name. The governor was supportive at first, but some strong editorials (e.g. Just changing 'North' won't keep economy from going south, retrieved from the Internet Archive from July 2001), the fun polls throughout the state that were hugely opposed to a name change, and then in August 2001 the Dave Barry column ("North Dakota name change lacks direction"), it was pretty widely snickered at nationwide when it happened, so the new "history" of it in the West Wing episode is kind of a fun postscript.
Getting back to Janet Hyde's quote "Men are from North Dakota and women are from South Dakota" it does add a fun (unintended) pragmatic dimension to the quote.
I'm not sure what that meaning is, but somewhere in the industrial/economic/touristic issues, the very real population concerns, the Mount Rushmore envy, and more, the intended meaning which was probably much more of a Zook/Yook "butter side up vs. butter side down" kind of thing is thrown overboard, and once again suggests massive differences between men and women despite all evidence to the contrary. :-)
I realize I am being a bit of a troublemaker with the silly suggestion of hidden meaning, but it's Sunday night and I am known for being ornery....
This post brought to you by 𐑧 (U+10467, a.k.a. SHAVIAN LETTER EGG)
That's right, the Society of Typographic Aficionados (SOTA) is putting on TypeCon 2007 August 1st-5th at the Seattle Crown Plaza Hotel.
And I'm going to be there -- SIAO will be talking about the event!
(I am not a speaker at the event, but there are like more than 85 people who are and who are more qualified than I to do so!)
I didn't get press credentials or anything like that, though I'll see what I can do about blog entries as the conference progresses, as there are a lot of interesting things going on. :-)
If you're going to be there, let me know (if you would like to be there, they extended the regular registration until tomorrow (details here).
In their own words:
The typographic center of the universe is at TypeCon2007: Letter Space. More than 85 amazing speakers will be in Seattle for SOTA’s ninth annual conference, including Marian Bantjes, David Berlow, Roger Black, Robert Bringhurst, Matthew Carter, Art Chantry, and Modern Dog. We've extended regular registration so that more people can enjoy an affordable week of presentations, workshops, panel discussions, exhibitions, and special events.
Now someone mentioned the other day that this blog seemed like the collationary center of the universe and I don't think his choice of words can be put down as a mere accident. In my opinion, you can think of SIAO being at TypeCon2007 as a reasonably geeky kind of harmonic convergence, one that was too cool for even the Mayan calendar to make note of.
I suspect the universe will not explode, in any case....
I'll be the one with the scooter and the MacBookPro with Mac OS X Tiger, Vista 32-bit, and Vista 64-bit partitions!
So, see you at TypeCon 2007, whether you are my "type" or not! :-)
This post brought to you by t (U+ff54, a.k.a. FULLWIDTH LATIN SMALL LETTER T)
It was about a year ago that someone was looking at the Windows Developer Kit documentation and had a question.
They were comparing RtlUpcaseUnicodeChar/RtlUpcaseUnicodeString/RtlUpperChar/RtlUpperString versus RtlUpcaseUnicodeStringToCountedOemString, in particular wondering why the first four were documented as requiring IRQL = PASSIVE_LEVEL while the latter was documented as requiring IRQL < DISPATCH_LEVEL.
Apparently they were just confused as to the difference.
To me it made some sense that RtlUpcaseUnicodeStringToCountedOemString, which is part of the IFS (Installable File System) document set and the kind of function (uppercase and convert to the OEM charset) that is most likely to be even possibly needed at APC_LEVEL anyway.
I decided not to say anything at the time (I was mostly cured of desire to clarify at this level after all the back-story in the research that came up in the comments of Ready... set... Reboot!), and someone else from the team pointed out the obvious fact that the documentation was really not so far off from the truth anyway.
Though to be honest all five of them could be called at APC_LEVEL if needed. It is just that most of them would not be. So perhaps no change was really needed.
As Doron pointed out last Spring in not entirely unrelated comments to String buffers and IRQL:
APC_LEVEL is probably OK since you can handle paging i/o at that IRQL, i don't think there is anything special in the NLS tables that would preclude APC_LEVEL. I don't mention APC_LEVEL much because for a non FS related driver, you don't deal with APC_LEVEL much, so talking about it leads to more confusion then if we just talk about IRQL as PASSIVE_LEVEL, DISPATCH_LEVEL, or DIRQL.
Anyway, they made changes to the documentation after this conversation, with the former four functions now being documented as requiring IRQL <= APC_LEVEL and the latter requiring IRQL < DISPATCH_LEVEL (the latter did not change, while the former four did).
Which to me is weird, since the two directives are essentially identical, though the one that is theoretically more likely to find APC_LEVEL interesting given functionality requirements makes no mention of APC_LEVEL, while the four that probably are not going to need it explicitly mention it.
Not a big deal, and maybe not even worth changing, since a difference that makes no difference, makes no difference.
It just seems weird to me....
This post brought to you by ๆ (U+0e46, a.k.a. THAI CHARACTER MAIYAMOK)
Nothing technical in this post, though I have been getting generally positive feedback on these sorts of pieces as I've been writing them.
I headed to the rental office on Saturday morning from my apartment.
I had a package due yesterday that I wanted to pick up.
It was being sent via DHL and their estimated arrival dates had been sheer fiction of late. But on the other hand their drivers had not been leaving signs on the door either. It was sunny, I figured a trip over wouldn't hurt.
The girl spied me on the way over, saying nothing. I passed by at roughly five miles an hour, with what I hope was a friendly smile.
But then again I have smile issues. I even have proof, pictures of me at a wedding,standing next to someone who looks like a model, with a smile on my face that suggests I am not all there.
Hopefully I didn't scare her, she looked to be no more than ten.
Okay, no time to worry about that. I have absolutely nothing to do today other than avoiding a bunch of stuff so I can do it on Sunday.
When I made it to the rental office, the package was not there.
Sigh.
Okay, I did have some mail, most of which went into recycle.
Back to the apartment.
On the way back, the ten year old signals me to stop and introduces herself.
"I'm Fiona," she says, and I wonder if her parents were Fiona Apple fans. Probably not worth asking.
"I'm Michael," I tell her.
"Why are you riding that?" she asks me, "I just wondered." Though she asked the question so anxiously that it almost is like she had been summoning up the courage since she first saw me pass ten minutes prior. Her face is a little flushed, it occurs to me that she might be embarrassed.
I decide the actual answer might be a bit much, so I go with an easier version.
"It's my scooter. I fall down when I have to walk long distances, and this way I won't fall down."
She thinks for a moment and suggests something. "If you aren't walking around any more, how do you know you still fall when you walk around?"
"That's a good question," I say. And she smiles. One gets the feeling she is enjoying having an adult conversation because everyone talks to her like she is a ten year old and she is looking for something better. "I don't use the scooter in my apartment, so I can watch myself fall there," I continue, "but I do fall less often than I used to."
"So you are getting better?" she asks.
"Well, not so much. It is actually a little bit worse now."
She looks at me curiously, and if this were a cartoon there would be a huge question mark on her head, so I explain.
"I used to fall a lot, and I was really good at it since I did it so often. But now that I fall less often it surprises me and I am more likely to hurt myself accidentally."
A look of momentary confusion, followed by a look of understanding.
She has something on her mind, but seems unsure whether to continue. I smile, hoping it is warm enough and not scary. I really have to work on the smile thing. Truly.
"My mom has lupus air-my-toe-sis," she then says sounding out the word clearly unfamiliar to her. "They think I can't understand so they just say she has joint trouble. But I've overheard them."
"She falls too, sometimes," Fiona confides. "Maybe she should get one of these carts, I mean scooters, like yours."
"Well, lupus erythematosus can wear a person down," I agree, acting like I am not correcting her pronunciation because that used to annoy me to no end when I was ten -- I'd decided talk to her like she was an adult since that's what I wanted, even when I was being childish.
I think for a moment, then continue "I have multiple sclerosis, which is a little like lupus erythematosus but also very different. Maybe a scooter would be useful if she is having trouble getting around."
I pull out my wallet, find no card. But then I do notice there is a business card in the front basket, and even a pen. I write my home number and apartment number on the back, realizing I might be inviting an angry parent to come yell at me for accosting their daughter who is a little over ¼ of my age. Well, I think I am on safe ground here, so I decide it is not a bad risk. One or both of them probably work at Microsoft, so maybe this will help quell fears a bit.
"I don't sell the scooters or anything, but I can talk about them, at least."
"Thanks!" she beams."I'll give this to her" holding the card like it was a fifty dollar bill that she did not want to lose.
She continues, "I have to go now. I just wanted to ask you about the scooter."
I do a small bow from my seated position. "It was nice meeting you, Fiona," I say with a bit of formality. I didn't kiss her hand or anything but clearly I treated the meeting as worth the time, and she looks happy about that.
"It was nice meeting you too," she says, trying to match what I said though I doubt she even realized why she made the effort.
"And I hope you get used to falling less!" she exclaims as she starts to back away, still facing me and blushing more as she said the words. She suddenly decides to turn around and head home, probably almost not hearing my closing "thank you!".
Probably one of the more interesting conversations I have had this week, if not the most interesting then at least in the top five (the other four in no particular order have been with Raymond/Brad, Cathy, a VP named Julie, and Maryam -- and the next five come into my mind as well so the other folks who have conversed with me don't have to feel like they are being judged poorly!).
And this one with Fiona definitely seemed worthy of a blog post, at least. :-)
This post brought to you by ፲ (U+1372, a.k.a. ETHIOPIC NUMBER TEN)
Our story thus far:
It started when I mentioned that my Dell laptops have a new neighbor, who says hello. A new MacBook Pro that I was going to use for my world outside of Microsoft.
I was naive enough to think that would stick, and because of that it did for a little over a week....
But a bug report kind of sucked me back into it, and begat a large bunch of bug reports and a reminder statement on supportability of keyboard layouts (in Boot Camp 1.3 and MSKLC (also 1.3) -- excitement, enjoyment, and a wrinkle or three).
I skipped the step where I talked about what I did for the configuration....
Well, I started by making sure I had installed all of the latest updates.
Then I installed Boot Camp 1.3.
Like Brian, I was concerned about the lack of 64-bit drivers, but I wanted to have some fun too. So I did one less than recommend step -- I made my Windows partition to be 79gb so I would be able to recognize it later, and then when I ran Windows setup I deleted the partition and created two new partitions in the space formerly occupied by that 79gb.
(I booted into the Mac partition to be sure I hadn't hosed it!)
I then installed 32-bit Vista and all of the updates in one partition.
And then I installed 64-bit Vista. As people reported, there are a bunch of missing drivers (including the network driver and the wireless -- which makes installing updates much more complicated!).
Ok, back up and boot into 32-bit Vista, look to see that the network driver is apparently the Marvell Yukon 88E8058 PCI-E Gigabit Ethernet Controller, and it was pretty easy to find the 64-bit driver. Downloaded it, put it the 64-bit install's driver right in my desktop folder, and then booted back into the 64-bit Vista.
From there I just installed the driver. Once it was there I got all of the updates (and windows Update offered me the driver for the Wireless and lots of other goodies including Bluetooth. In fact, aside from the Apple keyboard layouts bring broken on 64-bit (not important to me since I didn't need them and they are broken on 32-bit Vista anyway!), 64-bit Vista on an Intel MacBook Pro via Boot Camp seems to work quite well!
And I get about 3.98gb of RAM, with 3gb on Vista 32-bit, of course -- which means RAM is about ¼ gb worse in Vista 32 but ¾ gb better in Vista 64. On the whole, much better than Dell's story, at the moment. :-)
After I installed all of the updates and rebooted, I ran that Windows Experience Index and got a 4.8:
0.1 better than that Dell Precision M90! :-)
In fact, the only thing missing is a Smart Card reader (which I would need for a RAS story, for both x86 and x64 Vista). But there is no huge hurry there, and with all of the spare USB ports on this thing I'm not worried. The light weight makes it appealing for travel.
This post brought to you by D (U+0044, a.k.a. LATIN CAPITAL LETTER D)
It was just a few days ago that I talked about how my Dell laptops have a new neighbor, who says hello, and I foolishly claimed I would not be going the Boot Camp/Vista route with it.
I only made it a few days before I ended up installing Boot Camp and Vista (both 32-bit and 64-bit, more on this soon!).
In my defense, I did it after I heard back about the problem I reported yesterday in Report of blank previews of unknown etiology.
Turns out this is a Boot Camp bug (at least in 1.3, maybe in other versions), and an unsupported Windows configuration involving MSKLC keyboard layouts being installed somewhere other than the system32 directory!
They add a bunch of keyboards that you can see right in the user interface:
and then if you look at the previews, you get the reported behavior:
Bummer.
Now if you look in the registry, you'll see where these keyboards are listed:
(note that this is the install on the 64-bit machine, which is broken for the additional reason that we will get to shortly but is also broken in the 32-bit version)
The keyboard DLL not being in the appropriate %windir% directory is the reason that the keyboard is not showing up in the preview -- it is failing to load.
Looking at the properties of the file:
This is clearly an MSKLC 1.3 DLL (we changed the property name to fit into one of the known Vista properties in 1.4), and as I mentioned the 32-bit version has many problems loading as well as the additional known problems with 1.3 on 64bit that made my experience above even less likely to work....
Now as a rule, Microsoft doesn't support keyboard layouts that are created with MSKLC but not installed with its setup package.
But assuming Apple did their due diligence and grabbed all of the settings and put them in their image, then the existing problems are:
1) They should be installing to the system32 directory (and the syswow64 directory for wow64 on x64), and
2) They should be using MSKLC 1.4 so they can pick up 64-bit support and better Vista support overall.
But keep in mind that Boot Camp 1.4 is still in beta and I am technically a beta tester of it, so you can consider this to be a bug report! :-)
Now, if you fix problem #1 above, then (as Olivier indicates), all of the problems on 32-bit will be resolved, and the 64-bit can be resolved as above (like many other people, I am assuming 64-bit issues will eventually be resolved!).
Despite the flaws I think this is a really cool usage of MSKLC and once they fix up the specific issues here I think that this is the kind of usage of MSKLC that really could put the number of tool downloads to shame when compared against the number of MSKLC keyboards.
So it's like a little piece of work that I was involved with be on a bunch of Macs, too. I am excited!
If anyone from Apple wants more info on this issue then they can of course contact me here. I'll be around and eager to help make sure that that the Mac/Vista story works well....
(special thanks to Olivier and David Tickle for their hints that helped encourage me to take a closer look!)
This post brought to you by ඉ (U+0d89, a.k.a. SINHALA LETTER IYANNA)
Francisco Moraes asks in the Suggestion Box:
Mike,Is it possible on MS SQL Server to have columns defined as CHAR (or VARCHAR) and actually store the data in UTF-8 without corruption due to code page convertions? I know there is the NCHAR/NVARCHAR type but we'd like to avoid the 2-bytes per character used to store them.Francisco
This is actually quite a common request but the answer is not one that will make Francisco happy -- there isn't such a way.
UTF-16 via the "N" data types is really the only way things will work here.
I will forward the feedback on to folks on the SQL Server team (or they might just read about the request here since I think some of them are regulars now!), though it is worth pointing some things out:
First of all, for pure ASCII text, UTF-8 will always be smaller, but for any other text in Unicode it will be the same size or bigger, which really hurts the size argument.
I discuss this point a bit in You may want to rethink your choice of UTF, #1 (if the size matters), and I gave the distribution:
The above is imperfect since it includes unassigned code values and it also includes high/low surrogates in the three byte group when they are not legal there, but you get the point that UTF-8 is not much of a space saver unless you stay in ASCII, and if you do stay in ASCII then any old code page would work....
Second of all, even if there were a way to make UTF-8 text work, it would not be free since the underlying engine and collation tables use UTF-16 for Unicode, there would be an associated performance hit due to the conversions. Now conversion is optimized as much as it can be, but it is still a non-zero cost.
And finally, though we do not change code pages, there have really on a regular basis been updates to UTF-8 to conform to the latest Unicode Standard guidelines around conformant UTF-8 conversion, which means that if such a feature existed there would be worries about index corruption if faulty, non-conformant UTF-8 was being stored. This would have to be a real concern, enough to make sure that invalid data was never stored in the database (suggesting a validation pass, which means additional work that would have to happen).
This post brought to you by ! (U+ff01, a.k.a. FULLWIDTH EXCLAMATION MARK)
Over in the Suggestion Box, Olivier asked:
We created Keyboard layouts for our own specific keyboards, and on Windows Vista when we look at the Keyboard Layout Preview in the Add Input language dialog, the preview is mostly empty (only tab, Caps, Shift, Enter and BackSp keys show up). Is it because the keyboard layouts are custom and define extra keys??Thanks for any suggestion or help.Olivier
That preview dialog is one I have talked about before, if you will recall (just this last March in The T's are crossed, but not all of the I's are dotted...).
In that post I actually described how the preview get its data:
...the same info that feeds the GetKeyNameText function, which itself depends on the data that feeds the MapVirtualKeyEx function. In fact, when dealing with the function itself GetKeyNameText calls MapVirtualKeyEx twice: First with the MAPVK_VSC_TO_VK flag, mapping the scan code to a virtual key on the given keyboard Second with the MAPVK_VK_TO_CHAR flag, mapping the virtual key to a character
...the same info that feeds the GetKeyNameText function, which itself depends on the data that feeds the MapVirtualKeyEx function. In fact, when dealing with the function itself GetKeyNameText calls MapVirtualKeyEx twice:
Interestingly enough (as I pointed out in that post), ignoring the odd bug the data it gets back is probably better than the more complex things pulled out by MSKLC. But then that preview's needs are different, so no shame in being better at its own needs!
In the particular case of Olivier's question, I am not sure what might be happening. The keys that work are of course ones that it populates from its own resources, but I don't know of a reason that the created keyboards would not have their keys showing....
I then had a chilling thought. Could it be a keyboard based on a custom culture created in MSKLC 1.4? Due to that strange LCID? Yikes, I hope not!
Okay, just tested that scenario out and everything worked.
Whew! That would have been pretty ugly if MSKLC were to break GetKeyNameText.
On the other hand, MSKLC was not explicitly mentioned so perhaps I am being paranoid. :-)
I guess I'll need some more details from Olivier at this point -- like the keyboard that repros the problem, or at least more details on how it was created.
Or is anyone else seeing this problem?
This post brought to you by ៘ (U+17d8, a.k.a. KHMER SIGN BEYYAL)