Groups > comp.os.msdos.programmer > #956 > unrolled thread

Problem with Int 21/AH=4E,4F(FindFirst and FindNext) function call.

Started by	Anil Nair <anilcoll90@gmail.com>
First post	2013-08-29 05:27 -0700
Last post	2013-09-10 23:01 -0700
Articles	20 on this page of 23 — 5 participants

Back to article view | Back to comp.os.msdos.programmer

  Problem with Int 21/AH=4E,4F(FindFirst and FindNext) function call. Anil Nair <anilcoll90@gmail.com> - 2013-08-29 05:27 -0700
    Re: Problem with Int 21/AH=4E,4F(FindFirst and FindNext) function call. "R.Wieser" <address@not.available> - 2013-08-29 15:03 +0200
      Re: Problem with Int 21/AH=4E,4F(FindFirst and FindNext) function call. kerravon@w3.to - 2013-08-29 08:15 -0700
        Re: Problem with Int 21/AH=4E,4F(FindFirst and FindNext) function call. kerravon@w3.to - 2013-08-29 08:21 -0700
          Re: Problem with Int 21/AH=4E,4F(FindFirst and FindNext) function call. "Bill Buckels" <bbuckels@mts.net> - 2013-08-29 11:03 -0500
            Re: Problem with Int 21/AH=4E,4F(FindFirst and FindNext) function call. kerravon@w3.to - 2013-08-30 03:06 -0700
              Re: Problem with Int 21/AH=4E,4F(FindFirst and FindNext) function call. "Bill Buckels" <bbuckels@mts.net> - 2013-08-30 09:30 -0500
                Re: Problem with Int 21/AH=4E,4F(FindFirst and FindNext) function call. kerravon@w3.to - 2013-08-30 08:07 -0700
                  Re: Problem with Int 21/AH=4E,4F(FindFirst and FindNext) function call. "Bill Buckels" <bbuckels@mts.net> - 2013-08-30 10:48 -0500
                    Re: Problem with Int 21/AH=4E,4F(FindFirst and FindNext) function call. "Rod Pemberton" <dont_use_email@nohavenotit.com> - 2013-08-31 01:32 -0400
                      Re: Problem with Int 21/AH=4E,4F(FindFirst and FindNext) function call. kerravon@w3.to - 2013-08-31 10:36 -0700
          Re: Problem with Int 21/AH=4E,4F(FindFirst and FindNext) function call. "Bill Buckels" <bbuckels@mts.net> - 2013-08-29 11:15 -0500
            Re: Problem with Int 21/AH=4E,4F(FindFirst and FindNext) function call. kerravon@w3.to - 2013-08-30 08:03 -0700
              Re: Problem with Int 21/AH=4E,4F(FindFirst and FindNext) function call. kerravon@w3.to - 2013-08-30 15:01 -0700
              Re: Problem with Int 21/AH=4E,4F(FindFirst and FindNext) function call. "R.Wieser" <address@not.available> - 2013-08-31 00:28 +0200
    Re: Problem with Int 21/AH=4E,4F(FindFirst and FindNext) function call. "Bill Buckels" <bbuckels@mts.net> - 2013-08-29 08:05 -0500
      Re: Problem with Int 21/AH=4E,4F(FindFirst and FindNext) function call. "Bill Buckels" <bbuckels@mts.net> - 2013-08-29 08:33 -0500
        Re: Problem with Int 21/AH=4E,4F(FindFirst and FindNext) function call. Anil Nair <anilcoll90@gmail.com> - 2013-08-29 06:57 -0700
          Re: Problem with Int 21/AH=4E,4F(FindFirst and FindNext) function call. "Bill Buckels" <bbuckels@mts.net> - 2013-08-29 10:04 -0500
      Re: Problem with Int 21/AH=4E,4F(FindFirst and FindNext) function call. kerravon@w3.to - 2013-08-29 07:22 -0700
        Re: Problem with Int 21/AH=4E,4F(FindFirst and FindNext) function call. "Bill Buckels" <bbuckels@mts.net> - 2013-08-29 09:55 -0500
        Re: Problem with Int 21/AH=4E,4F(FindFirst and FindNext) function call. "Bill Buckels" <bbuckels@mts.net> - 2013-08-29 11:35 -0500
    Re: Problem with Int 21/AH=4E,4F(FindFirst and FindNext) function call. Anil Nair <anilcoll90@gmail.com> - 2013-09-10 23:01 -0700

Page 1 of 2 [1] 2 Next page →

#956 — Problem with Int 21/AH=4E,4F(FindFirst and FindNext) function call.

From	Anil Nair <anilcoll90@gmail.com>
Date	2013-08-29 05:27 -0700
Subject	Problem with Int 21/AH=4E,4F(FindFirst and FindNext) function call.
Message-ID	<3d695743-aadd-45f3-af21-68be161c50ce@googlegroups.com>

Hello Guys,

We have implemented two functions calls int 21/AH=4E(find first) and int 21/AH=4F(find next), Both the function calls seems to work fine when called with the "dir" (directory listing) command, But the moment we use program such as "xcopy" it doesn't seem to work properly. The problem occurs when we try to copy multiple files from one volume to another volume it just copies a single file. We added some debugging Statements into it, here are the observations

"Booting from Hard Disk...
welcome to PDOS-16
welcome to pcomm

C:\>dir
The pattern in PosFindFirst is x *.* x
 IO.SYS            11250 20 2013-08-22 00:42:18
MSDOS.SYS         36998 20 2013-08-28 23:54:10
COMMAND.COM       38022 20 2013-08-21 20:49:36
FROM                  0 10 2013-08-21 20:49:18
XCOPY.EXE         26902 20 2013-08-22 00:53:12
1.TXT                12 00 1981-09-16 00:00:00
The Return code in fileRead is x 32 x

C:\>xcopy c:\from\ d:\
The pattern in PosFindFirst is x c:\from\*.* x
 Called xcopy_file
The pattern in PosFindFirst is x c:\from\1.TXT x
 The pattern in PosFindFirst is x d:\1.TXT x
 Overwrite d:\1.TXT (Yes/No/Overwrite all/Skip all)? y"

We concluded that the PosFindFirst(int21 AH=4E) is being called multiple times,
Here is the debug output for multiple 4E calls,

"ZZZ 57 6000 YYY
ZZZ 58 4300 YYY
ZZZ 59 6000 YYY
ZZZ 60 1a80 YYY

ZZZ 61 4e80 YYY

ZZZ 62 4300 YYY
ZZZ 63 4300 YYY
ZZZ 64 1a2a YYY

>ZZZ 65 4e2a YYY

ZZZ 66 1a48 YYY

>ZZZ 67 4e48 YYY

ZZZ 68 3666 YYY
ZZZ 69 024f YYY
OZZZ 70 0276 YYY
vZZZ 71 0265 YYY
eZZZ 72 0272 YYY
rZZZ 73 0277 YYY
wZZZ 74 0272 YYY
rite d:\1.TXT (Yes/No/Overwrite all/Skip all)? "

As Observed in the debug output the 4E function call is being called multiple times due to which the contents present in the DTA are overwritten so findnext call 4F is not being called correctly. Is there any way to preserve the contents of DTA on temporary basis? or Associate every 4E function call with 4F?

Let me know if any data is missing or not understood. Any help or suggestions are appreciated.:)

--
Regards,
Anil Nair

[toc] | [next] | [standalone]

#957

From	"R.Wieser" <address@not.available>
Date	2013-08-29 15:03 +0200
Message-ID	<521f4697$0$15995$e4fe514c@news2.news.xs4all.nl>
In reply to	#956

Hello Anil

> We concluded that the PosFindFirst(int21 AH=4E) is
> being called multiple times,

Please be aware that each of those calls is preceeded by an INT 21h, AH=1Ah.
These will change the location of the DTA (where the FindFirst/FindNext
calls store their intermediate/continuation data).

To clarify: When you need to do some nested FindFirst/FindNext calls you
need to change the DTA for each nesting-level.

Hope that helps.

Rudy Wieser


-- Origional message:
Anil Nair <anilcoll90@gmail.com> schreef in berichtnieuws
3d695743-aadd-45f3-af21-68be161c50ce@googlegroups.com...
Hello Guys,

We have implemented two functions calls int 21/AH=4E(find first) and int
21/AH=4F(find next), Both the function calls seems to work fine when called
with the "dir" (directory listing) command, But the moment we use program
such as "xcopy" it doesn't seem to work properly. The problem occurs when we
try to copy multiple files from one volume to another volume it just copies
a single file. We added some debugging Statements into it, here are the
observations

"Booting from Hard Disk...
welcome to PDOS-16
welcome to pcomm

C:\>dir
The pattern in PosFindFirst is x *.* x
 IO.SYS            11250 20 2013-08-22 00:42:18
MSDOS.SYS         36998 20 2013-08-28 23:54:10
COMMAND.COM       38022 20 2013-08-21 20:49:36
FROM                  0 10 2013-08-21 20:49:18
XCOPY.EXE         26902 20 2013-08-22 00:53:12
1.TXT                12 00 1981-09-16 00:00:00
The Return code in fileRead is x 32 x

