DOS ain't dead

Is here any way how to get (with DOSLFN) LFN name of file without conversion from UTF-8 to local code page?
F.e. I have a mix of mp3 files, some with czech names but same with russian names and in DOS I am not able to copy them together without destrying eighter czech or russian names.

---
DOS-u-akbar!

> Is here any way how to get (with DOSLFN) LFN name of file without
> conversion from UTF-8 to local code page?
> F.e. I have a mix of mp3 files, some with czech names but same with russian
> names and in DOS I am not able to copy them together without destrying
> eighter czech or russian names.

Will this help ?

http://www.ausreg.com/f4/f4.htm

> Is here any way how to get (with DOSLFN) LFN name of file without
> conversion from UTF-8 to local code page?

Minor nitpick: LFNs are stored in UCS-2 (or maybe UTF-16, not sure, I don't think so though). Of course, if an interface allowed you to access the names with UTF-8 encoded names, that would work too.

> F.e. I have a mix of mp3 files, some with czech names but same with russian
> names and in DOS I am not able to copy them together without destrying
> eighter czech or russian names.

There's no interface that would allow this. You'll have to extend DOSLFN to make it work.

A simple hack to make it work would be to add recognition of a "UTF-8 codepage" to DOSLFN. For that, you'd select some unused codepage number, and if DOSLFN detected that one to be selected, you'd make it convert file names from and to UTF-8 instead of the normal codepage-style conversion. (You could then manually switch to that codepage or whatever.) Besides incompatibility with other programs that don't know this "codepage", the only issue that I can think of right now would be that you'd have to watch out not to overflow the filename buffers; the UTF-8 encoding of non-ASCII characters requires more space than a normal codepage encoding. This should allow you to copy the files without filename corruption. (Lacking UTF-8-capable display drivers, the non-ASCII names would of course show up incorrectly if displayed using DIR or such.)

---
l

> There's no interface that would allow this. You'll have to extend DOSLFN to
> make it work.
>
I think this issue is a big problem
Because in DOS I am not able at all to properly copy mixture os various files with national LFNs.

DOSLFN should really by extended. Good solution maybe could be to use the DF flag from flags register. If DF cleared, act like now, when set, don't make any conversion and keep strings as they are, t.e. in UTF coding.

---
DOS-u-akbar!

> DOSLFN should really by extended. Good solution maybe could be to use the
> DF flag from flags register. If DF cleared, act like now, when set, don't
> make any conversion and keep strings as they are, t.e. in UTF coding.

That's not feasible. The current interfaces are defined as they are, you can't just use DF set as indicator for a different encoding because existing software might expect the interface to just work as usual with DF set as well.

---
l

> That's not feasible. The current interfaces are defined as they are, you
> can't just use DF set as indicator for a different encoding because
> existing software might expect the interface to just work as usual with DF
> set as well.

I think I can. Almost nobody uses DF flag. Besides that virtualy all programers expect that DF is zero - not very programmers even test it when using instructions like REP MOVSD
I am pretty sure that no existing program will be affected with using DF as a parameter.
All "LFN UTF ready" programs when calling UTF version of LFN service would set DF just before INT and immediately after INT again clear DF.

---
DOS-u-akbar!

> I think I can. Almost nobody uses DF flag. Besides that virtualy all
> programers expect that DF is zero - not very programmers even test it when
> using instructions like REP MOVSD

I agree with cm that such an "extension" is a *very* bad idea.

A possible approach is using int 2Fh, ax=1401h (NLSFUNC). This API is already hooked by DOSLFN. It could be easily extended to be used by a program to - temporarily - switch to a (virtual?) codepage that does what you want.

---
MS-DOS forever!