Re: [vwnc] [VW7.6] [BUG]windows folder with international characters (utf-8)

I wonder if loading allencodings parcel would have an effect there,

Cheers!

-Boris (via BlackBerry)

----- Original Message -----
From: [hidden email] <[hidden email]>
To: VWNC <[hidden email]>
Sent: Tue Jul 15 10:16:31 2008
Subject: [vwnc] [VW7.6] [BUG]windows folder with international characters (utf-8)

Hello all,

I came across interesting bug.
I have created a window folder with using non English (looks like utf8)
characters such as:
C:\test\Маштаков.


most of the windows application  can read and write to it.

However the the VW from 7.3 to the latest 7.6 does not even recognize it
as a folder.  When I try to save something there( for example from
workspace I do get an error like:
Unhandled exception: ERROR_INVALID_NAME ("c:\test\????????\Page 1.ws").

Here is a question to the smalltalkers outside the US -- how do you work
with the non ASCII based file names in general ?

Any help is greatly appreciated

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

I am not sure... It looks like Unicode filenames are not supported on
Windows. So we are out of luck on that one.  I am interested to hear how
people from eastern Europe are dealing with it.
   Here is a quote form the latest release notes:

UTF-8 File and Directory name encoding

It is increasingly common that operating systems use UTF-8 for the
encoding of file and directory names in the file system. Previous
releases would not handle this correctly. In the case of Unix and Linux
systems, this had to do with the presence of Locales. The current Locale
class combines a country/language and an encoding. e.g.,
en_US.iso-8859-1. There were no encodings using UTF-8, and if no
matching encoding was found, it would fall back to the default "C"
encoding, which used ISO-8859-1. If this didn't match the filesystem,
then using characters outside the basic ASCII range could fail.
This issue has been resolved by adding .UTF-8 locales for all existing
locales in the system. For operating systems where we haven't defined a
locale, adding an appropriate one will make it use the filesystem
correctly. A longer-term solution is to separate the encoding from the
country/language.

For MacOSX, the file system is always in a particular form of UTF-8, in
which accented characters are decomposed. In this case we simply need to
hard-code the MacOSXFilename to use this encoding consistently.
In both of these cases, the fix can be made entirely at the image level.

For MS-Windows, the fix to support "unicode" characters in file and
directory names will require VM changes, and is not yet available.

Boris Popov wrote: _______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

The underlying issue is that on Windows you can use APIs that are either narrow or wide. Narrow means in the code page that the Windows version is natively using, wide means UTF-16. Currently the VM uses the narrow ones, and we are switching it over to use UTF-16. The AllEncodings parcel would get you some of the way there. For Eastern European users right now it would work fine, if they are using versions of Windows built for that locale. The problem is just when you try to use characters outside that range.

By in the process of, I mean that people in vw-dev can expect to see a version of that in the next few weeks.

At 02:03 PM 7/15/2008, Boris Popov wrote:

Content-Class: urn:content-classes:message
Content-Type: multipart/alternative;
         boundary="----_=_NextPart_001_01C8E6A5.1499374D"

I wonder if loading allencodings parcel would have an effect there,

Cheers!

-Boris (via BlackBerry)

----- Original Message -----
From: [hidden email] <[hidden email]>
To: VWNC <[hidden email]>
Sent: Tue Jul 15 10:16:31 2008
Subject: [vwnc] [VW7.6] [BUG]windows folder with international characters (utf-8)

Hello all,

I came across interesting bug.
I have created a window folder with using non English (looks like utf8)
characters such as:
C:\test\Маштаков.


most of the windows application  can read and write to it.

However the the VW from 7.3 to the latest 7.6 does not even recognize it
as a folder.  When I try to save something there( for example from
workspace I do get an error like:
Unhandled exception: ERROR_INVALID_NAME ("c:\test\????????\Page 1.ws").

Here is a question to the smalltalkers outside the US -- how do you work
with the non ASCII based file names in general ?

Any help is greatly appreciated

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

> The underlying issue is that on Windows you can use APIs that are either narrow or wide. Narrow means in the code page that the Windows version is natively using, wide means UTF-16. Currently the VM uses the narrow ones, and we are switching it over to use UTF-16. The AllEncodings parcel would get you some of the way there. For Eastern European users right now it would work fine, if they are using versions of Windows built for that locale. The problem is just when you try to use characters outside that range.

just out of curiosity: I thought this had to be changed already for
Windows CE / Mobile, which only provides the wide string API versions
for most functions?

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

At 08:01 AM 7/17/2008, Holger Kleinsorgen wrote:

> The underlying issue is that on Windows you can use APIs that are either narrow or wide. Narrow means in the code page that the Windows version is natively using, wide means UTF-16. Currently the VM uses the narrow ones, and we are switching it over to use UTF-16. The AllEncodings parcel would get you some of the way there. For Eastern European users right now it would work fine, if they are using versions of Windows built for that locale. The problem is just when you try to use characters outside that range.

just out of curiosity: I thought this had to be changed already for
Windows CE / Mobile, which only provides the wide string API versions
for most functions?

It was, but this wasn't adopted in the regular Windows VMs, and I believe that some things have also changed from the way it was done for CE.



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc