I used a 190kb file of '001001001....etc' with a 111 towards the end of the file and wrote a snippet that replaced the 111 with a 999.


org cs:100
mov ah,3D    ;<open file F1
mov al,02    ;<read/write
mov dx,F1
int 21
mov bl,al    ;file handle
mov si,dx  ;have a peek
mov bp,3131
l1
mov ah,3F ;<read
mov al,00 ;<bx has file handle
mov cx,2 ;<read 2 bytes
int 21
mov si,dx
cmp bp,
jnz l1        ;loop if no bp match
mov ah,40 ;<write B1 to file F1
mov al,00 ;<bx has file handle
mov cx,3 ;<write 3 bytes of B1
mov dx,B1
int 21
mov bp, ;peek
mov ah,3E  ;close file
mov al,0  ;handle in bx
int 21
ret
;
F1 db "db.txt"
B1 db "999"
C1 db ?
ret
END


What I am wondering is how far the INT21-3F pointer would go for writing this 999 into a text file thats obviously bigger than a 65kb segment, is it a 32 bit pointer that would handle a 4gig file??

Does anyone know where it exists in memory, I don't see any interrupt reference as to where the buffer is?
Posted on 2006-11-10 21:08:12 by eek
The offset into the file is a 32-bit value after DOS 2.0 and later. You can look at the function 42h for the trap 21h for DOS which sets the current file position in the file. It can also be used to retrieve the file position if you don't move the file pointer.
Posted on 2006-11-11 02:07:56 by XCHG
Thx for that, will have a look.
Posted on 2006-11-11 06:14:53 by eek
I wonder if that API can actually handle files the large - FAT has a limit of 2GB iirc, so the dos API might as well?
Posted on 2006-11-11 09:39:28 by f0dder
I didn't know that about FAT and unfortunately haven't found any official documents that state whether DOS has a limitation in reading from files or not ummm.
Posted on 2006-11-14 07:45:49 by XCHG