1. RE: Lfn.e

It is really strange. Windows and DOS use different code pages, but BOTH @
and _ have the same Hex representation under Windows and under DOS. That is,
@ is Hex 40, and _ is Hex 5F. Hex AE, instead, corresponds to « (Alt-174)
under DOS and under Outlook Express (I in fact generated this character
 here by typing ALT-174), but to a 'registered' symbol (a R within a circle)
under Windows editors.
So it seems that something is wrong with code pages in your PC.
Anyway, please try my "text utilities" programs in the Euphoria Archive. One
of them allows conversion between DOS and Windows normal code pages, but you
can easily change it to convert between any two character sets.
Regards.
----- Original Message -----
From: <bobelia200 at NETZERO.NET>
To: EUforum <EUforum at topica.com>
Sent: Saturday, December 21, 2002 1:35 AM
Subject: Lfn.e



Juergen,

I started writing an app to test Lfn.e and came upon this:

Several files I was trying to process had been saved as .txt from Internet
Explorer and contained the '@' sign in their names.  That is what is shown
in a folder by Windows.
I verified with a disk editor that the '@' sign was #AE on disk.  However,
DOS returns that character as an underscore ( #5F
).   lfn_dir("discov*.txt") returned a list which contained:

"Discover_ Platinum Account Statement 09-26-02.txt"

Note the '_' instead of '@'.  lfn_open() failed to open this file.

This is very likely a code page problem but I don't have time to research
it now. Perhaps Igor could help?  I will mail you the test report.
Thanks,

Bob

P.S.   command.com's "dir" showed it like above; 4DOS, which I use every
day, would only show the alias (short form).

==^^===============================================================
This email was sent to: rforno at tutopia.com





----------------------------------------------------------------------------
----


>
> ---
>

new topic     » topic index » view message » categorize

2. RE: Lfn.e

--=======49E155E3=======

At 02:42 PM 12/21/02 -0300, you wrote:

>
>It is really strange. Windows and DOS use different code pages, but BOTH @
>and _ have the same Hex representation under Windows and under DOS. That=
 is,
>@ is Hex 40, and _ is Hex 5F. Hex AE, instead, corresponds to =AB (Alt-174)
>under DOS and under Outlook Express (I in fact generated this character
>  here by typing ALT-174), but to a 'registered' symbol (a R within a=
 circle)
>under Windows editors.
>So it seems that something is wrong with code pages in your PC.
>Anyway, please try my "text utilities" programs in the Euphoria Archive.=
 One
>of them allows conversion between DOS and Windows normal code pages, but=
 you
>can easily change it to convert between any two character sets.
>Regards.

         Thanks, Ricardo, I'll try that.

                 Bob

--=======49E155E3=======
Content-Type: text/plain; charset=us-ascii; x-avg=cert;
x-avg-checked=avg-ok-51B33FCA
Content-Disposition: inline


---

--=======49E155E3=======--

new topic     » goto parent     » topic index » view message » categorize

3. RE: Lfn.e

My 'translation' program uses code page 850. I think it is used by most
Western languages. Correct me if I'm wrong.
Regards.
----- Original Message -----
From: Juergen Luethje <eu.lue at gmx.de>
Subject: Re: Lfn.e



Bob wrote:

> Juergen,
>
> I started writing an app to test Lfn.e and came upon this:

Many thanks.

> Several files I was trying to process had been saved as .txt from Internet
> Explorer and contained the '@' sign in their names.  That is what is shown
> in a folder by Windows.
> I verified with a disk editor that the '@' sign was #AE on disk.

That is strange. As Ricardo already wrote, normally '@' is #40.

