lfndssrc.zip

[cg_chas]

Does anybody happen to have a copy of or know where I can obtain lfndssrc.zip?
It is from Chris Jones's LFNDOS project which is no longer being maintained.

Here's where it used to be:
http://web.archive.org/web/20010821074213/http://members.nbci.com/dosuser/dosutils.htm

and here...
http://web.archive.org/web/20010407230330/http://saturn.spaceports.com/~dosuser/dosutils.htm

and here...
http://web.archive.org/web/20050206113625/http://www.sylpher.com/dosuser/dosutils.htm

Best Regards,
Charles

[Rugxulo]

Hi,

On May 7, 9:21 pm, cg_chas <cg_c...@hotmail.com> wrote:
>
> Does anybody happen to have a copy of or know where I can obtain lfndssrc.zip?
> It is from Chris Jones's LFNDOS project which is no longer being maintained.

A Google search doesn't find it (no surprise). But it appears Rod
Pemberton mentioned it in 2005, and he's still "around", so you could
ask him perhaps.

BTW, if it doesn't have to be this particular LFN tool, you could use
something similar instead which does have sources, e.g. StarLFN or
DOSLFN:

http://sta.c64.org/starlfn.html

http://doslfn.adoxa.cjb.net

[cg_chas]

Thanks. I will try to contact Rod Pemberton.

I really wanted to look at Chris Jones's sources because of what appears to be
a technique he used for hooking DOS function calls on a child COMMAND.COM
process.

I have had mixed success in trying to do the same. You can see my other post
from today's date that describes the issue I am having.

My intention is to also implement long file name support for DOS.

I have not tried starlfn, but I have tried doslfn and have found it to be very
buggy. A simple dir from real mode on a Windows 98 tree with the doslfn
driver loaded gives garbage where LFNDOS "seems" to at least work correctly.
Admittedly I have not done extensive testing with LFNDOS, but I would consider
resuming where Chris Jones left off if I can locate his sources which at one
time he had made available freely.

Thank you for your reply.

Charles

[Auric__]

cg_chas wrote:

> I really wanted to look at Chris Jones's sources because of what appears
> to be a technique he used for hooking DOS function calls on a child
> COMMAND.COM process.

You could run lfndos.exe through a debugger or a disassembler.

--
Ack! I'm trapped in a bad Radio Shack commercial!

[Rod Pemberton]

"cg_chas" <cg_...@hotmail.com> wrote in message
news:dqgiq75ptivv2iabu...@4ax.com...

> On Tue, 8 May 2012 08:47:48 -0700 (PDT), Rugxulo <rug...@gmail.com>
> wrote:
> >On May 7, 9:21 pm, cg_chas <cg_c...@hotmail.com> wrote:
> >>
> >> Does anybody happen to have a copy of or know where I can obtain
> >> lfndssrc.zip? It is from Chris Jones's LFNDOS project which is no
> >> longer being maintained.

Yes, I do.

I have these from CG:

LFNDOS.ZIP
LFNDSSRC.ZIP
LFNDSNEW.ZIP

I also have these, which I believe are from him.

INTWRAP.ASM
LFNSAMPL.ZIP

IIRC, INTWRAP.ASM, the source for INTWRAP.OBJ, was released later
and is not in the .zip's.

I also have my changes and fixes which have not been released. I'll package
them up and post to Rapidshare or similar etc. Give me a bit of time.
Today. Tomorrow. A few days. I'll repost with a link.

> >BTW, if it doesn't have to be this particular LFN tool, [...]

DOSLFN works really well. That why I stopped messing around with Chris
Jone's LFNDOS.

> Thanks. I will try to contact Rod Pemberton.
>

Well, good luck with that. Usenet posts are about the only way you can
contact me.


Rod Pemberton

[Rod Pemberton]

"Rod Pemberton" <do_no...@notemailnot.cmm> wrote in message
news:jod2h2$hdg$1...@speranza.aioe.org...

> "cg_chas" <cg_...@hotmail.com> wrote in message
> news:dqgiq75ptivv2iabu...@4ax.com...
> > On Tue, 8 May 2012 08:47:48 -0700 (PDT), Rugxulo <rug...@gmail.com>

> > >On May 7, 9:21 pm, cg_chas <cg_c...@hotmail.com> wrote:

....

> I'll package them up and post to Rapidshare or similar etc. [...]

> I'll repost with a link.
>

Ok, Rapidshare's policies have changed. So, I'm trying Filedropper. I've
not used them previously. So, I don't know how many downloads they allow.
I did one as a test. Let me know if you have any problems getting the file.
I'd ask that any other people interested in the files to please wait a few
days so that Charles can get them. Supposedly, it'll expire in 30 days.

http://www.filedropper.com/lfn

Click big grey download box. Asks for captcha. Enter. Download starts.


Rod Pemberton

[cg_chas]

Thank you sir!

[cg_chas]

I have read comments from various sites that list LFN packages. They
generally agree with you regarding DOSLFN, but my experience has not been the
same.

On two different systems, I have installed Windows 98. One with FAT16, one
with FAT32. On both of those systems, from real mode, with DOSLFN loaded, a
simple DIR listing from the root of C produces garbage after Program Files as
if the string wasn't terminated properly. I have not looked into this any
further, but there is either a serious bug there or I am not using it on a
supported platform. (FAT16 / FAT32 / MS-DOS 7 / Long files made from Windows?)

>
>> Thanks. I will try to contact Rod Pemberton.
>>
>
>Well, good luck with that. Usenet posts are about the only way you can
>contact me.

I noticed :)
I was hoping to find your e-mail in a mailing list somewhere, but no luck.

Anyhow, I am glad you saw this post.

>
>
>Rod Pemberton
>
>
>
>

Thank you very much Rod,
Charles

[cg_chas]

On Wed, 09 May 2012 05:32:06 -0400, cg_chas <cg_...@hotmail.com> wrote:

>On Wed, 9 May 2012 05:28:50 -0400, "Rod Pemberton"
><do_no...@notemailnot.cmm> wrote:
>
>>"Rod Pemberton" <do_no...@notemailnot.cmm> wrote in message
>>news:jod2h2$hdg$1...@speranza.aioe.org...
>>> "cg_chas" <cg_...@hotmail.com> wrote in message
>>> news:dqgiq75ptivv2iabu...@4ax.com...
>>> > On Tue, 8 May 2012 08:47:48 -0700 (PDT), Rugxulo <rug...@gmail.com>
>>> > >On May 7, 9:21 pm, cg_chas <cg_c...@hotmail.com> wrote:
>>....
>>
>>> I'll package them up and post to Rapidshare or similar etc. [...]
>>> I'll repost with a link.
>>>
>>
>>Ok, Rapidshare's policies have changed. So, I'm trying Filedropper. I've
>>not used them previously. So, I don't know how many downloads they allow.
>>I did one as a test. Let me know if you have any problems getting the file.
>>I'd ask that any other people interested in the files to please wait a few
>>days so that Charles can get them. Supposedly, it'll expire in 30 days.

Forgot to mention that I got the files successfully.
Thanks again!

[Rod Pemberton]

"cg_chas" <cg_...@hotmail.com> wrote in message

news:edekq7hhnac7jap2b...@4ax.com...

> On Wed, 9 May 2012 02:24:02 -0400, "Rod Pemberton"
> <do_no...@notemailnot.cmm> wrote:
> >"cg_chas" <cg_...@hotmail.com> wrote in message

...

> >DOSLFN works really well. That why I stopped messing around with Chris
> >Jone's LFNDOS.
>
> I have read comments from various sites that list LFN packages. They
> generally agree with you regarding DOSLFN, but my experience has not been
> the same.
>

I'm sorry to hear that. I use version 0.32o almost exclusively. I haven't
had any problems with it. I think that was Henrik Haftman's last version.

There have been alot of updates since Henrik Haftmann's last version. I
also have 0.34b and 0.40e around. Jason Hood has done a bunch. Japheth
(0.40f) did one for directory corruption. Jason Hood's 0.41 includes
Japheth's fix. I don't recall as to which version, but at some point it was
changed to require SHSUCDX for cd-rom support. The current version is 0.41b
is at the link Rugxulo posted:

http://doslfn.adoxa.cjb.net

As for LFNDOS, you'll see in the comments in the version I was modifying
that I was experiencing some type of mysterious "lockup" ... I was probably
compiling with DJGPP and suspect that the TSR wasn't locking all memory, but
I don't know. If I was to work on it again, I'd probably revert from DJGPP
to either OpenWatcom or Borland C++ so I could create a true 16-bit TSR,
instead of a 32-bit DPMI based TSR.


Good luck.


Rod Pemberton

[cg_chas]

On Thu, 10 May 2012 03:44:24 -0400, "Rod Pemberton"
<do_no...@notemailntt.cmm> wrote:

>"cg_chas" <cg_...@hotmail.com> wrote in message
>news:edekq7hhnac7jap2b...@4ax.com...
>> On Wed, 9 May 2012 02:24:02 -0400, "Rod Pemberton"
>> <do_no...@notemailnot.cmm> wrote:
>> >"cg_chas" <cg_...@hotmail.com> wrote in message
>...
>
>> >DOSLFN works really well. That why I stopped messing around with Chris
>> >Jone's LFNDOS.
>>
>> I have read comments from various sites that list LFN packages. They
>> generally agree with you regarding DOSLFN, but my experience has not been
>> the same.
>>
>
>I'm sorry to hear that. I use version 0.32o almost exclusively. I haven't
>had any problems with it. I think that was Henrik Haftman's last version.

Just curious, have you tried it with MS-DOS 7 in real mode?