C:\>xcopy c:\from\ d:\
The pattern in PosFindFirst is x c:\from\*.* x
 Called xcopy_file
The pattern in PosFindFirst is x c:\from\1.TXT x
 The pattern in PosFindFirst is x d:\1.TXT x
 Overwrite d:\1.TXT (Yes/No/Overwrite all/Skip all)? y"

We concluded that the PosFindFirst(int21 AH=4E) is being called multiple
times,
Here is the debug output for multiple 4E calls,

"ZZZ 57 6000 YYY
ZZZ 58 4300 YYY
ZZZ 59 6000 YYY
ZZZ 60 1a80 YYY

ZZZ 61 4e80 YYY

ZZZ 62 4300 YYY
ZZZ 63 4300 YYY
ZZZ 64 1a2a YYY

>ZZZ 65 4e2a YYY

ZZZ 66 1a48 YYY

>ZZZ 67 4e48 YYY

ZZZ 68 3666 YYY
ZZZ 69 024f YYY
OZZZ 70 0276 YYY
vZZZ 71 0265 YYY
eZZZ 72 0272 YYY
rZZZ 73 0277 YYY
wZZZ 74 0272 YYY
rite d:\1.TXT (Yes/No/Overwrite all/Skip all)? "

As Observed in the debug output the 4E function call is being called
multiple times due to which the contents present in the DTA are overwritten
so findnext call 4F is not being called correctly. Is there any way to
preserve the contents of DTA on temporary basis? or Associate every 4E
function call with 4F?

Let me know if any data is missing or not understood. Any help or
suggestions are appreciated.:)

--
Regards,
Anil Nair

[toc] | [prev] | [next] | [standalone]

#965

From	kerravon@w3.to
Date	2013-08-29 08:15 -0700
Message-ID	<4b68ed75-f4c9-4ad1-996e-9973309a9a0b@googlegroups.com>
In reply to	#957

On Thursday, August 29, 2013 11:03:49 PM UTC+10, R.Wieser wrote:
> 
> > We concluded that the PosFindFirst(int21 AH=4E) is
> 
> > being called multiple times,
> 
> Please be aware that each of those calls is preceeded by an INT 21h, AH=1Ah.

Good observation!

> These will change the location of the DTA (where the FindFirst/FindNext
> calls store their intermediate/continuation data).
> 
> To clarify: When you need to do some nested FindFirst/FindNext calls you
> need to change the DTA for each nesting-level.

Ok, so every First/Next call requires an
intervening SetDTA. That's appears to be
the case.

Thanks. Paul.

[toc] | [prev] | [next] | [standalone]

#966

From	kerravon@w3.to
Date	2013-08-29 08:21 -0700
Message-ID	<41171246-21e6-493c-9b7e-a59b5fbaaddb@googlegroups.com>
In reply to	#965

On Friday, August 30, 2013 1:15:06 AM UTC+10, kerr...@w3.to wrote:
> On Thursday, August 29, 2013 11:03:49 PM UTC+10, R.Wieser wrote:
> 
> > > We concluded that the PosFindFirst(int21 AH=4E) is
> 
> > > being called multiple times,
> 
> > Please be aware that each of those calls is preceeded by an INT 21h, AH=1Ah.
> 
> Good observation!

Anil, here is the code in question from the
Borland runtime library findfirs.cas:

/*--------------------------------------------------------------------------*

Name            findfirst - searches disk directory

Usage           int findfirst(const char *pathname, struct ffblk *ffblk,
                              int attrib);

Prototype in    dir.h

Description     begins a search of a disk directory by using the
                MS-DOS system call 0x4E.

                pathname is a string with an optional drive specifier,
                path and file name of the file to be found.   If a
                matching file is found, the ffblk structure is filled
                with the file-directory information.

                attrib is an MS-DOS file-attribute byte used in selecting
                eligible files for the search.  attrib can be one of the
                following constants defined in dos.h

                        FA_RDONLY  Read only
                        FA_HIDDEN  Hidden file
                        FA_SYSTEM  System file
                        FA_LABEL   Volume label
                        FA_DIREC   Directory
                        FA_ARCH    Archive

                For more detailed information about these attributes, refer
                to the MS-DOS Programmer's Reference Manual.

Return value    success : 0
                else : -1 and errno is set to
                        ENOENT  Path or file name not found
                        ENMFILE No more files

*---------------------------------------------------------------------------*/

