cp950 this was, not 930

Ross and Steven and Wallace, do any of you have a Chinese windows image handy?  If not, do you still have the MSDN download info to create one?

Hi, Chris,

I have a Chinese XP CD at home.  I do not have the Japanese one.

Let's download them.

I am emailing you about the MSDN account info.

Thanks
Wallace

Is it traditional Chinese or Simplified Chinese?  Is it real double byte OSes or English XP with double byte support?

If it is failing on both Chinese and Japanese, it could be an issue for double byte XP.  It may be a good idea to check Korean too, if it is supported by SlimServer.

According to this Microsoft web page,

http://www.microsoft.com/globaldev/reference/oslocversion.mspx

here's the breakdown of code pages for Japanese and Chinese Windows:

Chinese Windows XP (Taiwan & Traditional) / Vista (Taiwan & Hong Kong SAR): code page 950
Chinese Windows XP (Simplified)/ Vista (PRC): code page 936
Japanese Windows XP / Vista: code page 932

The guys reporting bugs didn't say Korean, which code page 949.

The easy assumption is that all of these currently don't work, and any fix could possibly fix all of them.

I would suggest testing all of them whenever any fix is created.

Since the original bug had a code page 950 and 932 issues, we can assume the users were some version of Chinese Windows with traditional character set and Japanese Windows.

I just finished downloading and installing SS 6.5.3 on Traditional Chinese Windows XP SP2 and I get the same "Unknown encoding: cp950" error.

Is this possibly the result of updating ActiveState on the build machine?  Any other ideas?

I fear so, because I couldn't find any change in the relevant parts of the server. I asked about it in the ActiveState forums, but didn't get an answer so far. Do we have some support plan with them?

Somebody (Dean, Andy?) could probably try to build a version with the PDK6 to doublecheck.

I just finished installing SVN on Traditional Chinese Windows XP SP2 using the instructions on the Wiki and it seems to run just fine.  Sounds like the new build code may in fact be the problem.

SlimServer Version: 6.5.4 - TRUNK - Windows XP - EN - cp950
Server IP address: 10.0.3.20
Perl Version: 5.8.8 MSWin32-x86-multi-thread
MySQL Version: 5.0.22-community-nt 

I've got a first feedback from ActiveState's support. They're asking for a minimalistic program to reproduce the case. To whom could I send an executable to test on that chinese/japanes system? Or could the VM be made available for download somewhere so I could run the tests over here?

Michael: I'll see if one of the guys here can help you with getting you access to Chinese or Japanese Windows in one form or another. Of course, don't you have MSDN access by now? If so, you can download that stuff, too.

You are familiar with one of those languages, aren't you? 8^)

Dean has ordered MSDN, but I haven't the details yet. And now that I'm fluent in Hebrew, it will be easy to learn Chinese ;-).

BTW: VMware Fusion (Mac) does a great job installing Windows without user input. This should allow me to install without knowing "Regional settings" in Chinese (that's _not_ in lesson one of "Chinese for Dummies").

Created attachment 2072 [details]
test executable to crash perl (PDK7  build)

Do you see the "Hooray" message when running this mini application on your Chinese system in a command window or does it crash?

I see "Hoooray! I survived!" when I run crasher both with and without ActiveState perl installed on Traditional Chinese
Windows.  What does it mean?

That means that my test case was too simple :-(. Thanks. I'm downloading a chinese copy of Windows right now, so I can test myself.

What a shame: I didn't read the release notes carefully enough. Our crasher is closely related to the smaller executable files. PDK7 simply doesn't bundle the necessary files any more to gain some memory. Here's the answer from Activestate's support (which was very responsive, btw):

PDK 7 no longer bundles Encode::CN, Encode::JP, Encode::KR or Encode::TW by
default every time it sees that Encode is being used.  This saves over 2MB
in the generated executable.
 
You can explicitly add them with either --add Encode::CN etc, or add some
block to the program like this:
 
    if (0) { # Tell PerlApp to bundle these modules
        require Encode::CN;
        require Encode::JP;
        # ...
    }

-------------

If nobody has done it when I'm back, I'll give it a try later tonight. Adding the necessary modules should be pretty straight forward.

Created attachment 2073 [details]
Fix for the crasher

This patch against 6.5.x branch should fix the crasher (it did on my machine).

Michael, will this change make it into the nightly?

I've checked it in to 6.5.x (12428) and trunk (12429). It will be in tomorrow's build. Let's give it some exposure. I'll ask the guys in the thread to update their installation and give feedback.

Installed last night's build and it's running successfully on my Chinese system. Please reopen if there are any further problems with this issue.

Works for me too, thanks!

This bug has been fixed in the latest release of SqueezeCenter!

Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already.  

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.