>
>There have been alot of updates since Henrik Haftmann's last version. I
>also have 0.34b and 0.40e around. Jason Hood has done a bunch. Japheth
>(0.40f) did one for directory corruption. Jason Hood's 0.41 includes
>Japheth's fix. I don't recall as to which version, but at some point it was
>changed to require SHSUCDX for cd-rom support. The current version is 0.41b
>is at the link Rugxulo posted:

I've tried 0.41b and it has the same symptom.

>
>http://doslfn.adoxa.cjb.net
>
>As for LFNDOS, you'll see in the comments in the version I was modifying
>that I was experiencing some type of mysterious "lockup" ... I was probably
>compiling with DJGPP and suspect that the TSR wasn't locking all memory, but
>I don't know. If I was to work on it again, I'd probably revert from DJGPP
>to either OpenWatcom or Borland C++ so I could create a true 16-bit TSR,
>instead of a 32-bit DPMI based TSR.
>
>
>Good luck.
>
>
>Rod Pemberton
>
>

Thanks.

Unfortunately I have done nothing with DPMI stuff (yet), so I can't directly
help with the DJGPP issue. I will venture a guess though that the problem is
possibly due to failure to preserve registers and DOS "areas" when needed.
DOS INT 21h calls seem to be highly sensitive to this :)

I had similar issues during the development of my WATCH21H utility. I can say
that lockups will occur if you hook INT 21h and do not restore the registers
before your handler returns, especially if you are doing post oldint21
processing. My issues were with saving and restoring the registers which
turned out not to be a really big deal for Borland C++ / TASM. I am not
nearly as proficient with assembly as I am with C++ so I tend to rely on
inline ASM quite a bit rather than fully assembled programs. Normally this is
not a big deal, but as soon as you have to deal with stack switching, C++ no
longer is enough. Assembly is required.

I am sure you already know that DOS calls generally are not re-entrant, so if
you need to make DOS calls from the newint21 handler, you effectively "have
the calls scheduled" (set flags). To do this, you have to do stack switching
as well as PSP and DTA saving and restoring. If you can get away without
doing DOS calls from your INT 21h handler, you are better off, but you still
must restore the register states if you do post oldint21 processing.

I started WATCH21H a few days before you had given me the LFNDOS sources. It
effectively works like a 16-bit real mode TSR. It hooks int 21h and handles
pre and post oldint21 calls and displays register codes on the screen like a
debugger. I am finding that it works really well for me so far and it is
going to make life easier when implementing my own updates to LFNDOS.

Here is a link to it if you are interested in seeing WATCH21H.
There's a screenshot there as well as source code in the zip archive.

http://mysite.verizon.net/sub19jrhd/watch21h.html

The techniques I use for stack switching and DTA/PSP manipulation are from
John English's C++ TSR Class. I've included his archive in mine for compliance
with his permission as well as completeness to watch21h.zip.

I look forward to diving into LFN under DOS next week :)

Charles

[Rod Pemberton]

"cg_chas" <cg_...@hotmail.com> wrote in message

news:vkoqq7lqshij3mfng...@4ax.com...

> On Thu, 10 May 2012 03:44:24 -0400, "Rod Pemberton"
> <do_no...@notemailntt.cmm> wrote:

...

> I've tried 0.41b and it has the same symptom.

...

> Just curious, have you tried it with MS-DOS 7 in real mode?
>

I use it with MS-DOS in RM for Win98/SE. I first used it with Windows 98
and later with Windows SE. I believe that's v7.10. My partitions have been
FAT32. I don't believe I've used it with other devices, like floppies or
USB or cd-roms.

So far, the only thing I've noticed is that one program which creates a
ramdisk won't create an LFN for the disk, but I assumed that it was
something to do with the ramdisk program.

So, you just type "DIR C:\" and get garbage at the end when the "Program
Files" directory is displayed? Let me go check.

Yeah, I'm not seeing that (032.o). I did DIR/P in the C:\ directory as well
as within "Program Files" directory, multiple times. Everything appears
correct to me.

Which DOS and version are you using: MS-DOS, FreeDOS, OpenDOS/DR-DOS,
PC-DOS?

The only thing I recommend, besides a different DOS, is to try the LFN tools
package by Ortwin "Odi" Glueck. Use LDIR to check the SFN and LFN are
correct. Use DOS' REN to fix the SFN, and LREN to fix the LFN. The tools
are really good. I *love* LCOPY. No LFN TSR required. He implemented
drive locking too, so AIUI they work in a Windows dosbox/console too.
However, building them requires an old DOS version of MSVC++ (v1.51) that
can produce DOS binaries. And, there is no TSR by Odi ... The lack of a
TSR was the big disappointment.
http://lfntools.sourceforge.net/

> I started WATCH21H a few days before you had given me the LFNDOS
> sources. It effectively works like a 16-bit real mode TSR. It hooks int
> 21h and handles pre and post oldint21 calls and displays register codes
> on the screen like a debugger. I am finding that it works really well for
> me so far and it is going to make life easier when implementing my own
> updates to LFNDOS.
>

Nice.

I did it somewhat more brutishly. I implemented a bunch, like 186 of them,
of "watcher" routines in assembly using 16-bit x86 for NASM. I have a
base group of maybe four or five small programs that get repeated and
renamed for each interrupt. One displays the interrupt vector. One
displays interrupt calls to that vector. Etc. Some pause for keypresses.
Etc. The more advanced ones display in the bottom-right hand corner of the
screen, then scroll the right hand side of the screen. They display the
interrupt number and AX/AH value, sometimes BX etc., and indicate repeated
AX/AH calls with an asterisk "*" to slow down unnecessary scrolling. I just
run one for each interrupt I want to watch, after loading other programs
that set interrupts, obviously. I learned that there are certain few
interrupts that don't like being trapped, and others that don't like it if
you pause for a keypress. I always wanted to have the ability to save the
data to a file, but I never got around to learning how to do that exactly.
See Int 10h, ax=06h for scrolling.

> The techniques I use for stack switching and DTA/PSP manipulation are from
> John English's C++ TSR Class. I've included his archive in mine for
> compliance with his permission as well as completeness to watch21h.zip.

I'm not familiar with manipulating DTA or PSP or InDOS stuff. Supposedly,
DJGPP handles it for you ... Unfortunately, learning DOS programming was
just a side result of using DJGPP (GCC compiler for DOS w/custom DOS C
library) for my personal C programs.

Have you heard of undocumented Int 21h, ax=5d06h or 5d0bh?
http://groups.google.com/group/comp.os.msdos.programmer/msg/8417651dcc1d72da


Rod Pemberton

[cg_chas]

On Fri, 11 May 2012 17:56:43 -0400, "Rod Pemberton"

<do_no...@notemailntt.cmm> wrote:

>"cg_chas" <cg_...@hotmail.com> wrote in message
>news:vkoqq7lqshij3mfng...@4ax.com...
>> On Thu, 10 May 2012 03:44:24 -0400, "Rod Pemberton"
>> <do_no...@notemailntt.cmm> wrote:
>...
>
>> I've tried 0.41b and it has the same symptom.
>...
>> Just curious, have you tried it with MS-DOS 7 in real mode?
>>
>
>I use it with MS-DOS in RM for Win98/SE. I first used it with Windows 98
>and later with Windows SE. I believe that's v7.10. My partitions have been
>FAT32. I don't believe I've used it with other devices, like floppies or
>USB or cd-roms.
>
>So far, the only thing I've noticed is that one program which creates a
>ramdisk won't create an LFN for the disk, but I assumed that it was
>something to do with the ramdisk program.
>
>So, you just type "DIR C:\" and get garbage at the end when the "Program
>Files" directory is displayed? Let me go check.
>
>Yeah, I'm not seeing that (032.o). I did DIR/P in the C:\ directory as well
>as within "Program Files" directory, multiple times. Everything appears
>correct to me.
>
>Which DOS and version are you using: MS-DOS, FreeDOS, OpenDOS/DR-DOS,
>PC-DOS?

Win98/SE here too, so MS-DOS 7.10 and I haven't tested with ramdisk, floppies,
usb, or cd-roms yet.

I observed a couple different problems trying to unzip32 (and pkunzip) the
DJGPP archives with doslfn, so I then took it to VirtualBox which has
Win98/SE, and under Real Mode is where I observed with doslfn the garbage
after Program Files as well as others, but it wasn't just limited to that one
directory. It is possible I have observed more than one issue without
realizing it, of which, an incompatibility with VirtualBox and doslfn is
possible. I tried with FAT16 and FAT32, both cases are MS-DOS 7.10 (Win 98/SE
[Version 4.10.2222]).

>
>The only thing I recommend, besides a different DOS, is to try the LFN tools
>package by Ortwin "Odi" Glueck. Use LDIR to check the SFN and LFN are
>correct. Use DOS' REN to fix the SFN, and LREN to fix the LFN. The tools
>are really good. I *love* LCOPY. No LFN TSR required. He implemented
>drive locking too, so AIUI they work in a Windows dosbox/console too.
>However, building them requires an old DOS version of MSVC++ (v1.51) that
>can produce DOS binaries. And, there is no TSR by Odi ... The lack of a
>TSR was the big disappointment.
>http://lfntools.sourceforge.net/

Not to "dis" the tools as I can see a real need for them, but for now, I am
only interested in a TSR at this point. I am trying to provide lfn support to
programs that can use or require long file names including the file manager
that I am developing for one of my old applications as well as DJGPP.

Yes, absolutely!

My WATCH21H program uses 0x5D06. I learned about this originally from John
English's C++ TSR Class and some more from UNDOCUMENTED DOS, Second Edition
pages 558-559.

// locate critical error flag
r.x.ax = 0x5D06;
intdosx (&r, &r, &s);
critical = (char far*) MK_FP(s.ds, r.x.si);

I watch the following 4 flags to determine if its safe to switch stacks, psp,
and dta.

if (*indos == 0 && *critical == 0 && diskflag == 0 && myindos == 0) ...

myindos is my flag that I set from my INT 21h handler so that I can prevent
the TSR from activating during processing before and after the call to the old
INT 21h handler.

diskflag came exclusively from John English. If interested, you can read more
about that from his TSR100JE C++ class.

I don't believe I have ever used 5D0Bh, which I show to be DOS 4.x only -
internal - GET DOS SWAPPABLE DATA AREAS. Instead, for that, I use 5D06h.

I also use:
2Fh DOS 2+ - GET DISK TRANSFER AREA ADDRESS
1Ah DOS 1+ - SET DISK TRANSFER AREA ADDRESS
51h DOS 2+ internal - GET CURRENT PROCESS ID (GET PSP ADDRESS)
50h DOS 2+ internal - SET CURRENT PROCESS ID (SET PSP ADDRESS)
34h DOS 2+ - GET ADDRESS OF INDOS FLAG

>
>Rod Pemberton

Charles

[Rugxulo]

Hi,

On May 10, 2:44 am, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
wrote:

>
> As for LFNDOS, you'll see in the comments in the version I was modifying
> that I was experiencing some type of mysterious "lockup" ...  I was probably
> compiling with DJGPP and suspect that the TSR wasn't locking all memory, but
> I don't know.

Way too complicated for me. But according to the FAQ ... :

http://www.delorie.com/djgpp/v2faq/faq18_9.html

"
Lock all the memory your handler touches, the code of the handler
itself, and any function it calls, with a series of calls to
__dpmi_lock_linear_region. Failure to lock memory accessed during the
interrupt handling will cause your program to crash. Alternatively,
you could set the _CRT0_FLAG_LOCK_MEMORY bit in the
_crt0_startup_flags variable, like this:

#include <crt0.h>

int _crt0_startup_flags = _CRT0_FLAG_LOCK_MEMORY;

Another possibility is to disable virtual memory by using CWSDPR0 as
your DPMI server.

"

> If I was to work on it again, I'd probably revert from DJGPP
> to either OpenWatcom or Borland C++ so I could create a true 16-bit TSR,
> instead of a 32-bit DPMI based TSR.

There was (I thought) an example of a TSR with DJGPP somewhere,
perhaps CWS' old page, but I can't find it. You could probably email
him (cwsdpmi _AT_ earthlink _AT_ net). But IIRC you can't unload such
things.

[Rod Pemberton]

"cg_chas" <cg_...@hotmail.com> wrote in message

news:rs5sq7hme11emommn...@4ax.com...

> On Fri, 11 May 2012 17:56:43 -0400, "Rod Pemberton"
> <do_no...@notemailntt.cmm> wrote:

...

