Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.msdos.programmer > #561 > unrolled thread
| Started by | cg_chas <cg_chas@hotmail.com> |
|---|---|
| First post | 2012-05-07 22:21 -0400 |
| Last post | 2012-05-12 14:09 -0700 |
| Articles | 20 on this page of 32 — 5 participants |
Back to article view | Back to comp.os.msdos.programmer
lfndssrc.zip cg_chas <cg_chas@hotmail.com> - 2012-05-07 22:21 -0400
Re: lfndssrc.zip Rugxulo <rugxulo@gmail.com> - 2012-05-08 08:47 -0700
Re: lfndssrc.zip cg_chas <cg_chas@hotmail.com> - 2012-05-08 12:10 -0400
Re: lfndssrc.zip "Auric__" <not.my.real@email.address> - 2012-05-08 17:39 +0000
Re: lfndssrc.zip "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-05-09 02:24 -0400
Re: lfndssrc.zip "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-05-09 05:28 -0400
Re: lfndssrc.zip cg_chas <cg_chas@hotmail.com> - 2012-05-09 05:32 -0400
Re: lfndssrc.zip cg_chas <cg_chas@hotmail.com> - 2012-05-09 10:04 -0400
Re: lfndssrc.zip cg_chas <cg_chas@hotmail.com> - 2012-05-09 05:42 -0400
Re: lfndssrc.zip "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-10 03:44 -0400
Re: lfndssrc.zip cg_chas <cg_chas@hotmail.com> - 2012-05-11 15:35 -0400
Re: lfndssrc.zip "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-11 17:56 -0400
Re: lfndssrc.zip cg_chas <cg_chas@hotmail.com> - 2012-05-12 04:41 -0400
Re: lfndssrc.zip "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-13 03:24 -0400
Re: lfndssrc.zip cg_chas <cg_chas@hotmail.com> - 2012-05-13 09:21 -0400
Re: lfndssrc.zip cg_chas <cg_chas@hotmail.com> - 2012-05-14 10:37 -0400
Re: lfndssrc.zip "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-14 23:46 -0400
Re: lfndssrc.zip Rugxulo <rugxulo@gmail.com> - 2012-05-14 21:02 -0700
Re: lfndssrc.zip cg_chas <cg_chas@hotmail.com> - 2012-05-15 08:13 -0400
Re: lfndssrc.zip "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-15 18:54 -0400
Re: lfndssrc.zip cg_chas <cg_chas@hotmail.com> - 2012-05-15 09:51 -0400
Re: lfndssrc.zip "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-15 18:59 -0400
Re: lfndssrc.zip cg_chas <cg_chas@hotmail.com> - 2012-05-16 08:55 -0400
Re: lfndssrc.zip cg_chas <cg_chas@hotmail.com> - 2012-05-16 09:08 -0400
Re: lfndssrc.zip cg_chas <cg_chas@hotmail.com> - 2012-05-16 16:11 -0400
Re: lfndssrc.zip Rugxulo <rugxulo@gmail.com> - 2012-05-13 07:00 -0700
Re: lfndssrc.zip cg_chas <cg_chas@hotmail.com> - 2012-05-15 08:21 -0400
Re: lfndssrc.zip "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-15 19:46 -0400
Re: lfndssrc.zip Rugxulo <rugxulo@gmail.com> - 2012-05-15 17:32 -0700
Re: lfndssrc.zip cg_chas <cg_chas@hotmail.com> - 2012-05-16 10:37 -0400
Re: lfndssrc.zip cg_chas <cg_chas@hotmail.com> - 2012-05-16 10:42 -0400
Re: lfndssrc.zip Rugxulo <rugxulo@gmail.com> - 2012-05-12 14:09 -0700
Page 1 of 2 [1] 2 Next page →
| From | cg_chas <cg_chas@hotmail.com> |
|---|---|
| Date | 2012-05-07 22:21 -0400 |
| Subject | lfndssrc.zip |
| Message-ID | <fdugq7hutrgrb9skp8fdvl7rug5t0v6cft@4ax.com> |
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
[toc] | [next] | [standalone]
| From | Rugxulo <rugxulo@gmail.com> |
|---|---|
| Date | 2012-05-08 08:47 -0700 |
| Message-ID | <0e7791c8-162c-46d1-b57f-7656e2483d62@h19g2000yqj.googlegroups.com> |
| In reply to | #561 |
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
[toc] | [prev] | [next] | [standalone]
| From | cg_chas <cg_chas@hotmail.com> |
|---|---|
| Date | 2012-05-08 12:10 -0400 |
| Message-ID | <dqgiq75ptivv2iabukala0acokfi3a494u@4ax.com> |
| In reply to | #564 |
On Tue, 8 May 2012 08:47:48 -0700 (PDT), Rugxulo <rugxulo@gmail.com> wrote: >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 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
[toc] | [prev] | [next] | [standalone]
| From | "Auric__" <not.my.real@email.address> |
|---|---|
| Date | 2012-05-08 17:39 +0000 |
| Message-ID | <XnsA04D6C83366C8auricauricauricauric@88.198.244.100> |
| In reply to | #565 |
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!
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnot.cmm> |
|---|---|
| Date | 2012-05-09 02:24 -0400 |
| Message-ID | <jod2h2$hdg$1@speranza.aioe.org> |
| In reply to | #565 |
"cg_chas" <cg_chas@hotmail.com> wrote in message news:dqgiq75ptivv2iabukala0acokfi3a494u@4ax.com... > On Tue, 8 May 2012 08:47:48 -0700 (PDT), Rugxulo <rugxulo@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
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnot.cmm> |
|---|---|
| Date | 2012-05-09 05:28 -0400 |
| Message-ID | <joddbi$e32$1@speranza.aioe.org> |
| In reply to | #568 |
"Rod Pemberton" <do_not_have@notemailnot.cmm> wrote in message news:jod2h2$hdg$1@speranza.aioe.org... > "cg_chas" <cg_chas@hotmail.com> wrote in message > news:dqgiq75ptivv2iabukala0acokfi3a494u@4ax.com... > > On Tue, 8 May 2012 08:47:48 -0700 (PDT), Rugxulo <rugxulo@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
[toc] | [prev] | [next] | [standalone]
| From | cg_chas <cg_chas@hotmail.com> |
|---|---|
| Date | 2012-05-09 05:32 -0400 |
| Message-ID | <vbekq7tssvum8v27dvmsela420euvjh4v2@4ax.com> |
| In reply to | #569 |
On Wed, 9 May 2012 05:28:50 -0400, "Rod Pemberton" <do_not_have@notemailnot.cmm> wrote: >"Rod Pemberton" <do_not_have@notemailnot.cmm> wrote in message >news:jod2h2$hdg$1@speranza.aioe.org... >> "cg_chas" <cg_chas@hotmail.com> wrote in message >> news:dqgiq75ptivv2iabukala0acokfi3a494u@4ax.com... >> > On Tue, 8 May 2012 08:47:48 -0700 (PDT), Rugxulo <rugxulo@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 > Thank you sir!
[toc] | [prev] | [next] | [standalone]
| From | cg_chas <cg_chas@hotmail.com> |
|---|---|
| Date | 2012-05-09 10:04 -0400 |
| Message-ID | <faukq7llr953lsj57mtn5us9b7v9mhkrii@4ax.com> |
| In reply to | #570 |
On Wed, 09 May 2012 05:32:06 -0400, cg_chas <cg_chas@hotmail.com> wrote: >On Wed, 9 May 2012 05:28:50 -0400, "Rod Pemberton" ><do_not_have@notemailnot.cmm> wrote: > >>"Rod Pemberton" <do_not_have@notemailnot.cmm> wrote in message >>news:jod2h2$hdg$1@speranza.aioe.org... >>> "cg_chas" <cg_chas@hotmail.com> wrote in message >>> news:dqgiq75ptivv2iabukala0acokfi3a494u@4ax.com... >>> > On Tue, 8 May 2012 08:47:48 -0700 (PDT), Rugxulo <rugxulo@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! >> >>http://www.filedropper.com/lfn >> >>Click big grey download box. Asks for captcha. Enter. Download starts. >> >> >>Rod Pemberton >> > >Thank you sir!
[toc] | [prev] | [next] | [standalone]
| From | cg_chas <cg_chas@hotmail.com> |
|---|---|
| Date | 2012-05-09 05:42 -0400 |
| Message-ID | <edekq7hhnac7jap2bm9pr9jtgtt8v6a8im@4ax.com> |
| In reply to | #568 |
On Wed, 9 May 2012 02:24:02 -0400, "Rod Pemberton" <do_not_have@notemailnot.cmm> wrote: >"cg_chas" <cg_chas@hotmail.com> wrote in message >news:dqgiq75ptivv2iabukala0acokfi3a494u@4ax.com... >> On Tue, 8 May 2012 08:47:48 -0700 (PDT), Rugxulo <rugxulo@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. 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
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailntt.cmm> |
|---|---|
| Date | 2012-05-10 03:44 -0400 |
| Message-ID | <jofrkd$vst$1@speranza.aioe.org> |
| In reply to | #571 |
"cg_chas" <cg_chas@hotmail.com> wrote in message news:edekq7hhnac7jap2bm9pr9jtgtt8v6a8im@4ax.com... > On Wed, 9 May 2012 02:24:02 -0400, "Rod Pemberton" > <do_not_have@notemailnot.cmm> wrote: > >"cg_chas" <cg_chas@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
[toc] | [prev] | [next] | [standalone]
| From | cg_chas <cg_chas@hotmail.com> |
|---|---|
| Date | 2012-05-11 15:35 -0400 |
| Message-ID | <vkoqq7lqshij3mfngok9g02gkcp5fg6kou@4ax.com> |
| In reply to | #574 |
On Thu, 10 May 2012 03:44:24 -0400, "Rod Pemberton" <do_not_have@notemailntt.cmm> wrote: >"cg_chas" <cg_chas@hotmail.com> wrote in message >news:edekq7hhnac7jap2bm9pr9jtgtt8v6a8im@4ax.com... >> On Wed, 9 May 2012 02:24:02 -0400, "Rod Pemberton" >> <do_not_have@notemailnot.cmm> wrote: >> >"cg_chas" <cg_chas@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
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailntt.cmm> |
|---|---|
| Date | 2012-05-11 17:56 -0400 |
| Message-ID | <jok1tl$mlc$1@speranza.aioe.org> |
| In reply to | #575 |
"cg_chas" <cg_chas@hotmail.com> wrote in message news:vkoqq7lqshij3mfngok9g02gkcp5fg6kou@4ax.com... > On Thu, 10 May 2012 03:44:24 -0400, "Rod Pemberton" > <do_not_have@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
[toc] | [prev] | [next] | [standalone]
| From | cg_chas <cg_chas@hotmail.com> |
|---|---|
| Date | 2012-05-12 04:41 -0400 |
| Message-ID | <rs5sq7hme11emommn474of3nvclr6lmum9@4ax.com> |
| In reply to | #576 |
On Fri, 11 May 2012 17:56:43 -0400, "Rod Pemberton"
<do_not_have@notemailntt.cmm> wrote:
>"cg_chas" <cg_chas@hotmail.com> wrote in message
>news:vkoqq7lqshij3mfngok9g02gkcp5fg6kou@4ax.com...
>> On Thu, 10 May 2012 03:44:24 -0400, "Rod Pemberton"
>> <do_not_have@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.
>
>> 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
>
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
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailntt.cmm> |
|---|---|
| Date | 2012-05-13 03:24 -0400 |
| Message-ID | <jonnho$2sf$1@speranza.aioe.org> |
| In reply to | #577 |
"cg_chas" <cg_chas@hotmail.com> wrote in message
news:rs5sq7hme11emommn474of3nvclr6lmum9@4ax.com...
> On Fri, 11 May 2012 17:56:43 -0400, "Rod Pemberton"
> <do_not_have@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);
}
[toc] | [prev] | [next] | [standalone]
| From | cg_chas <cg_chas@hotmail.com> |
|---|---|
| Date | 2012-05-13 09:21 -0400 |
| Message-ID | <kkavq7pvo2l2j4cv4buk29j76i8m76knba@4ax.com> |
| In reply to | #578 |
On Sun, 13 May 2012 03:24:12 -0400, "Rod Pemberton"
<do_not_have@notemailntt.cmm> wrote:
>"cg_chas" <cg_chas@hotmail.com> wrote in message
>news:rs5sq7hme11emommn474of3nvclr6lmum9@4ax.com...
>> On Fri, 11 May 2012 17:56:43 -0400, "Rod Pemberton"
>> <do_not_have@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);
>}
>
>
>
>
>
>
>
>
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
[toc] | [prev] | [next] | [standalone]
| From | cg_chas <cg_chas@hotmail.com> |
|---|---|
| Date | 2012-05-14 10:37 -0400 |
| Message-ID | <pi22r7l8p6kd8un01j1hoaqpotdla6ke21@4ax.com> |
| In reply to | #579 |
On Sun, 13 May 2012 09:21:10 -0400, cg_chas <cg_chas@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
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailntt.cmm> |
|---|---|
| Date | 2012-05-14 23:46 -0400 |
| Message-ID | <josjha$4ga$1@speranza.aioe.org> |
| In reply to | #586 |
"cg_chas" <cg_chas@hotmail.com> wrote in message news:pi22r7l8p6kd8un01j1hoaqpotdla6ke21@4ax.com... > On Sun, 13 May 2012 09:21:10 -0400, cg_chas <cg_chas@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
[toc] | [prev] | [next] | [standalone]
| From | Rugxulo <rugxulo@gmail.com> |
|---|---|
| Date | 2012-05-14 21:02 -0700 |
| Message-ID | <e7df4d37-b8a3-47ab-8f22-e4847b8eb167@h10g2000yqn.googlegroups.com> |
| In reply to | #593 |
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
[toc] | [prev] | [next] | [standalone]
| From | cg_chas <cg_chas@hotmail.com> |
|---|---|
| Date | 2012-05-15 08:13 -0400 |
| Message-ID | <a1i4r7t7bajtcgl3orhoju2kh9mcv4lvhr@4ax.com> |
| In reply to | #593 |
On Mon, 14 May 2012 23:46:23 -0400, "Rod Pemberton" <do_not_have@notemailntt.cmm> wrote: >"cg_chas" <cg_chas@hotmail.com> wrote in message >news:pi22r7l8p6kd8un01j1hoaqpotdla6ke21@4ax.com... >> On Sun, 13 May 2012 09:21:10 -0400, cg_chas <cg_chas@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? > > >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. 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 > >
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailntt.cmm> |
|---|---|
| Date | 2012-05-15 18:54 -0400 |
| Message-ID | <joumq2$jes$1@speranza.aioe.org> |
| In reply to | #595 |
"cg_chas" <cg_chas@hotmail.com> wrote in message news:a1i4r7t7bajtcgl3orhoju2kh9mcv4lvhr@4ax.com... > On Mon, 14 May 2012 23:46:23 -0400, "Rod Pemberton" > <do_not_have@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
[toc] | [prev] | [next] | [standalone]
Page 1 of 2 [1] 2 Next page →
Back to top | Article view | comp.os.msdos.programmer
csiph-web