[ruby-talk:18366] Re: Unicode filenames and Ruby porting

Yukihiro Matsumoto wrote:

> |If someone were to port Ruby to Windows/CE, they would have a little
> |problem: Ruby seems to assume (from a quick glance at the source) that
> |filenames are made up of 1-byte characters (don't know what character set
> |it assumes). However, all file APIs in Windows/CE take and return Unicode
> |characters.
> 
> Hmm, I'd like to try CE port, if time/budget allows.  Any information,
> suggestion, etc. would be welcome.

I'd love to see a CE port (especially for HPC/Pro 2.11 versions!) Some info 
off the top of my head (some of this may be a bit dated):

* Development tools are free (Embedded Visual Toolkit 3.0) from Microsoft. 
You can produce multiple target versions easily with a single set of 
source. They support remote debugging if you have a serial connection or 
network connection with your CE device. But you have to run Windows 
(preferably some flavor of NT like NT4 or Win2000) to run the tools. There 
is an emulator you can try things out on.

* All APIs that take strings use 2-byte Unicode. There are some simple 
mapping routines available. All filenames are in Unicode, as are all 
registry values, etc. Text files produced by the internal text editor are 
likewise in Unicode; you'd probably want to make it so that Ruby source 
could be in Unicode.

* In the pocket PC versions, there is basically no stdlib. Also there is no 
stdin/stdout/stderr or console.

* In the HPC/Pro versions, there is a console, CMD.EXE, that can run 
external programs. There is I/O redirection syntax in CMD.EXE. There is 
also a limited stdlib included. This lacks a number of Unix features, and 
its support varies between versions of the HPC/Pro platform.

* Making a version of Ruby that would work across both the PocketPC 
versions and the HPC/Pro versions would require making some way to launch 
Ruby in the PocketPC environment, perhaps a mini-console of some kind. Or 
you could just specify registry settings for stdin, stdout, and stderr 
(connect them to files).

* There is a WINSOCK socket library available. However, there is no async 
socket support.

* There is a Python port to CE that you might be able to mine some stdlib 
replacements from. 

* There is a Perl port to CE that also did its own stdlib replacement. This 
author decided to make his own console, ignoring the one that comes with 
the HPC/Pro, so he could run on the Pocket PC devices. However, this 
doesn't seem to work too well on the HPC/Pro devices.

* CE supports multiple threads with the typical Win32 API.

* There is support for dynamically loaded code (.DLL)

* In general, assume no Unix-isms available. However, there is some C 
stdlib stuff there in some platforms (notably the HPC/Pro) (though this can 
be conditionally not compiled):

==== ANSI Stdin/Out functions
scanf printf vprintf getchar putchar gets puts fgetc fgets fputc fputs 
ungetc
fopen fscanf fprintf vfprintf

==== functions for general buffered file handling reqd by BOTH ANSI and Wide
_InitStdioLib _getstdfilex _wfdopen _wfreopen fclose _fcloseall fread fwrite
fflush _flushall _fileno feof ferror clearerr fgetpos fsetpos fseek ftell
_setmode

==== WIDE Stdin/Out functions
wscanf wprintf vwprintf getwchar putwchar _getws _putws

==== WIDE functions reqd for BOTH Stdin/out and general buffered file 
handling
fgetwc fputwc ungetwc fgetws fputws

==== WIDE functions for general buffered file handling
_wfopen fwscanf fwprintf vfwprintf

* It is unclear to me how the CMD.EXE in the HPC/Pro sets up its 
stdin/stdout connections in terms of the underlying Win32 API. If you found 
this out, you could write a CMD replacement for the PocketPC and have a 
single version of Ruby that would work natively in both environments.