> Not to "dis" [Odi's LFN] tools as I can see a real need for them, [...]

Oh, I just thought someday, maybe someone, might be skilled enough to take
his source and make it into a TSR ...

> I am trying to provide lfn support to programs that can use or
> require long file names including the file manager
> that I am developing for one of my old applications as well as DJGPP.

Well, I've got few thoughts on that.

First, I forgot about it, but I wrote a test program to see which LFN
functions Windows 98, DOSLFN, and LFNDOS support. It's got RBIL interrupt
notes, probably copyrighted, that I need to remove ... It may save you some
time. It appears to be DJGPP only. I'll post a clean version after my .sig
to keep it separate from the other list below.

Second, I extended a program called rpmunpack.c for DJGPP and OpenWatcom for
LFN use. It uses 3 functions: 0x7156, 0x716C, and 0x3E. I'm not sure if
there is a difference between the two postings:
http://groups.google.com/group/openwatcom.contributors/msg/407305aa1df591de
http://groups.google.com/group/comp.os.msdos.djgpp/msg/07dac4062df95adc

Third, most of my other LFN-aware programs uses 0x71a0 and 0x7160
exclusively. AFAIK, I've not posted those functions. They're implemented
similarly to the two 0x71xx functions in rpmunpack.c. Very simple test
functions are also in my test program below. But, I do explain how I've
used 0x71a0 and 0x7160 at the end of this post:
http://groups.google.com/group/comp.os.msdos.djgpp/msg/6f05e7dd065ebbc1

Fourth, I compiled a bunch of info on DJGPP interrupt usage. I just merged
the LFN relevant info into the list below. It's for DJGPP v2.03. v2.04
supports symlinks, so there might be a few more C functions calling LFN
functions. So, if you use DJGPP, you'll have an idea of which C functions
call which LFN functions. I quickly compiled the info for personal use ...
years ago. So, I can't be certain I got everything. Sometimes an interrupt
number is split, e.g., instead of 0x710d, it's 0x71 and 0x0d, or worse ...
0x7160 is is interesting in that it has 3 sub-functions. The comment below
explains.


5704h ; LFN get last access date and time
5704 DJGPP _lfn_time

5705h ; LFN set last access date and time
5705 DJGPP utime

5706h ; LFN get creation date and time
5706 DJGPP _lfn_time

5707h ; LFN set creation date and time
5707 DJGPP (not found)

710Dh ; LFN reset drive
710d DJGPP _flush_disk_cache

7139h ; LFN create directory
7139 DJGPP mkdir

713Ah ; LFN remove directory
713a DJGPP remove
713a DJGPP rmdir

713Bh ; LFN set current directory
713b DJGPP __chdir

7141h ; LFN delete file
7141 DJGPP remove

7143h ; LFN get/set file attributes
7143 DJGPP _chmod
7143 DJGPP _open
7143 DJGPP utime

7147h ; LFN get current directory
7147 DJGPP __get_current_directory
7147 DJGPP __getcwd

714Eh ; LFN find first file
714e DJGPP findfirst

714Fh ; LFN find next file
714f DJGPP findnext

7156h ; LFN move (rename) file
7156 DJGPP _rename

7160h ; LFN truename FPN (CL=00h), SFN (CL=01h), LFN (CL=02h)
7160h ; LFN /* FPN FullPathName, SFN ShortFileName, LFN LongFileName */
7160 DJGPP _truename
7160 DJGPP _open direct_exec_tail_1
7160 DJGPP _get_current_directory
7160 DJGPP symlink
7160 DJGPP _getcwd

716Ch ; LFN create/open file
716c DJGPP _open
716c DJGPP _creat
716c DJGPP _creatnew

71A0h ; LFN get volume information
71a0 DJGPP _get_volume_info

71A1h ; LFN terminate FindFirst/FindNext
71a1 DJGPP findfirst
71a1 DJGPP findnext
71a1 DJGPP _lfn_find_close

71A6h ; LFN get file information
71a6 DJGPP get_sft_entry

71A7h ; LFN time conversion DOS_to_FILE (BL=00h), FILE_to_DOS (BL=01h)
71a7 DJGPP (not found)

71A8h ; LFN generate short filename
71a8 DJGPP _lfn_gen_short_fname

71A9h ; LFN server create/open file
71a9 DJGPP (not found)

71AAh ; LFN SUBST create (BH=00h), terminate (BH=01h), query (BH=02h)
71aa DJGPP (not found)


HTH,


Rod Pemberton
PS. Four comments and one print statement near the bottom have wrapped.


/* LFNTST.C by Rod Pemberton */
/* This program inspired by Andrew Crabtree's LFNTEST.ASM (NT-LFN driver) */
/* (I got tired of working in assembly... :{ */
/* To reduce coding issues, as much code as possible came from within
DJGPP... */
/* This program was originally used to try to improve Chris Jone's LFNDOS
driver */
/* However, Henrik Haftmann's DOSLFN driver works perfectly */
/* An #define below decides if you have a LFN test program or clean LFN
library */
/* gcc -o LFNTEST.EXE LFNTEST.C */

#include <dir.h> /* ffblk ffblklfn */
#include <dos.h> /* _get_drive */
#include <go32.h> /* __tb _dos_ds */
#include <dpmi.h> /* __dpmi_int */
#include <libc/dosio.h> /* __tb_segment __tb_offset _put_path
_put_path2 */
#include <stdio.h> /* printf */
#include <ctype.h>
#include <stdlib.h> /* malloc */
#include <strings.h> /* malloc */
#include <sys/movedata.h> /* movedata dosmemget */
#include <sys/farptr.h> /* farpeekb */
#include <fcntl.h> /* _get_volume_info */

__dpmi_regs r;

#define dot_char(x) (isprint(x)?(x):('.'))
void dump_tb(void)
{
int ctr;
for (ctr=0;ctr<1024;ctr++)
printf("%c",dot_char(_farpeekb(_dos_ds,__tb+ctr)));
}

void dump_tbh(void)
{
int ctr;
for (ctr=0;ctr<1024;ctr++)
printf("%02X",_farpeekb(_dos_ds,__tb+ctr));
}

void hex(unsigned long func)
{
printf ("0x%04lX ",func);
}

void hexnl(unsigned long func)
{
hex(func);
printf (" \n");
}

void pass(unsigned long func)
{
hex(func);
printf ("Passed! \n");
}

void fail(unsigned long func)
{
hex(func);
printf ("Failed! \n");
}

void pass_fail(unsigned long func)
{
if (!(r.x.flags & 1))
pass(func);
else
fail(func);
}

void dump_st(char *st)
{
int ctr,stl;
stl = strlen(st);
// hexnl(stl);
for (ctr=0;ctr<=stl;ctr++)
printf("%c",*st++);
printf("\n");
}

void dump_sth(char *st)
{
int ctr,stl;
stl = strlen(st);
// hexnl(stl);
for (ctr=0;ctr<=stl;ctr++)
printf("%02X",*st++);
printf("\n");
}

void lfn_710D(int drive)
{
r.x.ax = 0x710d;
r.x.cx = 1;
r.x.dx = drive;
r.x.flags |= 1;
__dpmi_int (0x21, &r);
}

void lfn_71A0(char *mpath)
{
dosmemput( mpath, 32,__tb);
r.x.ax = 0x71a0;
r.x.ds = __tb_segment;
r.x.dx = __tb_offset;
r.x.es = __tb_segment;
r.x.di = __tb_offset + 260;
r.x.cx = 32;
r.x.flags |= 1;
__dpmi_int(0x21, &r);
dosmemget(__tb+260, 32, mpath);
}

void lfn_7139(char *mpath)
{
dosmemput(mpath, 260,__tb);
r.x.ax = 0x7139;
r.x.ds = __tb_segment;
r.x.dx = __tb_offset;
r.x.flags |= 1;
__dpmi_int(0x21, &r);
}

void lfn_713B(char *mpath)
{
dosmemput( mpath, 260,__tb);
r.x.ax = 0x713b;
r.x.ds = __tb_segment;
r.x.dx = __tb_offset;
r.x.flags |= 1;
__dpmi_int(0x21, &r);
}

void lfn_7147(char *mpath, int drive)
{
r.x.ax = 0x7147;
r.h.dl = drive;
r.x.ds = __tb_segment;
r.x.si = __tb_offset;
r.x.flags |= 1;
__dpmi_int(0x21, &r);
dosmemget(__tb, 260, mpath);
}

void lfn_71A8(char *mpath, int dh)
{
dosmemput(mpath, 255, __tb);
r.x.ax = 0x71a8;
r.x.ds = __tb_segment;
r.x.si = __tb_offset;
r.x.es = __tb_segment;
r.x.di = __tb_offset + 260;
r.h.dh = dh;
r.h.dl = 0x11;
r.x.flags |= 1;
__dpmi_int (0x21, &r);
dosmemget(__tb+260, 255, mpath);
mpath[11+r.h.dh]=0;
}

void lfn_716C(char *mpath, unsigned *fhandle)
{
dosmemput( mpath, 260,__tb);
r.x.ax = 0x716c;
r.x.bx = 0x0002;
r.x.cx = 0;
r.x.dx = 0x0011; /* create, open if exists */
// r.x.dx = 0x0010; /* create, fail if exists */
// r.x.dx = 0x0012; /* create, truncate if exists */
// r.x.dx = 0x0001; /* open, fail if does not exist */
// r.x.dx = 0x0002; /* truncate, fail if does not exist */
r.x.ds = __tb_segment;
r.x.si = __tb_offset;
r.x.di = 0;
r.x.flags |= 1;
__dpmi_int(0x21, &r);
*fhandle = r.x.ax;
}

void lfn_7160(char *mpath, int cl)
{
dosmemput( mpath, 261,__tb);
r.x.ax = 0x7160;
r.h.cl = cl;
r.h.ch = 0;
r.x.ds = __tb_segment;
r.x.si = __tb_offset;
r.x.es = __tb_segment;
r.x.di = __tb_offset + 261;
r.x.flags |= 1;
__dpmi_int(0x21, &r);
dosmemget(__tb+261, 255, mpath);
}

/*
void lfn_todostime(, unsigned *xtime)
{
dosdate = day + (mon<<5) + ((year-1980)<<9);
dostime = sec/2 + (min<<5) + (hour<<11);
*xtime = r.x.dx;
*xtime = (*xtime << 16) | r.x.cx;
}

void lfn_dostimeto(, unsigned *xtime)
{
dosdate = day + (mon<<5) + ((year-1980)<<9);
dostime = sec/2 + (min<<5) + (hour<<11);
*xtime = r.x.dx;
*xtime = (*xtime << 16) | r.x.cx;
}
*/

void lfn_5704(unsigned fhandle, unsigned *xtime)
{
r.x.ax = 0x5704;
r.x.bx = fhandle;
r.x.flags |= 1;
__dpmi_int (0x21, &r);
*xtime = r.x.dx;
*xtime = (*xtime << 16) | r.x.cx;
}

void lfn_5705(unsigned fhandle, unsigned xtime)
{
r.x.ax = 0x5705;
r.x.bx = fhandle;
r.x.cx = xtime & 0xFFFF;
r.x.dx = xtime >> 16;
r.x.flags |= 1;
__dpmi_int(0x21, &r);
}

void lfn_5706(unsigned fhandle, unsigned *xtime)
{
r.x.ax = 0x5706;
r.x.bx = fhandle;
r.x.flags |= 1;
__dpmi_int (0x21, &r);
*xtime = r.x.dx;
*xtime = (*xtime << 16) | r.x.cx;
}

void lfn_5707(unsigned fhandle, unsigned xtime)
{
r.x.ax = 0x5707;
r.x.bx = fhandle;
r.x.cx = xtime & 0xFFFF;
r.x.dx = xtime >> 16;
r.x.si = 0;
r.x.flags |= 1;
__dpmi_int(0x21, &r);
}

void lfn_71A6(unsigned fhandle)
{
r.x.ax = 0x71a6;
r.x.bx = fhandle;
r.x.ds = __tb_segment;
r.x.dx = __tb_offset;
r.x.flags |= 1;
__dpmi_int(0x21, &r);
// dosmemget(__tb, 0x34, ?buf);
}

void lfn_7156(char *mpath, char *mpath2)
{
dosmemput( mpath, 260,__tb);
dosmemput( mpath2, 260,__tb+260);
r.x.ax = 0x7156;
r.x.ds = __tb_segment;
r.x.dx = __tb_offset;
r.x.es = __tb_segment;
r.x.di = __tb_offset + 260;
r.x.flags |= 1;
__dpmi_int(0x21, &r);
}

void lfn_7141(char *mpath, int si)
{
dosmemput( mpath, 260,__tb);
r.x.ax = 0x7141;
r.x.ds = __tb_segment;
r.x.dx = __tb_offset;
r.x.si = si;
r.h.cl = 0x0;
r.h.ch = 0x0;
r.x.flags |= 1;
__dpmi_int(0x21, &r);
}

void lfn_713A(char *mpath)
{
dosmemput( mpath, 260,__tb);
r.x.ax = 0x713a;
r.x.ds = __tb_segment;
r.x.dx = __tb_offset;
r.x.flags |= 1;
__dpmi_int(0x21, &r);
}

void lfn_714E(char *mpath, char *mpath2, unsigned *fhandle)
{
dosmemput( mpath, 260,__tb);
r.x.ax = 0x714e;
r.h.cl = 0;
r.h.ch = 0;
r.x.si = 1;
r.x.ds = __tb_segment;
r.x.dx = __tb_offset;
r.x.es = __tb_segment;
r.x.di = __tb_offset + 260;
r.x.flags |= 1;
__dpmi_int(0x21, &r);
*fhandle = r.x.ax;
dosmemget(__tb+260+0x2C, 260, mpath);
dosmemget(__tb+260+0x130, 14, mpath2);
}

void lfn_714F(char *mpath, char *mpath2, unsigned fhandle)
{
r.x.ax = 0x714f;
r.x.bx = fhandle;
r.x.si = 1;
r.x.es = __tb_segment;
r.x.di = __tb_offset;
r.x.flags |= 1;
__dpmi_int(0x21, &r);
dosmemget(__tb+0x2C, 260, mpath);
dosmemget(__tb+0x130, 14, mpath2);
}

void lfn_71A1(unsigned fhandle)
{
r.x.ax = 0x71a1;
r.x.bx = fhandle;
r.x.flags |= 1;
__dpmi_int(0x21, &r);
}


void lfn_3E(unsigned fhandle)
{
r.h.ah = 0x3E;
r.x.bx = fhandle;
r.x.flags |= 1;
__dpmi_int(0x21, &r);
}

void lfn_71AA(char *mpath, int drive, int bh)
{
dosmemput( mpath, 261,__tb);
r.x.ax = 0x71AA;
r.h.bh = bh;
r.h.bl = drive;
r.x.ds = __tb_segment;
r.x.dx = __tb_offset;
r.x.flags |= 1;
__dpmi_int(0x21, &r);
dosmemget( __tb, 261, mpath);
}


#if 0
void lfn_7143(char *mpath, int bl, unsigned cx, unsigned di)
{
dosmemput( mpath, 260,__tb);
r.x.ax = 0x7143;
r.x.ds = __tb_segment;
r.x.dx = __tb_offset;
r.h.bl = bl;
r.x.cx = cx;
r.x.di = di;
r.x.si = 0;
r.x.flags |= 1;
__dpmi_int(0x21, &r);
}

void lfn_71A7(char *qwordh, char *qwordl, unsigned *xtime, int bl)
{
dosmemput( qwordh, 4,__tb);
dosmemput( qwordl, 4,__tb+4);
r.x.ax = 0x71A7;
r.h.bl = bl;
r.h.bh = 0;
r.x.cx = xtime & 0xFFFF;
r.x.dx = xtime >> 16;
r.x.ds = __tb_segment;
r.x.si = __tb_offset;
r.x.es = __tb_segment;
r.x.di = __tb_offset;
r.x.flags |= 1;
__dpmi_int(0x21, &r);
dosmemget(__tb, 4, qwordh);
dosmemget(__tb+4, 4, qwordl);
*xtime = r.x.dx;
*xtime = (*xtime << 16) | r.x.cx;
}

/* ? */
void lfn_71A9()
{
dosmemput( mpath, 261,__tb);
r.x.ax = 0x71A9;
r.h.cl = cl;
r.h.ch = 0;
r.x.ds = __tb_segment;
r.x.si = __tb_offset;
r.x.es = __tb_segment;
r.x.di = __tb_offset + 261;
r.x.flags |= 1;
__dpmi_int(0x21, &r);
dosmemget(__tb+261, 255, mpath);

r.x.flags |= 1;
__dpmi_int(0x21, &r);
}

#endif

int main (void){

char *path,*path2;
unsigned fh,ftim,drive;

path = malloc(260);
path2 = malloc(260);
if (path==NULL||path2==NULL)
printf("error malloc\n");

/* LFN driver installation check, calls 0x71A0 */
_dos_getdrive(&drive);
sprintf(path,"%c:\\", 'A' - 1 + drive);
if ((_get_volume_info(path,0,0,0) & _FILESYS_LFN_SUPPORTED) ==0)
{
printf("No LFN support.");
exit(0);
}


printf("Testing Function 0x710D (Reset Drive) \n");
lfn_710D(0);
pass_fail(0x710d);
printf("\n");

printf("Testing LFN Function 0x71A0 (Get Volume Info) \n");
strcpy(path,"C:\\");
printf("%s\n",path);
lfn_71A0(path);
printf("%s\n",path);
pass_fail(0x71A0);
printf("\n");

printf("Testing LFN Function 0x7139 (Make Directory) \n");
strcpy(path,"C:\\TestMe LongName");
printf("%s\n",path);
lfn_7139(path);
pass_fail(0x7139);
printf("\n");

printf("Testing LFN Function 0x713B (Change Directory) \n");
strcpy(path,"C:\\TestMe LongName");
printf("%s\n",path);
lfn_713B(path);
pass_fail(0x713B);
printf("\n");

printf("Testing LFN Function 0x7147 (Get Current Directory) \n");
strcpy(path,"");
lfn_7147(path,0);
printf("%s\n",path);
pass_fail(0x7147);
printf("\n");

printf("Testing Function 0x71A8 (Generate Short Filename) \n");
strcpy(path,"Big Long Name to Test.tst");
printf("%s\n",path);
lfn_71A8(path,0);
printf("%s\n",path);
pass_fail(0x71A8);
strcpy(path,"Big Long Name to Test.tst");
lfn_71A8(path,1);
printf("%s\n",path);
pass_fail(0x71A8);
printf("\n");

// setup second file for 714F
strcpy(path,"Second Long Name to Test.tst");
lfn_716C(path,&fh);
lfn_3E(fh);

printf("Testing LFN Function 0x716C (Create/Open File) \n");
strcpy(path,"Big Long Name to Test.tst");
printf("%s\n",path);
lfn_716C(path,&fh);
pass_fail(0x716C);
printf("\n");

printf("Testing LFN Function 0x7160 (Get True/Short/Long Name) \n");
printf("Testing CL = 0x0 \n");
strcpy(path,"Big Long Name to Test.tst");
printf("%s\n",path);
lfn_7160(path,0);
printf("%s\n",path);
pass_fail(0x7160);
printf("\n");
printf("Testing CL = 0x1 \n");
strcpy(path,"Big Long Name to Test.tst");
printf("%s\n",path);
lfn_7160(path,1);
printf("%s\n",path);
pass_fail(0x7160);
printf("\n");
printf("Testing CL = 0x2 \n");
strcpy(path,"BIGLON~1.TST");
printf("%s\n",path);
lfn_7160(path,2);
printf("%s\n",path);
pass_fail(0x7160);
printf("\n");

printf("Testing Function 0x5704 (Get Last Access) \n");
lfn_5704(fh,&ftim);
pass_fail(0x5704);
printf("\n");

printf("Testing Function 0x5705 (Set Last Access) \n");
lfn_5705(fh,ftim);
pass_fail(0x5705);
printf("\n");

printf("Testing Function 0x5706 (Get Creation Date/Time) \n");
lfn_5706(fh,&ftim);
pass_fail(0x5706);
printf("\n");

printf("Testing Function 0x5707 (Set Creation Date/Time) \n");
lfn_5707(fh,ftim);
pass_fail(0x5707);
printf("\n");

printf("Testing LFN Function 0x71A6 (Get File Info By Handle) \n");
lfn_71A6(fh);
pass_fail(0x71A6);
printf("\n");

/* can't rename an open file in W98, must close first */
printf("Testing Function 0x3E (Close File) \n");
lfn_3E(fh);
pass_fail(0x3E);
printf("\n");

printf("Testing LFN Function 0x714E (Find First File) \n");
strcpy(path,"*.*");
strcpy(path2,"");
printf("%s\n",path);
lfn_714E(path,path2,&fh);
printf("%s\n",path);
printf("%s\n",path2);
pass_fail(0x714E);
printf("\n");

printf("Testing LFN Function 0x714F (Find Next File) \n");
strcpy(path,"");
strcpy(path2,"");
lfn_714F(path,path2,fh);
printf("%s\n",path);
printf("%s\n",path2);
pass_fail(0x714F);
printf("\n");

printf("Testing LFN Function 0x71A1 (Terminate Directory Search) \n");
lfn_71A1(fh);
pass_fail(0x71A1);
printf("\n");

printf("Testing Function 0x7156 (Rename File) \n");
strcpy(path,"Big Long Name to Test.tst");
printf("%s\n",path);
strcpy(path2,"Another Big Long name.tst");
printf("%s\n",path2);
lfn_7156(path,path2);
pass_fail(0x7156);
printf("\n");

printf("Testing Function 0x7156 (Rename File) \n");
strcpy(path,"Another Big Long name.tst");
printf("%s\n",path);
strcpy(path2,"junkit.tst");
printf("%s\n",path2);
lfn_7156(path,path2);
pass_fail(0x7156);
printf("\n");

//delete second file for 714F
strcpy(path,"Second Long Name to Test.tst");
lfn_7141(path,0);

printf("Testing Function 0x7141 (Delete File) \n");
strcpy(path,"junkit.tst");
printf("%s\n",path);
lfn_7141(path,0);
pass_fail(0x7141);
printf("\n");

strcpy(path,"*.*");
lfn_7141(path,1);

printf("Testing Function 0x71AA (Create/Terminate/Query Subst) \n");
printf("Testing BH = 0x0 \n");
strcpy(path,"C:\\TestMe LongName");
printf("%s\n",path);
lfn_71AA(path,1,0);
pass_fail(0x71AA);
printf("\n");

printf("Testing BH = 0x2 \n");
strcpy(path,"");
lfn_71AA(path,1,2);
printf("%s\n",path);
pass_fail(0x71AA);
printf("\n");

printf("Testing BH = 0x1 \n");
strcpy(path,"");
lfn_71AA(path,1,1);
pass_fail(0x71AA);
printf("\n");

printf("Testing LFN Function 0x713A (Remove Directory) \n");
strcpy(path,"..");
lfn_713B(path);
strcpy(path,"C:\\TestMe LongName");
printf("%s\n",path);
lfn_713A(path);
pass_fail(0x713A);
printf("\n");

#if 0
printf("Testing Function 0x7143 (Extended Get/Set File Attributes)
\n");
printf("Testing BL = 0x0 \n");
lfn_7143(path,? bl,cx,di);
pass_fail(0x7143);
printf("Testing BL = 0x1 \n");
lfn_7143(path,? bl,cx,di);
pass_fail(0x7143);
printf("Testing BL = 0x2 \n");
lfn_7143(path,? bl,cx,di);
pass_fail(0x7143);
printf("Testing BL = 0x3 \n");
lfn_7143(path,? bl,cx,di);
pass_fail(0x7143);
printf("Testing BL = 0x4 \n");
lfn_7143(path,? bl,cx,di);
pass_fail(0x7143);
printf("Testing BL = 0x5 \n");
lfn_7143(path,? bl,cx,di);
pass_fail(0x7143);
printf("Testing BL = 0x6 \n");
lfn_7143(path,? bl,cx,di);
pass_fail(0x7143);
printf("Testing BL = 0x7 \n");
lfn_7143(path,? bl,cx,di);
pass_fail(0x7143);
printf("Testing BL = 0x8 \n");
lfn_7143(path,? bl,cx,di);
pass_fail(0x7143);
printf("\n");
#endif

#if 0
printf("Testing Function 0x71A7 (Dos/File Time to File/Dos Time) \n");
printf("Testing BL = 0x0 \n");
lfn_71A7(qwh,qwl,&ftim,0);
pass_fail(0x71A7);
printf("\n");
printf("Testing BL = 0x1 \n");
lfn_71A7(&qwh,&qwl,ftim,1);
pass_fail(0x71A7);
printf("\n");
#endif

#if 0
printf("Testing Function 0x71A9 (Server Create/Open File) \n");
lfn_71A9();
#endif

exit(0);
}

[cg_chas]

On Sun, 13 May 2012 03:24:12 -0400, "Rod Pemberton"

Good stuff.

It seems we both chose a similar approach in that we both wrote test programs
prior to developing improvements for existing LFN code.

When I get to protected mode with my current project, I will be sure to refer
back to this thread and the links within.

For now, I am limiting what I am doing to 16-bit, at least until I identify
the issues I am currently having with the other LFN TSRs, DOS 7.10, and FAT16.

Even if one of the issues turns out to be exclusive to VirtualBox or emulators
in general where doslfn is concerned, I'd still like to know why exactly so I
can explore the possibilities for correction or improvement in my code.

Here's an example. My file manager has a function for getting all of the valid
drive letters. This means identifying a drive's type as well as determining if
it is ready, and if it ready the letter is placed into a kind of list view.
One of the things this routine does for actual disks is make an Int 13/AH=02h
call to read a sector. The results of this call determines the readiness for
a given disk. Under DosBox, however, this call returns 0xFF. So, I handle
this case with some extra checking to see if the environment is actually
DOSBox and not a legitimate 0xFF.

My sense at this point is that it is possible (I am not yet certain) that
similar handling might be needed for LFN for DOS in an emulated hardware
environment. Ideally it shouldn't, but for the case of doslfn, I do believe
you when you say that it works perfectly. I just happened to have stumbled
onto some contexts where doslfn does not work perfecly and LFNDOS works
better, or, and I haven't ruled this out, there are bugs in VirtualBox
regarding basic file system stuff. I happen to doubt the latter given that
LFNDOS, while is not perfect in every regard that I have observed, does not
DIR out garbage under VirtualBox like doslfn does. In fact LFNDOS seems to
work well with the exception of some cases where it can fail to create files
under a long directory name.

Fun things to look forward to this upcoming week :)

Thank you again for the input. Not having to reinvent the wheel at every turn
will likely result in time savings.

Charles

[Rugxulo]

Hi,

On May 13, 8:21 am, cg_chas <cg_c...@hotmail.com> wrote:
>
> For now, I am limiting what I am doing to 16-bit, at least until I identify
> the issues I am currently having with the other LFN TSRs, DOS 7.10, and FAT16.
> Even if one of the issues turns out to be exclusive to VirtualBox or emulators
> in general where doslfn is concerned, I'd still like to know why exactly so I
> can explore the possibilities for correction or improvement in my code.

It's hard to test in every environment, and surely some things don't
work everywhere. I've not used LFNDOS or old DOSLFN 0.32, but current
DOSLFN 0.41b seems to work fine for me (FreeDOS, FAT32). StarLFN, in
limited use, also seems to work. Note that I don't do anything heavy
with it, just occasional use. Mostly I avoid it because I don't
personally prefer it, but sometimes you gotta use it for other
packages. Anyways, it slows down like 2x. Oh, before I forget, Odi's
tools don't work for me here, perhaps my HD is too big or there is
some other latent bug. Similarly LTOOLS, go figure. Yeah, something
always stops working for me.

VirtualBox does have bugs, but I don't know if they are recent
regressions or not. I know some things only appear when VT-X is
unavailable / disabled (e.g. my laptop). Annoying, but not much you
can do. DOSBox didn't work with any LFN TSRs, last I checked, but I
didn't try too hard. This is part of the reason why other environments
(WinXP's NTVDM, Linux's DOSEMU) are sometimes convenient.

> Here's an example. My file manager has a function for getting
> all of the valid drive letters.

Let me briefly mention, DJGPP's mntent() function is highly capable in
this regard, even if you're doing it from scratch in 16-bit, it's a
very good reference, so I'd be remiss not to mention it for
completeness:

http://www.delorie.com/bin/cvsweb.cgi/djgpp/src/libc/compat/mntent/mntent.c?rev=1.12

A quick compile with -DTEST should show you what you have.

> I happen to doubt the latter given that
> LFNDOS, while is not perfect in every regard that I have observed, does not
> DIR out garbage under VirtualBox like doslfn does.

You could always run DOSFSCK on the drive to "fix" any minor file
system errors there. It does support LFNs.

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/chkdsk/dosfsck/

> In fact LFNDOS seems to
> work well with the exception of some cases where it can fail to create files
> under a long directory name.

I don't know if that's the old DOS limitation or something new.
Confusing and annoying, but most of us wimps tend to avoid weird stuff
anyways.

> Fun things to look forward to this upcoming week :)
>
> Thank you again for the input. Not having to reinvent the wheel at every turn
> will likely result in time savings.