> However, DOS returns that character as an underscore ( #5F ).
>    lfn_dir("discov*.txt") returned a list which contained:
>
> "Discover_ Platinum Account Statement 09-26-02.txt"
>
> Note the '_' instead of '@'.  lfn_open() failed to open this file.

To test this on my system, I created a file by hand, using Windows
Explorer (Win 98), with the name:  "äÄöÖüÜß at 123.txt"

I don't know how the characters in this filename look on your system.
The first 7 chars are spezial German characters whith the codes
#84, #8E, #94, #99, #81, #9A, #E1 on codepage 850.

On a Win 98 DOS box, lfn_dir("*.*") showed the name correctly, and
lfn_open() opened the file. On plain MS-DOS 7.10, the filename consisted
of the first 6 characters (all uppercase) & '~1', as usual.
lfn_dir("*.*") again showed the name correctly, and lfn_open() opened
the file.

> This is very likely a code page problem but I don't have time to research
> it now. Perhaps Igor could help?

Hmm.. I always thought, that the standard ASCII characters (#00-#7F) are
the same on all codepages. If this is right, then there shouldn't be a
codepage problem with '@'. What codepage are you using? (type 'chcp' at
the DOS prompt)
My LFN functions all use the DOS interrupt #21. Is this interrupt on
your system handled by MS-DOS, or by 4DOS?
Did the program in Ricardo's text utilities solve the problem for you?
I also downloaded it, but I couldn't see, what DOS codepage it supports.

I searched Ralph Brown's DOS interrupt list, but didn't find anything
like a 'translate_ANSI_to_current_OEM_codepage()' function. But if there
is need for it, I can provide tables for translation from/to ANSI on the
one hand, and DOS codepages 437, 850, 852, 863, 865, and 866 on the
other hand ... next year.[1]
I really hope, that such a translation normally isn't required for my
LFN functions. At least, for MS-DOS 7.10 and codepage 850 it doesn't
seem to be necessary.

Sorry that I can't help you more at the moment.

> I will mail you the test report.
> Thanks,
>
> Bob

I received it, thank you again.

> P.S.   command.com's "dir" showed it like above; 4DOS, which I use every
> day, would only show the alias (short form).

Regards,
   Juergen

---------------------
[1] BTW, to everyone:
    Merry Christmas and a Happy New Year.
    Frohe Weihnachten und ein gutes Neues Jahr.
    Prettige Kerstdagen en een Gelukkig Nieuwjaar.
    Joyeux Noël et Bonne Année.
    Feliz Navidad y Próspero Año Nuevo.
    Buon Natale e felice Anno Nuovo.

==^^===============================================================
This email was sent to: rforno at tutopia.com

new topic     » goto parent     » topic index » view message » categorize

4. RE: Lfn.e

Juergen:
As I said before, Alt-174 (that is, #AE, not #AB; was that a typo, or
unicode has this different?) produces a left-chevron («) under Outlook
Express and DOS. But #AE shows as R within a circle under several Windows
editors. I tried EDXOR, Note Pad, Word Pad, Win Edit, Crimson Editor, and
the editor that comes with Borland C++ 5.0, all with the same result. As I'm
usign code page 850, the same as you, you should be getting the same
results. If not, I can't explain why.
----- Original Message -----
From: Juergen Luethje <eu.lue at gmx.de>
Subject: Re: Lfn.e



Robert Elia wrote:

> Juergen and Ricardo,
>
>          I must apologize for my bad eyesight and 14" monitor.  I believe
> it actually was the  'registered trademark' symbol ( R with a circle
around
> it ) in my filename.   At least, I can't find  the @ symbol.

Well, this puzzle seems to be solved. smile

>          "«" I just typed Alt-174 (#AE) before this sentence between
quotes
> in Eudora.  It looks the same in DOS on my machine. So, that's not part of
> the problem, I think.


Here are links to unicode character code tables as PDF-files:

   http://www.unicode.org/charts/PDF/U0000.pdf
   http://www.unicode.org/charts/PDF/U0080.pdf

so it's easier for us to see, what characters the other one means.

>          Anyway, I'm still getting the failure.  Ralf Browns list also
> shows this:
>
>   INT 21 - Windows95 - LONG FILENAME - FIND FIRST MATCHING FILE
>           AX = 714Eh
>           CL = allowable-attributes mask (see #01397 at AX=4301h)
>                 (bits 0 and 5 ignored)
>           CH = required-attributes mask (see #01397)
>           SI = date/time format (see #01755)
>           DS:DX -> ASCIZ filespec (both "*" and "*.*" match any filename)
>           ES:DI -> FindData record (see #01756)
>   Return: CF clear if successful
>               AX = filefind handle (needed to continue search)
>               CX = Unicode conversion flags (see #01757)
>           CF set on error
>               AX = error code
>                   7100h if function not supported
> <snip>
>   Bitfields for Windows95 Unicode conversion flags:
>   Bit(s)  Description     (Table 01757)
>    0      the returned full filename contains underscores for
un-convertable
>             Unicode characters
>    1      the returned short filename contains underscores for
un-convertable
>             Unicode characters
>   SeeAlso: #01756
>
> INT 21:AX = 714Eh  reg_list[REG_CX] bit 0 *IS* returning 1 on the bad
> filenames. and, indeed, lfn_dir() is showing them with underscores (#5F)
> instead of #AE. I even tried replacing the #5F with #AE before calling
> lfn_open() but that didn't work either.

Strange. Even if I create a whole filename consisting of #AE characters
(Alt-174 in the Windows Explorer), lfn_dir() and lfn_open() work fine.

BUT: By typeing Alt-174, I do *not* get the (R) sign! I get chevrons
(#AB in http://www.unicode.org/charts/PDF/U0080.pdf). That means, that
my Windows Explorer doesn't use Unicode, right? Interestingly, up to
this point, OEM codepages and DOS do not seem to be involved at all.
But maybe I'm completely wrong ...

      Iiiiii-goooor ?!!  smile)

>          My "Regional Settings" in Win98 are set to "English (United
States)"
>
>          and, in Dos,    c:\windows\personal>chcp
>                          Active code page: 437
>
>          I don't know enough about Unicode to say why the offending
> character is considered "un-convertible" by INT21714Eh. I don't know how
to
> determine whether my system is broken or just set to some odd but legal
> configuration.  From what I've read so far, windows uses the ANSI code
page
> and DOS uses OEM. There are some "extended" characters which don't map
> properly.

When I got my first PC, I read that only standard characters should be
used for building filenames. Maybe this is also true in modern times?

>          I have been able to create a file on the command line using
> Alt-keypad a file with your codes in the name. They work fine with my test
> program using lfn.e and they probably display the way you see them.  I see
> the lower and upper case a, o, u (alles mit umlaut)

Yup. smile

> followed by the letter whose name I can't remember.

The German name for this sign, looking like the Greek Beta, is "sz"
(pronounced like "Ess-Tssett" smile.
(#DF in http://www.unicode.org/charts/PDF/U0080.pdf).
Well, you see exactly what I typed.

> äÄöÖüÜß  I even used #AE in a filename and
> that worked but in the long form it's changed to #AB on disk.

That's the same what happened to me (see above). It's very strange for
me, too. However #AB works fine for me.  smile
I *always* hated this charakter set stuff ...

> I will try to take screen shots and show what I mean.
>
>          It may be that there's some windows setting that's causing this
> behavior.  I will share what I find with you if I think I understand it.
>
>                  Thanks for your effort,
>
>                          Bob

I want to say the same to you.

Regards,
   Juergen

--
 /"\  ASCII ribbon    | while not asleep do
 \ /  campain against |    sheep += 1
  X   HTML e-mail and | end while
 / \  news            |

==^^===============================================================
This email was sent to: rforno at tutopia.com

new topic     » goto parent     » topic index » view message » categorize

5. RE: Lfn.e

On 23 Dec 2002, at 21:38, rforno at tutopia.com wrote:

> 
> Juergen:
> As I said before, Alt-174 (that is, #AE, not #AB; was that a typo, or
> unicode has this different?) produces a left-chevron (=AB) under Outlook
> Express and DOS. But #AE shows as R within a circle under several
> Windows editors. I tried EDXOR, Note Pad, Word Pad, Win Edit, Crimson
> Editor, and the editor that comes with Borland C++ 5.0, all with the
> same result. As I'm usign code page 850, the same as you, you should be
> getting the same results. If not, I can't explain why. ----- Original

Ricardo:

Alt-0174 (note the zero) is =AE (Registered) while Alt-174 (no zero) is =AB=
 
(left-chevron) in ANSI char-map (Windows). While in DOS, you're using 
OEM char-map and these codes will produce =AE (Registered) and =A9 
(Copyright) respectively.
You have to be careful as some editors do not handle both tables. I use 
EditPad that works quite well. :)

Be good,

-- Euler

new topic     » goto parent     » topic index » view message » categorize

6. RE: Lfn.e

On 23 Dec 2002, at 21:38, rforno at tutopia.com wrote:

> 
> Juergen:
> As I said before, Alt-174 (that is, #AE, not #AB; was that a typo, or
> unicode has this different?) produces a left-chevron (=AB) under Outlook
> Express and DOS. But #AE shows as R within a circle under several
> Windows editors. I tried EDXOR, Note Pad, Word Pad, Win Edit, Crimson
> Editor, and the editor that comes with Borland C++ 5.0, all with the
> same result. As I'm usign code page 850, the same as you, you should be
> getting the same results. If not, I can't explain why. ----- Original

Ricardo:

Just another word: alt-174 (that is used on DOS) is the same as alt-
0171 (on Windows). Both will print out a left-chevron.

-- Euler

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu