Re: Modifying the Euphoria interpreter
CChris wrote:
> Definitely, this is a Windows only patch, so I check platform() before
> calling open_dll() and before using c_func().
>
> I tested my mod standalone, and it works. This does not replace full
> testing, but means I can go ahead with it.
>
> The proposed modification is actually a _bug fix_:
> * Problem: Under Windows NT/2K/XP and later, paths may legitimately contain
> non-ASCII characters, as long as they belong to the system codepage. If
> the path in EUDIR, or any path inside EUINC, contains such a character,
> said path is not processed by path_open(), and include files therein are not
> found.
> * Cause of the problem: when getenv() returns a string, that string is
> encoded using the current Windows codepage. But the strings open() passes
> are interpreted using the OEM current codepage. Since they have different
> layouts, some characters are misinterpreted, and path_open() searches a path
> that very likely doesn't exist.
> * Current workaround: In the Advanced tab of system properties, change
> offending characters in paths to the ones with the right codes.
> Example: if a path ontains a e acute accent, coded #E9 in the Windows code
> page and #82 in the OEM codepage, replace that e acute by the character with
> code #82 in the Windows codepage. This happens to be a U acute.
> This workaround implies tweaking environment variables and rebooting the
> computer for changes to take effect; it is not satisfactory, but at least it
> works.
> * Suggested mod to front end, specifically to path_open():
> If trying to open a file using a path from EUINC/EUDIR fails, if platform()
> is Windows and if the path has accented characters, then try again after
> converting this path using the CharToOemA() WinAPI. It has been in
> kernel32.dll since Windows 3.0 and probably before.
> Conversion applies to the path only, not the file name, since it is not
> stored in the environment variable.
>
> At least this is the right API to use, and the modified path_open() now finds
> files it was missing before.
> When I have tested with a real life interpreter (built under OW1.5), I'll
> (try to) submit that mod. Unless someone has a brighter idea.
This sounds reasonable to me.
Maybe others have an opinion?
I can give you full developer permissions on SourceForge
so you can check out official source code using SVN
(e.g. TortoiseSVN) and check it back in again after testing it
on your system. You just need to sign up for a free SourceForge id
and let me know what it is.
I realize that 90% of the job will be learning how
to use SVN, but I want to wean the community off using
me (or Matt) to make all changes. It will be better if
we have several people who are able to make changes and
check them in (and then handle the almost-inevitable bug
reports and enhancement requests that will flow from that).
I hope to get back to the 3.1 FreeBSD Release Candidate
later today. I had several distractions over the past few days.
It might be better to hold off on checking in your changes
until I do the full 3.1 official release for all platforms,
this week I hope.
Thanks,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
|
Not Categorized, Please Help
|
|
