Re: Need help with CABWIZ

it's a limitation on the way that CABWIZ stores it's data - it's single byte characters, so there's no way it can store a multi-byte glyph.

OK. I thought your previous posting said that CAB files couldn't contain multibyte glyphs. Yes this rewording makes a big difference.

Yes, CABWIZ's inability to produce valid CAB files is a defect in CABWIZ. CABWIZ isn't the only defective component of the Japanese version of Visual Studio 2005, it's just the part that I needed help with in this thread.

It's a design flaw, not a bug,

Now I'm confused again. If CABWIZ's bug is in its design instead of its coding, the bug is still a bug.

trying to belittle me by creating an installation isn't productive

I wasn't trying to belittle you. Your previous posting sure looked like you said you reverse-engineered the format of a CAB file not the execution of CABWIZ, and it sure looked like you said a CAB file couldn't contain multbyte filenames. I thought an example would improve your reverse-engineering effort on the format of a CAB file. If we're going to argue about belittling, then revisit your own statement "having Unicode doesn't simply give you Japanese glyph support". What kind of education do you think this provided to a user of Japanese Windows XP (hosting the compiler), Japanese Visual Studio 2005, and physical Japanese Pocket PC running Japanese Windows CE 5?

What's germane to to the question is that CE doesn't use ANSI codepages at all

Except sometimes (such as GetAdaptersInfo). I still have to call MultiByteToWideChar and WideCharToMultibyte more often than should be necessary.

There's nothing that guarantees codepage 932 compliance.

Yeah I know, there's no guarantee, and CABWIZ isn't the only part of a Microsoft Japanese product that can't conform to Microsoft's Japanese.

We all know that cabwiz and wceload are dated

If wceload is part of the problem, then I guess there is no correct way to use CAB files to deliver applications to a Japanese Pocket PC. The installer must be a custom-coded EXE.


"<ctacke/>" <ctacke[@]opennetcf[dot]com> wrote in message news:uRukrhktGHA.4848@xxxxxxxxxxxxxxxxxxxxxxx
Don't get yourself tied in a knot. I agreed that it can't do it, and it's a limitation on the way that CABWIZ stores it's data - it's single byte characters, so there's no way it can store a multi-byte glyph. It's a design flaw, not a bug, and trying to belittle me by creating an installation isn't productive - I've made them before and if you think you're "instructing" me on anything you're off-base.

The limitation also has nothing to do with Studio or CE. The Studio team didn't write it. The CE team didn't write it. Sure they're both consumers, but that's like saying that if you ship an MFC app and MFC has a bug, then it's your fault. Just becasue they're both from Microsoft doesn't mean that the people working on it were in the same room.

ANSI codepage 932 also is a red herring. I don't care that you know all about ANSI codepages, or how long Microsoft has been using them. What's germane to to the question is that CE doesn't use ANSI codepages at all, it uses Unicode. wceload unpacks the CAB file and does a simple conversion, probably using MultiByteToWideChar, but it could even be something simpler. There's nothing that guarantees codepage 932 compliance.

As for the statement on glyphs, you said "...Unicode which includes Japanese characters..." and I was clarifying that. Unicode is highly misunderstood by many, and if someone reads that, they will be inclided to think that since CE is Unicode, they magically get Japanese glyphs with it. That is definitely not the case.

We all know that cabwiz and wceload are dated and have many limitaions that aren't fun to work around and we probably all agree that it needs replacement.

-Chris

"Norman Diamond" <ndiamond@xxxxxxxxxxxxxxxx> wrote in message news:evanH5etGHA.4872@xxxxxxxxxxxxxxxxxxxxxxx
"having Unicode doesn't simply give you Japanese glyph support"

So what? Even if you're not sure whether the Japanese versions of Windows Mobile 5 (on the physical device) and Windows XP (hosting the compiler) and Visual Studio 2005 (the compiler) give me Japanese glyph support or not, I already quoted some of the registry keys in the device and provided a screenshot. In fact even the Japanese version of Remote Registry Editor has Japanese glyphs, look at the title bar and menu bar in the screenshot. And look at how it designates the default value of a registry key.

"CABWIZ is a tool separate from it"

Separate from the Japanese version of Windows Mobile 5, sure. Separate from the Japanese version of Visual Studio 2005, well not quite.

Meanwhile multibyte characters are ANSI. ANSI code page 932 has been used by Microsoft in this country for more than 20 years. ANSI code pages with other numbers are used by Microsoft in the world's most populous country and some others. CABWIZ is pretty badly messed up when it can't cope with Microsoft's Windows systems and the other components of Microsoft's Visual Studio 2005.