int _CType _FARFUNC findfirst(const char *pathname, struct ffblk *ffblk, int attrib)
{
asm     push    ds

asm     mov     ah,2fh          /* get (and save) DTA */
asm     int     21h
asm     push    es
asm     push    bx

asm     mov     ah, 01Ah
asm     LDS_    dx, ffblk
asm     int     021h            /* Set the disk transfer address */

asm     mov     ah, 04Eh
asm     mov     cx, attrib
asm     LDS_    dx, pathname
asm     int     021h            /* Find first matching file */

asm     pushf                   /* save state of carry flag */
asm     pop     cx
asm     xchg    ax, bx          /* save return code */

asm     mov     ah, 01Ah        /* restore DTA */
asm     pop     dx
asm     pop     ds
asm     int     21h

asm     push    cx
asm     popf
asm     pop     ds

asm     jc      findfirstFailed
        return(0);

findfirstFailed:
        return __IOerror(_BX);
}


/*--------------------------------------------------------------------------*

Name            findnext - fetches files which match findfirst

Usage           int findnext(struct ffblk *ffblk);

Prototype in    dir.h

Description     findnext is used to fetch subsequent files which
                match the pathname given in findfirst.  ffblk is the
                same block filled in by the findfirst call.  This
                block contains necessary information for continuing
                the search.  One file name for each call to findnext will
                be returned until no more files are found in the directory
                matching the pathname.

Return value    success : 0
                else : -1 and errno is set to
                        ENOENT  Path or file name not found
                        ENMFILE No more files

*---------------------------------------------------------------------------*/
int _CType _FARFUNC findnext(struct ffblk *ffblk)
{
asm     push    ds

asm     mov     ah,2fh          /* get (and save) DTA */
asm     int     21h
asm     push    es
asm     push    bx

asm     mov     ah, 01Ah
asm     LDS_    dx, ffblk
asm     int     021h            /* Set the disk transfer address */

asm     mov     ah, 04Fh
asm     int     021h            /* Find next matching file */

asm     pushf                   /* save state of carry flag */
asm     pop     cx
asm     xchg    ax, bx          /* save return code */

asm     mov     ah, 01Ah        /* restore DTA */
asm     pop     dx
asm     pop     ds
asm     int     21h

asm     push    cx
asm     popf
asm     pop     ds

asm     jc      findnextFailed
        return(0);

findnextFailed:
        return __IOerror(_BX);
}

[toc] | [prev] | [next] | [standalone]

#967

From	"Bill Buckels" <bbuckels@mts.net>
Date	2013-08-29 11:03 -0500
Message-ID	<kvnrce$akb$1@speranza.aioe.org>
In reply to	#966

<kerravon@w3.to> wrote:

> Anil, here is the code in question from the Borland runtime library 
> findfirs.cas:

Paul this is perfect. It seems to me they are using their own DTA after 
pushing whatver was ther onto the stack, then popping whatver was there back 
on afterwards.

Where do you have the source? I have some old turbo c and borland compilers 
around here from the old website, but I don't think they had the source 
there...

Bill

[toc] | [prev] | [next] | [standalone]

#970

From	kerravon@w3.to
Date	2013-08-30 03:06 -0700
Message-ID	<c2fcd62f-5c67-4d9a-b267-a240efac2430@googlegroups.com>
In reply to	#967

On Friday, August 30, 2013 2:03:27 AM UTC+10, Bill Buckels wrote:
> <kerravon@w3.to> wrote:
> 
> > Anil, here is the code in question from the Borland runtime library 
> 
> > findfirs.cas:
> 
> Paul this is perfect. It seems to me they are using their own DTA after 
> pushing whatver was ther onto the stack, then popping whatver was there back 
> on afterwards.
> 
> Where do you have the source?

It came with Borland C++ 3.1 (purchased long ago, not downloaded) I believe.

C:\borlandc>dir
 Volume in drive C is OS
 Volume Serial Number is DE22-8195

 Directory of C:\borlandc

2013-07-13  18:56    <DIR>          .
2013-07-13  18:56    <DIR>          ..
2013-07-13  18:56    <DIR>          BGI
2013-07-13  18:56    <DIR>          BIN
2013-07-13  18:56    <DIR>          CLASSLIB
2013-07-13  18:56    <DIR>          CRTL
2013-07-13  18:56    <DIR>          DOC
2013-07-13  18:56    <DIR>          EXAMPLES
2013-07-31  04:00    <DIR>          INCLUDE
2013-07-13  18:56    <DIR>          LIB
2013-07-13  18:56    <DIR>          OWL
2013-07-13  18:56    <DIR>          REDIST
2013-07-13  18:56    <DIR>          TVISION
               0 File(s)              0 bytes
              13 Dir(s)  20,550,037,504 bytes free

C:\borlandc>cd crtl

C:\borlandc\CRTL>dir
 Volume in drive C is OS
 Volume Serial Number is DE22-8195

 Directory of C:\borlandc\CRTL