I'm not much help with TSRs or anything, so I'll toss all this back to
Rod. Hope I didn't intrude too heavily in your conversation.

[cg_chas]

On Sun, 13 May 2012 09:21:10 -0400, cg_chas <cg_...@hotmail.com> wrote:


>My sense at this point is that it is possible (I am not yet certain) that
>similar handling might be needed for LFN for DOS in an emulated hardware
>environment. Ideally it shouldn't, but for the case of doslfn, I do believe
>you when you say that it works perfectly. I just happened to have stumbled
>onto some contexts where doslfn does not work perfecly and LFNDOS works
>better, or, and I haven't ruled this out, there are bugs in VirtualBox
>regarding basic file system stuff. I happen to doubt the latter given that
>LFNDOS, while is not perfect in every regard that I have observed, does not
>DIR out garbage under VirtualBox like doslfn does. In fact LFNDOS seems to
>work well with the exception of some cases where it can fail to create files
>under a long directory name.

>
>Fun things to look forward to this upcoming week :)
>

So I picked this back up this morning and here are some quick observations:

Using MS-DOS 7.1 under VirtualBox-4.1.14-77440
Regarding the issue with the garbage after Program Files when doing DIR C:\

DOSLFN 0.40e (Jason Hood) DOES exhibit this issue
DOSLFN 0.41b (Jason Hood) DOES exhibit this issue

