Re: Modifying the Euphoria interpreter
Robert Craig wrote:
>
> CChris wrote:
> > Are there any restritions on the statements thay may appear in the front end
> > source files?
>
> I don't think there are any restrictions.
> I think you can even have multitasking if you want.
> Obviously, I haven't tested everything though.
>
> > Specifically, I plan to add an open_dll() and c_func() call in scanner.e to
> > fix the problem of paths with accented characters in EUINC or EUDIR not
> > being
> > searched properly by path_open() under Windows. In order to build
> > succesfully,
> > can they remain as-is or should they be replaced by their native
> > machine_func() equivalents?
>
> If you try to *execute* an open_dll under DOS,
> you'll get an error. So you'll need to check platform()
> and avoid that. You should make sure your modified front-end
> runs with ex.exe, not just exw.exe.
>
> I'm not sure we ever agreed on EUforum that
> what you are doing is fine with everyone else,
> but you can certainly try it and let us know how it works.
>
> Thanks,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
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.
CChris
PS: if indeed mentioning open_dll() will cause ex.exe to error out because
it is not supported under DOS32, even though it will never execute the
function, then I'll have to use the machine_func() equivalent, that's all
it will take I bet. Thanks for pointing this potential problem out.
|
Not Categorized, Please Help
|
|