2013-07-13  18:56    <DIR>          .
2013-07-13  18:56    <DIR>          ..
1992-06-10  02:10               266 ALL.BAT
1992-06-10  02:10             1,826 BUILD.BAT
2013-08-30  01:19    <DIR>          CLIB
1992-06-10  02:10            17,239 CRTL.DOC
2013-07-13  18:56    <DIR>          EMU
2013-07-13  18:56    <DIR>          IOSTREAM
1992-06-10  02:10             1,391 MAKEDIRS.BAT
1992-06-10  02:10             3,038 MAKEFILE
2013-07-13  18:56    <DIR>          MATH
1992-06-10  02:10                 2 RETURN.TXT
2013-07-13  18:56    <DIR>          RTLINC
1992-06-10  02:10             2,320 RULES.MAK
1992-06-10  02:10               914 VARS.BAT
2013-07-13  18:56    <DIR>          WINLIB
               8 File(s)         26,996 bytes
               8 Dir(s)  20,550,037,504 bytes free

C:\borlandc\CRTL>cd clib

C:\borlandc\CRTL\CLIB>dir find*
 Volume in drive C is OS
 Volume Serial Number is DE22-8195

 Directory of C:\borlandc\CRTL\CLIB

1992-06-10  02:10             4,821 FINDFIRS.CAS
               1 File(s)          4,821 bytes
               0 Dir(s)  20,550,037,504 bytes free

C:\borlandc\CRTL\CLIB>

[toc] | [prev] | [next] | [standalone]

#971

From	"Bill Buckels" <bbuckels@mts.net>
Date	2013-08-30 09:30 -0500
Message-ID	<kvqa9q$p1g$1@speranza.aioe.org>
In reply to	#970

<kerravon@w3.to> wrote:

> It came with Borland C++ 3.1 (purchased long ago, not downloaded) I 
> believe.

In 1992 I bought Borland C++ 3.1 with manuals, MS-VC++ 7,  and the 
MS-Windows SDK with Manuals. Altogether they filled an entire bookshelf.

That was the year that MultiMedia Windows took over and MS-DOS started to 
lose popularity.

After working with the twindow class and Borland's DDVT (dynamic dispatch 
vecor table) I changed jobs many times moving between MS-C and Borland C and 
other languages. I believe I gave the Borland C++ in its entirety to a 
friend in 1999. In 2001 I set-up the company that I was with then as a 
Borland Partner and worked for a year or more in Borland Languages.

I have never really missed BC 3.1.

Today I collect older compilers from the 80's for various platforms and 
don't really need the source because when I write 16 bit C code I use MSC.

BC 3.1 was never made publicly available from David Intersimone's Antique 
Software Museum nor was library source for the other compilers.

David continues with emarcadero and Delphi XE4. I last received a product 
announcement from him at the end of June 2013.

What you have there is a wonderful reference. David never received further 
permission to distribute additional museum products as far as he has told 
any of us.

Best,

Bill

[toc] | [prev] | [next] | [standalone]

#974

From	kerravon@w3.to
Date	2013-08-30 08:07 -0700
Message-ID	<1782cf26-d8e3-43c3-bd47-667a173ba6e4@googlegroups.com>
In reply to	#971

On Saturday, August 31, 2013 12:30:18 AM UTC+10, Bill Buckels wrote:
> <kerravon@w3.to> wrote:
> 
> BC 3.1 was never made publicly available from David Intersimone's Antique 
> Software Museum nor was library source for the other compilers.
> 
> David continues with emarcadero and Delphi XE4. I last received a product 
> announcement from him at the end of June 2013.

It seems you know this person. Would you be
able to ask him to make TC++ 1.01 (part of
the museum) available for download without
requiring registration of an unrelated
(and non-free?) product?

Thanks. Paul.

[toc] | [prev] | [next] | [standalone]

#976

From	"Bill Buckels" <bbuckels@mts.net>
Date	2013-08-30 10:48 -0500
Message-ID	<kvqet5$7a0$1@speranza.aioe.org>
In reply to	#974

<kerravon@w3.to> wrote:

> TC++ 1.01 (part of the museum) available for download without requiring 
> registration of an unrelated (and non-free?) product?

I have it here free from the old museum without the condition of purchasing 
products. I can send it to you in private mail. I downloaded most everything 
that was free from the old museum long ago.

David has been sending me email from the time I was a Borland Partner but I 
have never met him nor known his personna outside of cyber-space.

Bill

[toc] | [prev] | [next] | [standalone]

#981

From	"Rod Pemberton" <dont_use_email@nohavenotit.com>
Date	2013-08-31 01:32 -0400
Message-ID	<op.w2n1omts0e5s1z@->
In reply to	#976