ODI's LDIR 1.79 DOES NOT exhibit this issue

LFNDOS 1.06 DOES NOT exhibit this issue, however:

When extracting using PKUNZIP -d (version 2.50 that supports DOS long file
names) from gcc462b.zip, for example, PKUNZIP spits out a series of Warning!
can't create: file errors.

When extracting using UNZIP32 (version 6.00 that supports DOS long file names)
from gcc462b.zip, for example, UNZIP32 spits out a series of checkdir error:
cannot create file. This seems to be happening with long directory names.

I believe this is a bug with LFNDOS that I had intentions to look into.

However,

DOSLFN 0.32o (Henrik Haftmann) DOES NOT exhibit this issue or any of the
other. So far, it is the only TSR I have been able to successfully unzip and
run djgpp 4.62 with from real mode DOS. I tested DOSLFN 0.32o using unzip32
and pkzip and djgpp 4.62 works.

I just wanted to clear that up because I know you said specifically that
DOSLFN 0.32o works well and I agree completely.

Charles

[Rod Pemberton]

"cg_chas" <cg_...@hotmail.com> wrote in message

news:pi22r7l8p6kd8un01...@4ax.com...

> On Sun, 13 May 2012 09:21:10 -0400, cg_chas <cg_...@hotmail.com> wrote:

...

> > [LFNDOS issues]

>
> So I picked this back up this morning and here are some quick
> observations:
>
> Using MS-DOS 7.1 under VirtualBox-4.1.14-77440
> Regarding the issue with the garbage after Program Files when
> doing DIR C:\
>
> DOSLFN 0.40e (Jason Hood) DOES exhibit this issue
> DOSLFN 0.41b (Jason Hood) DOES exhibit this issue
>
> ODI's LDIR 1.79 DOES NOT exhibit this issue
>
> LFNDOS 1.06 DOES NOT exhibit this issue, however:
>
> When extracting using PKUNZIP -d (version 2.50 that supports DOS
> long file names) from gcc462b.zip, for example, PKUNZIP spits out
> a series of Warning! can't create: file errors.
>
> When extracting using UNZIP32 (version 6.00 that supports DOS long
> file names) from gcc462b.zip, for example, UNZIP32 spits out a series
> of checkdir error: cannot create file. This seems to be happening with
> long directory names.
>
> I believe this is a bug with LFNDOS that I had intentions to look into.
>
> However,
>
> DOSLFN 0.32o (Henrik Haftmann) DOES NOT exhibit this issue or
> any of the other. So far, it is the only TSR I have been able to
> successfully unzip and run djgpp 4.62 with from real mode DOS.
> I tested DOSLFN 0.32o using unzip32 and pkzip and djgpp 4.62 works.
>
> I just wanted to clear that up because I know you said specifically that
> DOSLFN 0.32o works well and I agree completely.
>

PKZIP/PKUNZIP 2.04g has no LFN support, IIRC.
PKZIP/PKUNZIP 2.50 has LFN support, IIRC.

For Windows, I use WinZip and 7-Zip. For DOS, I use PKZIP/PKUNZIP
2.04g and 2.50. FYI, there are a few ancient .zip's that'll *only* work
with 2.04g. Today, I use 7-Zip exclusively. I don't think I've ever
used DJGPP's UNZIP utility. I might've tried it a few times, but I
generally don't use it. IIRC, I did use Info-ZIP for DOS once, but mostly I
used it in a enterprise server environment.


I'm not seeing the LFN corruption issue. I've tried these:

DOSLFN 0.32o
DOSLFN 0.34b
DOSLFN 0.40e
DOSLFNMS 0.40e
DOSLFN 0.41b
DOSLFNMS 0.41b


DOSLFNMS according to doslfn.txt:

"DOSLFNMS is intended for use with MS-DOS 7
(but may also work with FreeDOS)
and also has some features removed to reduce its size:"


The DOSLFN changelog.txt says a DIR problem was fixed with 0.40c
and another directory issue with 0.40c. I'd suspect one of those ...
Next, I'd suspect the SCSUCDX changes in 0.34, 0.40, 0.40a.


Hopefully, the old versions are still available on Jason's site. But, if
not, I have the following versions:

0.32e
0.32n (1/03)
0.32n (3/03)
0.32o (HH final)
0.32o (JH 5/03)
0.32o (JH 10/03)
0.40c
0.40e
0.40f
0.41
0.41a
0.41b

Let me know if you need them packed up. If you can find someone else with
the other versions, you might be able to determine which one created the
issue. Not to volunteer anyone, but maybe Rugxulo can help with that or
direct you to someone with the other versions.


Rod Pemberton

[Rugxulo]

Hi,

On May 14, 10:46 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
wrote:

>
> Let me know if you need them packed up.  If you can find someone else with
> the other versions, you might be able to determine which one created the
> issue.  Not to volunteer anyone, but maybe Rugxulo can help with that or
> direct you to someone with the other versions.

All I know of, offhand, are these:

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/system/doslfn/

0.33/ 21-Jan-2008 20:38
0.34/ 21-Jan-2008 20:38
0.40/ 21-Jan-2008 20:37
0.41/ 07-Feb-2012 10:50

For completeness, Chris Jones' LFNDOS (1.06, circa 1999, but no srcs)
is here:

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/system/lfndos.zip

[cg_chas]

On Mon, 14 May 2012 23:46:23 -0400, "Rod Pemberton"
<do_no...@notemailntt.cmm> wrote:

>"cg_chas" <cg_...@hotmail.com> wrote in message
>news:pi22r7l8p6kd8un01...@4ax.com...
>> On Sun, 13 May 2012 09:21:10 -0400, cg_chas <cg_...@hotmail.com> wrote:
>...

>I'm not seeing the LFN corruption issue. I've tried these:
>
>DOSLFN 0.32o
>DOSLFN 0.34b
>DOSLFN 0.40e
>DOSLFNMS 0.40e
>DOSLFN 0.41b
>DOSLFNMS 0.41b

Just curious, did you try under VirtualBox too?

If you pack them up and put them somewhere for me, I'll test them all and see
which version introduced the bug.

Charles

>
>
>Rod Pemberton
>
>

[cg_chas]

On Sun, 13 May 2012 07:00:55 -0700 (PDT), Rugxulo <rug...@gmail.com> wrote:

>Hi,

>
>> Here's an example. My file manager has a function for getting
>> all of the valid drive letters.
>
>Let me briefly mention, DJGPP's mntent() function is highly capable in
>this regard, even if you're doing it from scratch in 16-bit, it's a
>very good reference, so I'd be remiss not to mention it for
>completeness:
>
>http://www.delorie.com/bin/cvsweb.cgi/djgpp/src/libc/compat/mntent/mntent.c?rev=1.12
>
>A quick compile with -DTEST should show you what you have.

Thank you.

>
>> I happen to doubt the latter given that
>> LFNDOS, while is not perfect in every regard that I have observed, does not
>> DIR out garbage under VirtualBox like doslfn does.
>
>You could always run DOSFSCK on the drive to "fix" any minor file
>system errors there. It does support LFNs.
>
>http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/chkdsk/dosfsck/

There are no file system errors. I run scandisk on every boot in my MS-DOS
development environments and sometimes more than once during development
sessions when dealing with disks.

Only the recent versions of DOSLFN seems to be doing this, but DOSLFN 0.32.o
does not do this and either does LFNDOS.

>
>> In fact LFNDOS seems to
>> work well with the exception of some cases where it can fail to create files
>> under a long directory name.
>
>I don't know if that's the old DOS limitation or something new.
>Confusing and annoying, but most of us wimps tend to avoid weird stuff
>anyways.

I think it is a bug with LFNDOS. DOSLFN 0.32.o, for example, does not have
this problem, so I don't think it can be a DOS limitation in this particular
instance.

Another issue with LFNDOS is actually when trying to compile with DJGPP. If I
unpack all of the necessary DJGPP archives from within Win98, or from DOS
using DOSLFN 0.32.o, when compiling using DJGPP, it cannot find all of the
files it needs. Again, this is specific to using LFNDOS and it seems to have
to do with long directory names. I am guessing this is related to the same
bug.

My initial intentions here were to resume where LFNDOS left off. I had
considered this despite knowing that it was slower and uses considerably more
memory than DOSLFN, but this is when I thought that DOSLFN had more severe
bugs. Now I think I was mistaken with that assumption. DOSLFN 0.32.o, while
not perfect, does not have any of the bugs that were motivating me to start
writing patches. Also, newer versions of DOSLFN have corrected bugs and have
added functionality to DOSLFN despite the recent versions of DOSLFN having
this issue under VirtualBox.

I think what I will do first is try to find the version of DOSLFN that
presented the incompatibility and go from there. I realize now that this may
all be specific to VirtualBox, but given that some versions do not have this
issue with VirtualBox, I am running with the assumption that there was a
revision to DOSLFN that FAT under VirtualBox does not seem to like. It
remains to be seen what the nature of the incompatibility is.

>
>> Fun things to look forward to this upcoming week :)
>>
>> Thank you again for the input. Not having to reinvent the wheel at every turn
>> will likely result in time savings.
>
>I'm not much help with TSRs or anything, so I'll toss all this back to
>Rod. Hope I didn't intrude too heavily in your conversation.

It was no intrusion at all! just the opposite in fact. You all are the ones
keeping this group alive.

[cg_chas]

I went ahead and tested what I did have. I got most of these from the link
that Rugxulo posted. Thank you Rugxulo.

The test was a simple DIR C:\ under MS-DOS 7.10 FAT16 under VirtualBox 4.1.14.

0.32o pass
0.33 fail
0.34 (doslfnm) fail
0.34d (doslfnm) fail
0.40 fail
0.40a fail
0.40e fail
0.41b fail

Pass means no garbage in the long directory name.
Fail means garbage in the long directory name.

My results indicate the problem occured early on. Perhaps with the very first
JH revision, but I need some of your archives to verify that.

Given this, if you do not wish to post your entire archive (although for
completeness, the entire archive would be appreciated), I would still at least
be interested in looking at:

0.32e
0.32n (1/03)
0.32n (3/03)

0.32o (JH 5/03)
0.32o (JH 10/03)

I am not finding the above online.

Charles

[Rod Pemberton]

"cg_chas" <cg_...@hotmail.com> wrote in message

news:a1i4r7t7bajtcgl3o...@4ax.com...

> On Mon, 14 May 2012 23:46:23 -0400, "Rod Pemberton"
> <do_no...@notemailntt.cmm> wrote:
...


> >I'm not seeing the LFN corruption issue. I've tried these:
> >
> >DOSLFN 0.32o
> >DOSLFN 0.34b
> >DOSLFN 0.40e
> >DOSLFNMS 0.40e
> >DOSLFN 0.41b
> >DOSLFNMS 0.41b
>
> Just curious, did you try under VirtualBox too?
>

Sorry, I don't have VirtualBox installed.

> >The DOSLFN changelog.txt says a DIR problem was fixed with 0.40c
> >and another directory issue with 0.40c.

Oops. I think that should've been 0.40a and 0.40c ...

> If you pack them up and put them somewhere for me, I'll test them all and
> see which version introduced the bug.
>

Ok.


Rod Pemberton

[Rod Pemberton]

"cg_chas" <cg_...@hotmail.com> wrote in message

news:7rm4r7h0g1oq33m71...@4ax.com...
...

> Given this, if you do not wish to post your entire archive (although for
> completeness, the entire archive would be appreciated), I would still at
> least be interested in looking at:
>
> 0.32e
> 0.32n (1/03)
> 0.32n (3/03)
> 0.32o (JH 5/03)
> 0.32o (JH 10/03)
>

About 50% of the doslfn zip files I have were named "DOSLFN.ZIP".

Sigh ... :)

So, I renamed those using underscores, version info, and initials. If you
see an underscore, that's my naming.

Then, I decided to check their MD5 sums so that I wouldn't send duplicates
of the Ibiblio files. (FYI, MD5SUM.exe is available with DJGPP.)

for %1 in (*.zip) do md5sum %1 >> sums.txt

All of the ones you requested didn't match Ibiblio's files. So, all of
those you requested, and three more, are included. The doslfn_32ohh.zip is
the final version from Henrik's website. So, you can probably delete that,
assuming you got it and Jason Hood's latest. The original 032.o files I
have, didn't include source. It seems I deleted the zip for them...
However, it's DOSLFN.COM is the same binary as in doslfn_32ohh.zip,
so I didn't include it.


Link:
http://www.filedropper.com/lfnp


Based on the MD5 sums,

These from Ibiblio weren't in my set:
doslfnjh-0.33.zip
doslfnm-0.34.zip
doslfn-0.40.zip
doslfn-0.40a.zip

These from Ibiblio were duplicated with those in my set:
doslfn-0.40e.zip doslfn_40ejh.zip
doslfn041b.zip doslfn041b.zip
doslfn041a.zip doslfn041a.zip
doslfn41.zip doslfn41.zip

These in my set are not on Ibiblio:
DOSLF40F.ZIP
doslfnjh_32o.zip
doslfn_32ohh.zip
doslfn_32e.zip
DOSLFN_32n.ZIP
DOSLFN_32n2.ZIP
doslfnm_32ojh.zip
doslfn_40cjh.zip


Rod Pemberton

[Rod Pemberton]

"cg_chas" <cg_...@hotmail.com> wrote in message

news:ote4r7tjhf1qi8m0u...@4ax.com...

> On Sun, 13 May 2012 07:00:55 -0700 (PDT), Rugxulo <rug...@gmail.com>
wrote:

...

> [...] when compiling using DJGPP, [DJGPP] cannot find all of the

> files it needs. Again, this is specific to using LFNDOS and it seems to
> have to do with long directory names. I am guessing this is related to
> the same bug.
>

Generally, I use DJGPP in a Windows console to compile. However, when I'm
compiling in DOS, I don't automatically run DOSLFN. In fact, I rarely use
DOSLFN with DJGPP in DOS. Most of DJGPP's filenames, and my own, are 8.3
compliant. I.e., wait until it complains, then run an LFN driver.

IIRC, there are certain DJGPP files that need LFNs enabled for DJGPP to find
them. From what I've seen, these are usually POSIX related files.

One such example is "syslimits.h" gets included occasionally. I don't know
why. It's not in the normal include directory. Nothing in the normal
include directory actually seems to include it... You might ask on
comp.os.msdos.djgpp. The Google Groups archive of c.o.m.d. shows
people asking about the issue a very infrequently.

To fix the issue in DOS, you have to run an LFN driver, such as DOSLFN, and
also set DJGPP's LFN variable as LFN=y in DJGPP.ENV. LFN=y should be the
default. Some people compile for pure DOS without LFNs by using LFN=n. Or,
you have to rename "syslimits.h" to "syslimit.h" (8.3) by removing the "s"
and change the included name in the sources to "syslimit.h" by removing the
"s". Or you can change the name in the source to whatever SFN is in use,
e.g., "syslim~1.h". Or, you can change the source code to use a different
include with the needed include info. All of that's fine for your source or
the source you're trying to compile, but I don't know where that gets
included when DJGPP system files wants it...