Meanwhile I agree that CAB files can contain ANSI characters. Here, I created one for you:
http://www.geocities.jp/hitotsubishi/ctacke.cab
Of course you'll want to use an antivirus checker to be sure to be safe, but the only contents are a zero-length plain text file named for part of Microsoft's address:
東京都渋谷区代々木.txt


"<ctacke/>" <ctacke[@]opennetcf[dot]com> wrote in message news:%23ZeIVndtGHA.4872@xxxxxxxxxxxxxxxxxxxxxxx
Just a slight clarification - Unicode doesn't simply include Japanese characters - it can support them, but having Unicode doesn't simply give you Japanese glyph support (and CE is more correctly UTF16). CE handles Unicode just fine - in fact that's all it handles. CABWIZ is a tool separate from it, and while it's disappointing such an error would occur, it's not due to CE - it's in the CAB generation that it's failing. The CAB spec isn't published, but I've doen a fair bit of reverse engineering on it, and based on what I've seen, it doesn't have provision for non ANSI characters, as the descriptor record in the archive is all ANSI and it wouldn't know how to handle a multi-byte character.

-Chris



"Norman Diamond" <ndiamond@xxxxxxxxxxxxxxxx> wrote in message news:%23I3j$ZctGHA.3552@xxxxxxxxxxxxxxxxxxxxxxx
Actually the problem is that it doesn't handle its own language's characters at all, either in ANSI or in Unicode. Microsoft has been selling MS-DOS and Windows systems using ANSI code page 932 (Shift-JIS) for more than 20 years, they've been selling Windows CE and Windows Mobile using Unicode which includes Japanese characters, and now they're selling the Japanese version of Visual Studio 2005 which can't cope with their operating systems.


"The PocketTV Team" <support@xxxxxxxxxxxx> wrote in message news:OrNrjlVtGHA.1224@xxxxxxxxxxxxxxxxxxxxxxx
wow, good find!

i didn't know CABWIZ couldn't handle non-ANSI characters in registry keys or value names.

that's pretty lame...

"Norman Diamond" <ndiamond@xxxxxxxxxxxxxxxx> wrote in message news:%23AoTBqStGHA.4080@xxxxxxxxxxxxxxxxxxxxxxx
"Norman Diamond" <ndiamond@xxxxxxxxxxxxxxxx> wrote in message news:eXZhRnStGHA.4748@xxxxxxxxxxxxxxxxxxxxxxx

Screenshot at htp://www.geocities.jp/hitotsubishi/wm5_registry.png )

Should be http://www.geocities.jp/hitotsubishi/wm5_registry.png

OK I need help typing too, but mostly I need help with CABWIZ for the reason described. I don't care about the quotation marks, I just need the key names to work. By the way I experimented with deleting the quotation marks too but the result still just damaged the device's registry.









.

Relevant Pages

  • Re: unicode cab?
    ... Cab files can work with multibyte characters in any ANSI code page but they don't say which code page it is. ... So for example, if your filenames use Japanese characters, you can put them in a cab file under Japanese Windows XP and unpack the cab file on a Japanese Pocket PC. ...
    (microsoft.public.pocketpc.developer)
  • [sljfaq] Japanese lettering page added
    ... In the same way that there are various ways of writing English, ... Japanese has many different ways of being ... traditional square style of characters, with horizontal lines slanting upwards going from left to right. ...
    (sci.lang.japan)
  • Re: Quest for the book detectives...
    ... I was too run-down with a cold to see my Japanese language mentor today ... Chinese, not Japanese. ... Note that the characters chose 'power' 'warrior' is masculine in its ... Who "Felix" might be is a complete mystery, ...
    (rec.collecting.books)
  • Re: Characters not being displayed when language settings are changed.
    ... As for the original question - if changing the language for non-unicode programs affects the way you see things, the program you're using must be a non-Unicode program. ... As such it will be using a code page to display non-ascii characters, and changing the language will have changed the code page in use - I think! ... But I think that MS Mincho is installed with Office/Windows by default because there are certain characters in that font that Word uses even when you think you're entering something in the Default Paragraph Font. ... Japanese IME? ...
    (microsoft.public.word.docmanagement)
  • Re: Problem Displaying Japanese Characters
    ... Probably a problem with the way the HiT driver handles DBCS characters. ... > Server Query Analyzer to display Japanese Characters fetched through a linked ... > linked server on SQL Server B linking to SQL Server A. Change the font type ... > table on the AS400 using the HiT OLEDB provider. ...
    (microsoft.public.sqlserver.tools)