On Fri, 30 Aug 2013 11:48:54 -0400, Bill Buckels <bbuckels@mts.net> wrote:
> <kerravon@w3.to> wrote:

>> TC++ 1.01 (part of the museum) available for download without
>> requiring registration of an unrelated (and non-free?) product?
>
> I have it here free from the old museum without the condition
> of purchasing products. I can send it to you in private mail.
> I downloaded most everything that was free from the old museum
> long ago.
>

Borland's software museum comes up every few years on c.o.m.d.,
comp.lang.asm.x86, alt.os.development, etc.  AFAIK, the original
website is no longer available, but it is archived.  I just posted
this the other day for someone on a.o.d.:

"Turbo C++ (v1.01) and Turbo C (v2.01) and a few versions of
Turbo Pascal are available via WayBackMachine's archive of
Borland's software 'museum':"

http://web.archive.org/web/20050204085204/http://bdn.borland.com/museum

P.S.  I haven't had a chance to look at what DJGPP does with
FindFirst, FindNext, DTA, ffblk, etc.  You guys might want
to download DJGPP, and maybe OpenWatcom too, just to see
what they do in their code.  They had to have worked out
some of these or similar issues.  You could try their
newsgroups too:

comp.os.msdos.djgpp
openwatcom.user.c_cpp

Last I heard, you have to connect directly to news.openwatcom.org
to post to openwatcom.user.c_cpp, but you can read it anywhere.

Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#987

From	kerravon@w3.to
Date	2013-08-31 10:36 -0700
Message-ID	<823e60d6-f86b-4aed-a57a-e2f4d3af7793@googlegroups.com>
In reply to	#981

On Saturday, August 31, 2013 3:32:36 PM UTC+10, Rod Pemberton wrote:
> On Fri, 30 Aug 2013 11:48:54 -0400, Bill Buckels <bbuckels@mts.net> wrote:
> 
> > <kerravon@w3.to> wrote:
> 
> 
> >> TC++ 1.01 (part of the museum) available for download without
> 
> >> requiring registration of an unrelated (and non-free?) product?
> 
> > I have it here free from the old museum without the condition
> 
> > of purchasing products. I can send it to you in private mail.
> 
> > I downloaded most everything that was free from the old museum
> 
> > long ago.
> 
> 
> Borland's software museum comes up every few years on c.o.m.d.,
> 
> comp.lang.asm.x86, alt.os.development, etc.  AFAIK, the original
> 
> website is no longer available, but it is archived.  I just posted
> 
> this the other day for someone on a.o.d.:
> 
> 
> 
> "Turbo C++ (v1.01) and Turbo C (v2.01) and a few versions of
> 
> Turbo Pascal are available via WayBackMachine's archive of
> 
> Borland's software 'museum':"
> 
> 
> 
> http://web.archive.org/web/20050204085204/http://bdn.borland.com/museum

That's a great solution, thanks. I added that link here:

http://en.wikipedia.org/wiki/Turbo_C%2B%2B#External_links

BFN. Paul.

[toc] | [prev] | [next] | [standalone]

#968

From	"Bill Buckels" <bbuckels@mts.net>
Date	2013-08-29 11:15 -0500
Message-ID	<kvns24$coi$1@speranza.aioe.org>
In reply to	#966

<kerravon@w3.to> wrote:

> Anil, here is the code in question from the Borland runtime library 
> findfirs.cas:

Paul, I think Anil needs the header files to see what the DTA looks like in 
Borland...

from DIR.H TC 2.01

struct ffblk {
 char  ff_reserved[21];
 char  ff_attrib;
 unsigned ff_ftime;
 unsigned ff_fdate;
 long  ff_fsize;
 char  ff_name[13];
};

The FCB structs are in DOS.H

This is in TC2.01. Is that the version you have? I have no library sources 
for my BC55, or TC 2.01 etc.

Bill

[toc] | [prev] | [next] | [standalone]

#973

From	kerravon@w3.to
Date	2013-08-30 08:03 -0700
Message-ID	<12891b49-84d1-4fae-b9fe-df0ac147f441@googlegroups.com>
In reply to	#968

On Friday, August 30, 2013 2:15:02 AM UTC+10, Bill Buckels wrote:
> <kerravon@w3.to> wrote:
> 
> Paul, I think Anil needs the header files to see what the DTA looks like in 
> Borland...
> 
> from DIR.H TC 2.01
> 
> struct ffblk {
> 
>  char  ff_reserved[21];
> 
>  char  ff_attrib;
> 
>  unsigned ff_ftime;
> 
>  unsigned ff_fdate;
> 
>  long  ff_fsize;
> 
>  char  ff_name[13];
> 
> };