For a Windows console, LFNs are provided by Windows, so it shouldn't be an
issue for compiling. Compiling is much faster under Win98/SE too.


Rod Pemberton

[Rugxulo]

Hi,

On May 15, 6:46 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
wrote:
> "cg_chas" <cg_c...@hotmail.com> wrote in message
>
> news:ote4r7tjhf1qi8m0u...@4ax.com...> On Sun, 13 May 2012 07:00:55 -0700 (PDT), Rugxulo <rugx...@gmail.com>
>
> wrote:

I didn't actually write this, but whatever. :-)

> > [...] when compiling using DJGPP, [DJGPP] cannot find all of the
> > files it needs.  Again, this is specific to using LFNDOS and it seems to
> > have to do with long directory names.  I am guessing this is related to
> > the same bug.

If it only appears with one TSR, then it's probably that one's fault.
But I can't say without testing.

> Generally, I use DJGPP in a Windows console to compile.  However, when I'm
> compiling in DOS, I don't automatically run DOSLFN.  In fact, I rarely use
> DOSLFN with DJGPP in DOS.  Most of DJGPP's filenames, and my own, are 8.3
> compliant.  I.e., wait until it complains, then run an LFN driver.

LFNs in pure DOS slow things down a lot. Juan recompiled DJGPP libc
with and without LFNs, and it was a big difference, like two times
slower with than without. This is no huge surprise, but indeed it's
worth mentioning in case you want fastest speed.

> IIRC, there are certain DJGPP files that need LFNs enabled for DJGPP to find
> them.  From what I've seen, these are usually POSIX related files.
>
> One such example is "syslimits.h" gets included occasionally.  I don't know
> why.  It's not in the normal include directory.  Nothing in the normal
> include directory actually seems to include it...  You might ask on
> comp.os.msdos.djgpp.  The Google Groups archive of c.o.m.d. shows
> people asking about the issue a very infrequently.

This is only confusing because they are trying to support both DOS 8.3
and Win9x LFN systems at the same time. If your unzipper supports LFNs
(e.g. compiled by DJGPP v2), it will use whatever is available.
However, if you wish to use DJGPP (having been installed with LFNs
available) under plain DOS *without* LFNs, you'll be missing some
files as they will be misnamed.

So you have to unpack again in SFN-only mode to work in SFNs. In pure
DOS 8.3, a file named "longfilename.txt" will be truncated to
"longfile.txt" whereas under LFN the SFN is probably "longfi~1.txt" or
similar.

> To fix the issue in DOS, you have to run an LFN driver, such as DOSLFN, and
> also set DJGPP's LFN variable as LFN=y in DJGPP.ENV.   LFN=y should be the
> default.  Some people compile for pure DOS without LFNs by using LFN=n.  Or,
> you have to rename "syslimits.h" to "syslimit.h" (8.3) by removing the "s"
> and change the included name in the sources to "syslimit.h" by removing the
> "s".  Or you can change the name in the source to whatever SFN is in use,
> e.g., "syslim~1.h".  Or, you can change the source code to use a different
> include with the needed include info.  All of that's fine for your source or
> the source you're trying to compile, but I don't know where that gets
> included when DJGPP system files wants it...

It's not for normal use, at least not ANSI (though whether it's from
POSIX(es) or GCC or ..., dunno, too boring to look up). This SFN ->
LFN error only shows up if you "install" DJGPP one way and not the
other but expect it to work in either mode.

Long story short, let me just show a hypothetical example, just for
clarity:

C:\> doslfn
REM djdev204.zip, gcc462b.zip, bnu222br3.zip
C:\> for %a in (c:\tmp\*.zip) do unzip32 %a -d \djgpp
C:\> doslfn -u
REM -n means don't overwrite, it's not needed, already exists
C:\> for %a in (c:\tmp\*.zip) do unzip32 -n %a -d \djgpp

You'll have a few redundant files (same contents, different names),
but it will work both with and without LFNs, in pure DOS (8.3) or
Win9x (LFNs).

set DJGPP=c:\djgpp\djgpp.env
path c:\djgpp\bin;%PATH%
gcc -s -O2 hello.c -o hello.exe

If you really want to conserve install space, try this:

cd\djgpp
upx --best --lzma .../*.exe

> For a Windows console, LFNs are provided by Windows, so it shouldn't be an
> issue for compiling.  Compiling is much faster under Win98/SE too.

Compiling under Win9x is faster than pure DOS w/ LFNs? Probably, but
overall, it's not exactly slow under DOS. I'm sure all these various
TSRs could be sped up quite a bit, and a good cache does help a lot.

[cg_chas]

On Tue, 15 May 2012 18:59:07 -0400, "Rod Pemberton"
<do_no...@notemailntt.cmm> wrote:


>Link:
>http://www.filedropper.com/lfnp

>Rod Pemberton
>
>

I got the archive. Thank you, sir.

Here is the follow up test results.
For completeness, I have included yesterday's first, then from the archive you
just posted.

from Ibiblio:

0.32o pass
0.33 fail
0.34 (doslfnm) fail
0.34d (doslfnm) fail
0.40 fail
0.40a fail
0.40e fail
0.41b fail

from the archive you posted:

0.32e - doslfn_32e.zip - hangs system on TSR load - fail
0.32n - DOSLFN_32n.ZIP - (01/03) - pass
0.32n - DOSLFN_32n2.ZIP - (also shows as 01/03) - pass
0.32o - doslfn_32ohh.zip - (05/03) - pass
0.32o - doslfnjh_32o.zip - (& jmh 10/03) pass
0.32o - doslfnm_32ojh.zip - (shows as hh 05/03) - pass
0.40c - doslfn_40cjh.zip - fail
0.40f - DOSLF40F.ZIP (shows as 0.40e when loading) - fail

Given the above, it would seem that the bug or incompatibility was introduced
in the 0.33 revision and from what I've seen, it has remained ever since.

The chronology of the 0.32o to 0.33 revisions based on the files we have.
0.32o (05/03) hh
0.32o (10/03) hh & jmh
0.33 (07/04) hh & jmh

Unfortunately, according to the readme in 0.33, there were a total of 3 doslfn
releases of 0.32o by jmh which makes the amount of changes to consider as the
culprit cummulative from hh's 0.32o to jmh's 0.33.

I guess a next step could be to identify which functions and/or build
parameters changed in the 0.33 release from hh's official 0.32o release and go
from there.

Charles

[cg_chas]

On Wed, 16 May 2012 08:55:44 -0400, cg_chas <cg_...@hotmail.com> wrote:

>Unfortunately, according to the readme in 0.33, there were a total of 3 doslfn
>releases of 0.32o by jmh which makes the amount of changes to consider as the
>culprit cummulative from hh's 0.32o to jmh's 0.33.

Perhaps not as bad as all that, the doslfnjh_32o.zip looks like it might be
the latest of the 0.32o jmh releases, so the issue was likely introduced
between that and 0.33.
Charles

[cg_chas]

On Sun, 13 May 2012 07:00:55 -0700 (PDT), Rugxulo <rug...@gmail.com> wrote:


>
>You could always run DOSFSCK on the drive to "fix" any minor file
>system errors there. It does support LFNs.
>
>http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/chkdsk/dosfsck/
>

Out of curiosity, I just tried DOSFSCK. It finds no errors, but it does
mis-identify the filesystem as FAT32 when it should be FAT16.

[cg_chas]

... or perhaps I am misreading what is being displayed. It might be just that
the binary was compiled with those features.

dosfsck 2.11.DOS3, 8 8 Aug 2007, FAT32, LFN

Anyhow in the report it does say:
First FAT starts at byte 512 (sector 1)
2 FATs, 16 bit entries

so I am probably mistaken.

Charles

[cg_chas]

Ok so I've spent a few hours trying to get a proper debug session going with
TASM5, Turbo Debugger 5 and DOSLFN 0.33.

The MAKEFILE is listed below if anybody is interesting in seeing how I am
building.

I've tried both methods for debugging TSRs from the Turbo Debugger 5 Manual
and no dice.

This manual can be found here if anybody is interested:
http://www.bitsavers.org/pdf/borland/turbo_assembler/Turbo_Debugger_Version_5_Users_Guide.pdf
Page 138 in the guide shows the two proper methods for debugging a TSR using
TD5.

The closest I have come is:
Load the TSR.
Get the PSP address for the TSR with TDMEM.
Load TD. Load the Symbols file.
Set the table location.
Set a breakpoint at FindNext which I believe is line 686 of doslfn.asm.
The actual code is: cmp ah,4Fh
Set the debugger to resident.
do a DIR C:\ and at this point the screen starts filling with jibberish.
Returning to the debugger doesn't show anything useful at that point.

I am open to suggestions at this point.

I know there is an issue with 0.33 and all subsequent revisions of DOSLFN
where VirtualBox is concerned, but without a debugger, the project becomes
significantly more time consuming and 0.32o does work.

In the meantime, I will be considering other options.

Charles


# MAKEFILE for DOSLFN

TASM = c:\archives\tasm5\bin\tasm
TLINK = c:\archives\tasm5\bin\tlink
TDSTRIP = c:\archives\tasm5\bin\tdstrip
OPTIONS =

all: release

debug:
$(TASM) $(OPTIONS) -m5 -zi -DDEBUG doslfn.asm
$(TLINK) -3 -v -x doslfn.obj
$(TDSTRIP) -s -c doslfn.exe

release:
$(TASM) $(OPTIONS) -m5 doslfn.asm
$(TLINK) -3 -t -x doslfn.obj

lst:
$(TASM) $(OPTIONS) -m5 -l doslfn.asm

clean:
del doslfn.obj
del doslfn.com
del doslfn.tr
del doslfn.tds
del doslfn.lst
del doslfn.map
del td.tr
del tdconfig.td