how to read from a buffer

[Frank Kotler]

Lemme see... you open "filename1", which is "test2", and put the handle in "filehndl2". Have I got that right? (really should check the carry-flag to make sure the open succeeded before you try to use it!)

Then you attempt to read from "filehndl", which is... what? Still "uninitialized", isn't it? In executable formats other than .com (all that I'm aware of), the loader will initialize .bss to zero, but in a .com file it could be any garbage. This probably won't work.

Then you write to "filehndl2"... This might put "hellohello" in the file that just had "hello" in it... no, I think I'm lost at this point...

It is not normal that this should print hex anywhere. It is not normal that it should do something different each time. Trashing a "backup" of your MBR shouldn't cause a problem, unless you try to use it. Trashing your actual MBR definitely will cause a problem! Dos "file" functions won't read/write your MBR, but be very careful with int 13h!!!

Keep trying, I don't think you've got it yet...

Best,
Frank

[flyhigh427]

its way different then vb 6 thats for sure
thanks frank

[flyhigh427]

im haveing trouble with this line >> mov     [read_len],ax    ; returns number of bytes actually 
i cant figure out how count up the bytes then put that number in read read_ien

Code: [Select]


org 100h
section .text

start:
;open test1.txt
                mov     ah, 3dh         ;Open the file
                mov     al, 0           ;Open for reading
                mov     dx, filename1   ;Presume DS points at filename
                int     21h             ; segment.
                jc      BadOpen
                mov     [filehnd1], ax  ;Save file handle

;read from test1.txt 1 byte at a time into buffer
LP:
                mov     ah,3fh          ;Read data from the file
                mov     bx, [filehnd1]  ;Get file handle value
                mov     cx, 1         
                mov     dx, textbuf     ;Address of data buffer               
                int     21h               
                jc      ReadError               
               
                cmp     ax, 0           ;EOF reached?
                jne     EOF     
               
                mov     [read_len],ax    ; returns number of bytes actually 
                jmp     LP               ;Read next byte

EOF:           
               
                mov     bx, [filehnd1]
                mov     ah, 3eh         ;Close file
                int     21h
                jc      CloseError


;create test2.txt


                mov ah,3Ch               ; the open/create-a-file function
                mov cx,2                 ; file attribute - normal file
                mov dx,filename2         ; address of a ZERO TERMINATED! filename string
                int 021h                 ; call on Good Old Dos
                jc      BadOpen
                mov [filehnd2],ax        ; returns a file handle (probably 5)



;write to test2.txt


                mov ah,040h              ; write-to-a-file
                mov bx,[filehnd2]        ; file handle for standard output
                mov cx,read_len        ; bytes to write - same number we read :)
                mov dx,textbuf           ; buffer to write from
                int 021h                 ; call on Good Old Dos
         

;close test2.txt

                mov ah,03Eh               ; close the file
                mov bx,[filehnd2]         ; yeah, file handle in bx
                int 021h                  ; call on Good Old Dos
                jc      CloseError
                jmp exit
CloseError:

           mov dx,msgclose
           mov ah,09           
           int 21h   
           xor ax,ax
           int 016h
           jmp exit
ReadError:
           mov dx,msgread
           mov ah,09
           int 21h
           xor ax,ax
           int 016h
           jmp exit 
BadOpen:

           mov dx,msgopen
           mov ah,09
           int 21h
           xor ax,ax
           int 016h
           jmp exit 
exit:
    mov ah,04Ch         ; terminate-program function
    int 021h            ; you guessed it!
 


;--------------------------------------------------
section .data
   
    msgclose db "unable to close file...", 0x0d, 0x0a, '$'
    msgread db "read error...", 0x0d, 0x0a, '$'
    msgopen db "open error...", 0x0d, 0x0a, '$'



    filename2 db 'test2.txt',0
    filename1 db 'test1.txt',0
;--------------------------------------------------

    textbuf times 100 db 0
   
   
   
    filehnd1 db 0
    filehnd2 db 0

    read_len  db 0









[MJaoune]

hey i put hello in the test1.txt file and it prints hex into test2.txt ,i think.
but i did that 3 times and each time it printed different charecters each time.
is that normol?
and if it was a backup of my mbr would that cause a problem?
thanks

Maybe you have used the "mov" function to move the address, so you didn't use the [] brackets, double check the code (I was too lazy to read it) and see if you have "mov"ed the address of a register or a value and not the data.

If you are not using the brackets, then it would be equivalent to the C code:

Code: [Select]

int *p;
int tod;
p = &tod;

And then printing p to screen

By hex you must mean the address.

Best,
Mahmoud

[Frank Kotler]

You don't count 'em, dos does.

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

There's an error in your code, however!

Code: [Select]

   
                cmp     ax, 0           ;EOF reached?
                jne     EOF     

If "number of bytes read" is zero, you're at EOF.

Edit: Further, you need a word, not a byte, for each of your file handles!

Edit2: And for "len_read"!

Best,
Frank

[Frank Kotler]

its way different then vb 6 thats for sure

I dunno. We'd "say it" differently, but we should be doing the same functions. If we made the same errors - "dimensioning" a variable to the wrong size - it would give the same wrong results... but vb would probably generate an error.

HLLs need to know a lot of information about "types" since they need to generate the instructions. In asm, we're generating the instructions, so we need to keep track of "types", but the assembler doesn't need to know. There's more to "type" than "size". For example, a dword could represent an integer or a single-precision "float". Inappropriate instructions for a "type" will give incorrect results. Same with "signed" vs "unsigned" integers - we have to use the appropriate instructions.

It might, in fact, be enlightening to write out the intended operations in vb (or C/C++), whatever language you're familiar with, and "translate" to asm step by step. Code is code.

Best,
Frank

[Rob Neff]

It might, in fact, be enlightening to write out the intended operations in vb (or C/C++), whatever language you're familiar with, and "translate" to asm step by step. Code is code.

And if you output the assembly listing using the appropriate compiler switches you can see how the professional tools generate code.  It's very enlightening when you have optimizations turned on to guage just how good your compiler's output really is.