Is that first field - ff_reserved - used internally
by MSDOS/FreeDOS/PDOS, e.g. to contain:

1. a file handle corresponding to the open directory.
2. the pattern being matched against.

What is MSDOS expecting the size of the DTA
to be?

Does MSDOS use any of those fields, or are they
all for the benefit of the CRTL's findfirst/next
operations?

Thanks. Paul.

[toc] | [prev] | [next] | [standalone]

#977

From	kerravon@w3.to
Date	2013-08-30 15:01 -0700
Message-ID	<00059db8-89ea-4f16-b538-10336249f7be@googlegroups.com>
In reply to	#973

On Saturday, August 31, 2013 1:03:11 AM UTC+10, kerr...@w3.to wrote:
> On Friday, August 30, 2013 2:15:02 AM UTC+10, Bill Buckels wrote:
> 
> > <kerravon@w3.to> wrote:
> 
> > 
> 
> > Paul, I think Anil needs the header files to see what the DTA looks like in 
> 
> > Borland...
> 
> > 
> 
> > from DIR.H TC 2.01
> 
> > 
> 
> > struct ffblk {
> 
> > 
> 
> >  char  ff_reserved[21];
> 
> > 
> 
> >  char  ff_attrib;
> 
> > 
> 
> >  unsigned ff_ftime;
> 
> > 
> 
> >  unsigned ff_fdate;
> 
> > 
> 
> >  long  ff_fsize;
> 
> > 
> 
> >  char  ff_name[13];
> 
> > 
> 
> > };
> 
> 
> 
> Is that first field - ff_reserved - used internally
> 
> by MSDOS/FreeDOS/PDOS, e.g. to contain:
> 
> 
> 
> 1. a file handle corresponding to the open directory.
> 
> 2. the pattern being matched against.
> 
> 
> 
> What is MSDOS expecting the size of the DTA
> 
> to be?
> 
> 
> 
> Does MSDOS use any of those fields, or are they
> 
> all for the benefit of the CRTL's findfirst/next
> 
> operations?
> 
> 
> 
> Thanks. Paul.


I can see from this code in pdos:

dta[0x15] = buf[0x0b]; /* attribute */
memcpy(dta + 0x16, buf + 0x16, 2); /* time */
memcpy(dta + 0x18, buf + 0x18, 2); /* time */
memcpy(dta + 0x1a, buf + 0x1c, 4); /* file size */
/*memcpy(dta + 0x1e, buf, 11);
dta[0x1e + 11] = '\0';*/
memset(dta + 0x1e, '\0', 13);
strcpy(dta + 0x1e, file);

that the ffblk fields are in fact used/expected.

And this:

http://www.ctyme.com/intr/rb-2977.htm#Table1626

gives an indication of how the first 0x15 bytes
are used, and I believe that is the OS's
choice as to what information can be stored
there.

BFN. Paul.

[toc] | [prev] | [next] | [standalone]

#979

From	"R.Wieser" <address@not.available>
Date	2013-08-31 00:28 +0200
Message-ID	<52211c8a$0$15908$e4fe514c@news2.news.xs4all.nl>
In reply to	#973

Hello Paul,

> Does MSDOS use any of those fields, or are they
> all for the benefit of the CRTL's findfirst/next
> operations?

The default DTA is placed at PSP offset 0080h.  And that is where the
commandline parameters are placed too ...

In other words: if-and-when you need to use the commandline parameters you
either need to set your own DTA elsewhere, or parse the commandline
parameters before you do a FindFirst.

That/the DTA is for the use of your programs FindFirst/FindNext commands.
MSDOS does not use any of it.

Hope that helps.

Rudy Wieser


-- Origional message:
<kerravon@w3.to> schreef in berichtnieuws
12891b49-84d1-4fae-b9fe-df0ac147f441@googlegroups.com...
> On Friday, August 30, 2013 2:15:02 AM UTC+10, Bill Buckels wrote:
> > <kerravon@w3.to> wrote:
> >
> > Paul, I think Anil needs the header files to see what the DTA looks like
in
> > Borland...
> >
> > from DIR.H TC 2.01
> >
> > struct ffblk {
> >
> >  char  ff_reserved[21];
> >
> >  char  ff_attrib;
> >
> >  unsigned ff_ftime;
> >
> >  unsigned ff_fdate;
> >
> >  long  ff_fsize;
> >
> >  char  ff_name[13];
> >
> > };
>
> Is that first field - ff_reserved - used internally
> by MSDOS/FreeDOS/PDOS, e.g. to contain:
>
> 1. a file handle corresponding to the open directory.
> 2. the pattern being matched against.
>
> What is MSDOS expecting the size of the DTA
> to be?
>
> Does MSDOS use any of those fields, or are they
> all for the benefit of the CRTL's findfirst/next
> operations?
>
> Thanks. Paul.

