Home > Microsoft, Windows Vista > Vista SP2 and language packs

Vista SP2 and language packs

Tonight I went ahead and tried to install SP2 for Vista is the hopes that it would cure my Windows Media Player problem. No dice. Apparently, I need one that supports the 34 languages that I don’t have installed. Why? Because at one point I did install them, then uninstalled them, and now, SP2 thinks they are still installed. Huh?

J.Ja

Categories: Microsoft, Windows Vista Tags:
  1. May 12th, 2009 at 05:07 | #1

    It turns out that there is a *separate* place for languages; simply uninstalling the updates that came with Windows Update are not enough, you need to go to Control Panel->Clock, Language, and Region->Install of uninstall display languages

    What a mess. This explains a lot, actually. I’ve had in the past errors caused by these language packs that I wish I had never installed.

    J.Ja

  2. May 12th, 2009 at 16:15 | #2

    $sudo apt-get remove|purge //debian
    $sudo rpm -e
    //redhat package manager

    Is having to remember to go to more than one panel to do an uninstall ‘good design’?

  3. May 12th, 2009 at 16:21 | #3

    I have no clue what happened here. I suspect that there are two components here, in that by installing the language *update* it also installed the base languages, so when I uninstalled the *updates*, it still left the actual base languages behind. It makes a peculiar kind of sense, but it is obnoxious nonetheless. I will say, though, this is the only case I’ve seen of this.

    More annoying, is that the language uninstall, while it allows multiple languages to be selected, does not actually remove more than one at a time, and it takes roughly 20 minutes to remove each language, so you need to keep an eye on it and keep coming back to select the next one. Slightly less inconveniently, each language you install requires you to re-launch the uninstall system.

    J.Ja

  4. May 12th, 2009 at 23:11 | #4

    Maybe this is an example where a script witten in PowerShell that would iterate in a for loop across an object would be applicable, yes?

  5. May 12th, 2009 at 23:14 | #5

    Probably a good idea. I briefly considered that as well, but I figured it would probably take more effort to hunt down the needed information than it would to occassionally check in and start the next uninstall.

    J.Ja

  6. May 13th, 2009 at 00:02 | #6

    Well, W7 is heavily vested in PowerShell, so I understand. It would be interesting to see what you can put together for ‘practical uses’ now and then so Admins can get a feel for its potential and where it fits in.

    Get crackin’ those books! ;)

  7. May 13th, 2009 at 00:25 | #7

    PowerShell is on my list of things to learn this year. W2008 and the products that started coming out with "version years" of 2007 and later are all PowerShell. Their GUIs don’t even make calls anymore, they just populate PS scripts with user input and run them. It’s amazing. In 2 years, Windows suddenly reminds me of UNIX, if UNIX was done all at once by a single group of highly coordinated people, and in a post-OO era.

    In other words, I am a HUGE fan of PS, even though I don’t use it "for real" yet.

    J.Ja

  8. May 13th, 2009 at 11:16 | #8

    An interesting question comes to mind:

    Can a W7 or WS 2008 Administrator peform all system support functions strictly from a command line terminal interface (no GUI interaction)?

    If not, that’s what sets Linux, BSDs,Unix apart which CAN do so! And that is why the number of machines that a Linux Admin can support is higher relative to Windows Admins.

  9. May 13th, 2009 at 14:48 | #9

    Yes, WS2008 can be installed as "Server Core" (without a GUI) and be managed 100% via PowerShell. While I doubt that W7 has a "headless" mode like that, since it shares the core OS with WS2008 R2, I’d say that it too can be managed 100% via PS. Of course, not every app will expose stuff to PS, of course, but for *system administration*, it looks like PS can do it all, especially since it can tap into the WMI subsystem too.

    It’s odd, I have really used PS much (other than the bare minimum to accomplish a few tasks), but I *really* respect it. Unlike the *Nix CLI, what the output physically looks like is irrelevant to what happens when you pipe it around, because its passing objects, not text/data streams. That’s a big, big difference. It’s nice to reformat the output by requesting that a particular *property* be displayed, rather than writing something to pass to awk/sed/perl. :)

    J.Ja

  10. May 13th, 2009 at 16:37 | #10

    The ‘everything is a FILE’ and textual nature has is ‘pros’ once you grasp that you can pipeline stdout to stdin–a very efficient, powerful command-line/scripting feature, but it’s not just text.

    You have bindings for all manor of UIs, libs, modules, objects, classes, databases, etc., using Perl, Python, Ruby. So, one might think of PowerShell as being a Bash/Scripting Language ‘hybrid’, of sorts. Bash, by itself doesn’t have that rich functionality, but seasoned with Perl, awk, sed is almost limitless in capability.

    My money is on Perl vs the other Dynamic languages–it has proven to do the ‘heavy lifting’ when called upon. With Perl, you can stop using awk and sed. Live with it and you’ll realize you can stop using Bash as well.

    Ultimately, everything resolves to a file in Linux which is, I feel, superior to registry-based systems. Some things like rpm/deb do get stored to a db using Berkley db or sqllite but things don’t get nearly as fubar like Windows’ registry. You can’t necessarily be certain that upon uninstall Windows has reverted 100% to its previous state–the only 100% way to be sure is to bring back a ‘restore point’. Restore point by itself is a really nice feature I wish was standard in Linux.

  11. May 13th, 2009 at 18:10 | #11

    Oh, I "get" *Nix pipes… that’s why I like PS so much, because it works the same way. The major difference is, with *Nix it seems like so much effort is spent on wrangling with the output or input to make two disparate applications pipe nicely with each other. With PS you just don’t have that, because they operate on object information.

    I agree that "everything is a file" has a lot of advantages. I think that on Windows, the registry is quickly fading in importance, especially since so many apps are being done in .Net at this point which makes file-based configuration much easier and smarter than registry.

    J.Ja

  1. No trackbacks yet.