1. Bug in Eu v3.0.2 include system (Wincows XP Pro, french)
I was testing a program and needed to add the following folder to EUDIR:
D:\YKNUHW\Privé\telech\win32lib_v006006\Include
(the last character of Priv? is a e with acute accent).
Rebooted, file not found. And yet it was there.
For safety, I copied the path from Explorer to the environment variable
editor, so as to avoid any typo issue. To no avail.
I copied the folder to D:\YKNUHW\win32lib_v006006\Include and changed
the environment variable accordingly.
Rebooted, file now found.
So, it looks like include paths with accented characters, which are
completely allowed and useful under Windows, are not searched correctly.
My guess is that the case insensitive search mechanism, which uses upper(),
doesn't work right for at least some accented chars, but have no time to
investigate further right now.
Any quick fix?
RDS: any chance to get this fixed?
CChris
2. Re: Bug in Eu v3.0.2 include system (Wincows XP Pro, french)
CChris wrote:
>
>
> I was testing a program and needed to add the following folder to EUDIR:
> D:\YKNUHW\Privé\telech\win32lib_v006006\Include
> (the last character of Priv? is a e with acute accent).
> Rebooted, file not found. And yet it was there.
> For safety, I copied the path from Explorer to the environment variable
> editor, so as to avoid any typo issue. To no avail.
> I copied the folder to D:\YKNUHW\win32lib_v006006\Include and changed
> the environment variable accordingly.
> Rebooted, file now found.
>
> So, it looks like include paths with accented characters, which are
> completely allowed and useful under Windows, are not searched correctly.
>
> My guess is that the case insensitive search mechanism, which uses upper(),
>
> doesn't work right for at least some accented chars, but have no time to
> investigate further right now.
> Any quick fix?
> RDS: any chance to get this fixed?
>
> CChris
Note that, if I replace, in the tested file, the file name by its full
quoted path (hence not relying on EUDIR), then the file is found in spite
of the accented letter in the path.
CChris
3. Re: Bug in Eu v3.0.2 include system (Wincows XP Pro, french)
CChris wrote:
>
> CChris wrote:
> >
> >
> > I was testing a program and needed to add the following folder to EUDIR:
> > D:\YKNUHW\Privé\telech\win32lib_v006006\Include
> > (the last character of Priv? is a e with acute accent).
> > Rebooted, file not found. And yet it was there.
> > For safety, I copied the path from Explorer to the environment variable
> > editor, so as to avoid any typo issue. To no avail.
> > I copied the folder to D:\YKNUHW\win32lib_v006006\Include and changed
> > the environment variable accordingly.
> > Rebooted, file now found.
> >
> > So, it looks like include paths with accented characters, which are
> > completely allowed and useful under Windows, are not searched correctly.
> >
> > My guess is that the case insensitive search mechanism, which uses upper(),
> >
> > doesn't work right for at least some accented chars, but have no time to
> > investigate further right now.
> > Any quick fix?
> > RDS: any chance to get this fixed?
> >
> > CChris
>
> Note that, if I replace, in the tested file, the file name by its full
> quoted path (hence not relying on EUDIR), then the file is found in spite
> of the accented letter in the path.
>
> CChris
After digging a little, I can see that upper() isn't the problem.
The issue is with the different encodings of accented characters in various
fonts.
Indeed, when I use an absolute path (succesful), the path which is tried
out by path_open() has a #E9 in it, while the environment variable that
getenv()
returns has a #82 in it, resulting in a failure to
locate the file.
When an accented character occurs in any of the folders listed in EUINC
(and not EUDIR 
), shouldn't path_open() try different font mappings?
The font used when editing a variable under XP can be assessed, and no
variable can be set from autoexec.bat, so that there should not be too many
encodings to try.
CChris
4. Re: Bug in Eu v3.0.2 include system (Wincows XP Pro, french)
CChris wrote:
>
>
> I was testing a program and needed to add the following folder to EUDIR:
> D:\YKNUHW\Privé\telech\win32lib_v006006\Include
> (the last character of Priv? is a e with acute accent).
> Rebooted, file not found. And yet it was there.
> For safety, I copied the path from Explorer to the environment variable
> editor, so as to avoid any typo issue. To no avail.
> I copied the folder to D:\YKNUHW\win32lib_v006006\Include and changed
> the environment variable accordingly.
> Rebooted, file now found.
>
> So, it looks like include paths with accented characters, which are
> completely allowed and useful under Windows, are not searched correctly.
>
> My guess is that the case insensitive search mechanism, which uses upper(),
>
> doesn't work right for at least some accented chars, but have no time to
> investigate further right now.
> Any quick fix?
> RDS: any chance to get this fixed?
>
> CChris
Ok, U'm getting somewhere, but still, there is a bug. Howver, the bug is in
getenv().
Windows XP (don't know if this holds for earlier versions) stores data as
Unicode. However, getenv() returns data which is encoded using the current
OEM code page (437 or 850 exhibit the same behaviour). As a result, the
string getenv() returns is intermreted by Windows as Unicode even though
it is encoded using the 437/850 code page.
As a result, getenv(), on XP at least, should translate the environment
string back to Unicode for it to be correctly understood by the OS.
The workaround I found is to look up the UTF-16 for the character
I know the OEM encoding of, then go to environment editor and paste the
character which has that Unicode encoding in the OEM code page. For
instance, é has OEM code #82 and UTF-16 #E9. So I had to paste in
the char whose OEM code is #E9 (which is Ú).
After reboot, everything was working as expected.
But this is really an annoyance, and one shouldn't need to tinker with
environment variables like this.
CChris