[toc] | [prev] | [next] | [standalone]

#958

From	"Bill Buckels" <bbuckels@mts.net>
Date	2013-08-29 08:05 -0500
Message-ID	<kvngud$b2g$1@speranza.aioe.org>
In reply to	#956

"Anil Nair" <anilcoll90@gmail.com> wrote:

> Is there any way to preserve the contents of DTA on temporary basis?

That's a good question. I have never wanted to. Generally in a C program we 
build the list first and process the list afterwards...

    if(findfirst(buffer, &wild_card, FA_NORMAL) == 0) {
      strcpy(wildfiles[wildcounter], wild_card.ff_name);
      wildcounter++;

      while(findnext(&wild_card) == 0) {
        strcpy(wildfiles[wildcounter], wild_card.ff_name);
        wildcounter++;
      }
    }

Use the following link (view in an MS-DOS text file viewer):

http://www.o3one.org/hwdocs/bios_doc/dosref22.html

Have a look and write your own version of the xcopy command using the FCB 
calls;

Function  14h   Sequential Disk File Read
Function  15h   Sequential Disk Write

Bill

[toc] | [prev] | [next] | [standalone]

#959

From	"Bill Buckels" <bbuckels@mts.net>
Date	2013-08-29 08:33 -0500
Message-ID	<kvniis$fg1$1@speranza.aioe.org>
In reply to	#958

"Bill Buckels" <bbuckels@mts.net> wrote:

> Generally in a C program we build the list first and process the list 
> afterwards...

An example of how we do this is here (see source code for SHOWPIX - Menu 
Driven Picture Viewer for DOS):

http://www.teacherschoice.ca/kidstuff/worktool/wrktoo20.zip

Doc: http://www.teacherschoice.ca/kidstuff/worktool/wrktoo20.txt

Bill

[toc] | [prev] | [next] | [standalone]

#961

From	Anil Nair <anilcoll90@gmail.com>
Date	2013-08-29 06:57 -0700
Message-ID	<d529412a-a897-463e-a9bd-30771654516b@googlegroups.com>
In reply to	#959

Hey Thanks Bill for the references and you reply.I will try them out and will let you know.:).

--
Regards,
Anil Nair

[toc] | [prev] | [next] | [standalone]

#964

From	"Bill Buckels" <bbuckels@mts.net>
Date	2013-08-29 10:04 -0500
Message-ID	<kvnnuo$vpp$1@speranza.aioe.org>
In reply to	#961

"Anil Nair" <anilcoll90@gmail.com> wrote:

> Hey Thanks Bill for the references and you reply.I will try them out and 
> will let you know.:).

Watch-out Anil, those are FCB calls, not 4E and 4F calls.

Why not get-out Turbo C and write a prototype to see if what you want to do 
can be done without buffering the list of files. Assume that if it can't be 
done there it may not be worth pursuing.

My point is actually that you should not borrow problems. Build the list 
first, and copy the files next. That is all that makes sense to me and that 
is possibly why what you are trying to do may not work... the solution of 
storing and restoring the DTA to support a non-standard control structure in 
a piece of code seems rather a waste of time, when the time to code a buffer 
may solve everyhing for you...

Assuming you want to write some code, rather than debug something that is 
currently broken.

Good luck whatever you end-up doing. I would encourage you to follow what we 
did in the past with these old systems that is tried and true before trying 
something different and new.

Bill

[toc] | [prev] | [next] | [standalone]

#962

From	kerravon@w3.to
Date	2013-08-29 07:22 -0700
Message-ID	<6036febd-3f55-4138-ba2c-f2145e0ba521@googlegroups.com>
In reply to	#958

On Thursday, August 29, 2013 11:05:33 PM UTC+10, Bill Buckels wrote:
>     if(findfirst(buffer, &wild_card, FA_NORMAL) == 0) {
> 
>       while(findnext(&wild_card) == 0) {

Hi Bill.

Could you please explain why findnext takes
a parameter when the interrupt doesn't call
for one?

http://www.ctyme.com/intr/rb-2979.htm

Thanks. Paul.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2 [1] 2 Next page →

csiph-web

Problem with Int 21/AH=4E,4F(FindFirst and FindNext) function call.

Contents

#956 — Problem with Int 21/AH=4E,4F(FindFirst and FindNext) function call.

#957

#965

#966

#967

#970

#971

#974

#976

#981

#987

#968

#973

#977

#979

#958

#959

#961

#964

#962