by Michael S. Kaplan, published on 2010/07/28 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/07/28/10043258.aspx
There have been a few updates on the Language Interface Pack front that I want to communicate out to all of you....
First and foremost, do you remember back in March, in my blog Thirteen (13) can be a lucky number?
That was the blog where I explained that there was a magic list of 13 languages that would see 64-bit LIPs created.
Well, due to the patient and persistence of some of the amazing folks just down the hall from me, and in part due to some of the feedback by regular readers here like Pavanaja U B that my colleagues were able to verify and use...
...All future Language Interface Packs will have both their 32-bit and 64-bit packages released!
Note that this only applies to the download center; I have had it communicated to me that our OEM partners (i.e. the Dells and HPs and all of the others) specifically do not want these 64-bit packages because they do not get enough requests to make it worth creating all of the additional images (apparently they most often ship the 32-bit versions of Windows even on 64-bit hardware, still).
This is something that may be a future cause to take up if there is enough interest that people have in being able to have full packages that support their preferred languages when they buy a new computer!
Now all of that (well, the first part of that) is the good news. :-)
The bad news is that the LIPs that have been released as 32-bit versions only will have to wait for a bit before the media verification can happen and their 64-bit counterparts can be released. They will be coming, but it will be a bit. If there were some other way it would happen sooner, but all of these work items are on a very tight schedule and the new work items can only be added when time can be found.
But I can report that everyone does want to see it happen and that it will eventually happen!
I promise that I will keep interested readers posted about this as more details become available. :-)
Don't forget that later today I'll be doing that all-encompassing "Bidi support on Windows" presentation for MS internal type folk!
If you are a full time Microsoft employee in Redmond who is interested, feel free to drop in....
John Cowan on 28 Jul 2010 7:45 AM:
"Future" would seem to be the operative word in red here. Does that mean that *existing* 32-bit LIPs will not have 64-bit versions? The world wonders.
Michael S. Kaplan on 28 Jul 2010 8:03 AM:
That question is answered in the blog... :-)
Pavanaja U B on 28 Jul 2010 9:17 AM:
Thanks for the update on the news. But I would prefer the actual update, ie, 64 bit LIP for Kannada and other Indic :)
Random832 on 28 Jul 2010 10:00 AM:
As a general question - what exactly is it about a LIP that makes it not "just data" that could be installed on either version of windows? or, even if it's in the form of resource DLLs or something, that could be compiled for both [and for itanium/powerpc/mips/alpha if those still existed] as a matter of course without needing separate verification on each one? Do these contain any actual code? I'm trying to think of what sort of bugs one could have that would only show up on one architecture.
In other words - it's great that this is fixed now, but what was the reason in the first place?
Karellen on 28 Jul 2010 1:58 PM:
OK, why do LIPs need to be architecture-specific? What's 32-bit (or 64-bit) specific about a language pack? (On the systems I work with, l10n packages are generally arch-independent.)
Michael S. Kaplan on 28 Jul 2010 5:16 PM:
They are resource DLLs, and thus follow all the rules about architecture-specific binaries....
Mihai on 29 Jul 2010 2:41 PM:
I think making a 64 bit dll vs. a 32 bit dll is trivial, can probably be automated in one day.
What is way more expensive and time consuming is all the QE, distribution, support, etc. that comes with it.
But this is where it would be nice to have the .rsrc section outside, as an architecture independent binary file.
If I would make the calls, I think the next improvement I would do in the Windows resource handling would be on the MUI story for developers outside MS, with an enforced language structure for folders and all. If your stuff is not in the "en" or "en-US" folder, things don't work. And (of course) architecture-independent resources.
You know, like Mac OS X?
:-)
Michael S. Kaplan on 29 Jul 2010 9:30 PM:
The files are already built. But Microsoft in general and Windows in particular as a matter of policy do not release anything without fully verifying the medias being released. Therefore, there is a process that must be followed. And the time must be found to do that for these existing LIPs....
referenced by