I believe that to support different file name character sets we're  
going to need to alter sqVirtualMachine.c
and take  VM_PROXY_MINOR to 6 by adding three new calls to support  
information about what the file name
encoding information is.

getVMEncodings returns Smalltalk OOPS Array of supported encodings  
which the VM supports.

getCurrentVMEncoding returns magic integer signifying the encoding  
being used.

setCurrentVMEncoding takes magic integer, returns 1 if set, zero if not  
a supported encoding.

where the magic integer is and I'll be platform independent and define  
them as:

MacRoman = 0,
WindowsLatin1 = 1, /* ANSI codepage 1252 */
ISOLatin1 = 2, /* ISO 8859-1 */
Unicode = 3
UTF8 = 4

This allows plugins, like the mpeg plugin to accept a file name from  
the VM and know what to do
with it before issuing the file open by asking the VM what the encoding  
is. It also of course allows
a programmer the ability to see and choose an encoding to use within  
the Image.

I'm also considering using a reserved header word in the image so we  
can determine what the image
encoding is at startup time because things like the VMPath are loaded  
early and we can better
ensure file name encoding is done correctly versus relying on some  
startup task stamping the
image with the encoding information.

What is unclear, but could be defined is how to deal with existing path  
information, such as the vmpath
once you switch encoding. I suppose you could leave that information in  
native platform format and
return a converted value  based on the currently chosen encoding.

Thoughts on this are welcome.


--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===