程序集x86-如何在变量之间移动字符串

Question

(running assembly x86 through DOSBOX)

I'm using procedures to load an image (bmp file) and the first one is to load the file (open it):

proc OpenFile
    mov ah, 3Dh
    xor al, al
    mov dx, offset filename
    int 21h
    jc openerror1
    mov [filehandle], ax
    ret
    openerror1:
    mov dx, offset ErrorMsg
    mov ah, 9h
    int 21h
    ret
endp

I want filename to be used as a global variable for a name of a file - string of its path so the only thing I have to do before running all the procs is to move the right path to the filename variable.

filename db ?
img1 db 'img1.bmp',0
img2 db 'img2.bmp',0

I thought it's some kind of string transferring and I found out that the MOVS command might be helpful but I didn't manage to understand the way it works.

Answer 1

Just a short example how MOVS works (and others from the "string" instruction family are similar).

First you need space in memory, so in your case that filename has to be extended.

MAX_FILE_NAME_LENGTH    EQU  128
filename    db MAX_FILE_NAME_LENGTH dup (?)   ; reserving enough space for "string"
img1        db 'img1.bmp',0
img1length  equ $-img1
img2        db 'img2.bmp',0
img2length  equ $-img2

Now to copy img2 "string" into filename ... img2 is address into memory, where the following img2length bytes are defined by the db above (including the zero separator). And target address is the filename symbol. The MOVS copies data from ds:si ( si as "Source") to es:di ( di as "Destination").

...
; make sure the DS and ES are set up correctly, if you use data segment, then
; (this can be done just once, if you don't change ds/es in your code any more)
mov ax, @data
mov ds, ax
mov es, ax
cld             ; DF=0, if you don't plan to use DF=1 elsewhere
  ; DF=0 means, that the "string" instructions increment SI/DI
  ; DF=1 would make them run backwards, decrementing addresses
  ; (that's handy when implementing "memmove" with overlapping areas)
...

...
; now prepare registers (except ds+es) for `rep movsb` variant
mov cx, img2length   ; how many bytes to copy (numeric value)
lea si, [img2]       ; offset img2 into SI
lea di, [filename]   ; offset filename into DI
rep movsb            ; copy "img2length" bytes from ds:si to es:di

; check memory in debugger, the reserved area at "filename" should
; now contain the copied string, including the zero terminator

; WARNING, if you forget about reserved space limitations, and define
; img2 string longer than MAX_FILE_NAME_LENGTH, the code above will
; merrily overwrite more memory than expected, destroying values in memory
; beyond the filename buffer

...

---

Another variant with pointers example:

Common practice is to pass value to function as an argument, in this case you may ask the caller to pre-set ds:dx ahead of OpenFile call, then you just omit the dx setup code in the procedure, and you are done, example:

; arguments: ds:dx = pointer to ASCIIZ file name
; returns (and modifies): ax = file handle
; in case of file error "..." happens
proc OpenFile
    mov ax, 3D00h    ; ah = 3D "open file", al = 0 "read-only"
    int 21h
    jc openerror1
    ret
    openerror1:
    ... ; probably terminate app any way in case of error

Then ahead of each call you set up ds:dx, and after store the file handle as you wish:

    ...
    ; let's pretend the DS was already set before
    mov    dx, offset img1
    call   OpenFile
    mov    [img1FileHandle],ax
    ...

Data being set up like this:

img1 db 'img1.bmp',0
img1FileHandle dw 2    ; DW, because handle is 16 bit "wide" (AX = 16 bits)
  ; 2 == STDERR, until the code will run OpenFile and store real handle

It's also possible to put those things into globals in memory, and then read them from memory inside OpenFile , but if you will try to write that, you will see it's quite cumbersome, passing arguments in registers is simpler... up to a point, until your code gets complex enough to forget what procedure needs what in which register, and suddenly it becomes a bit of mess.

From there it's better to follow some official calling convention, like cdecl and similar, but most of calling conventions for 16b/32b modes did use stack for passing arguments, which is again a bit tedious to write by hand, and also performs worse than passing values by registers. For small pure asm applications feel free to optimize each procedure arguments/results as they fit, and just comment each procedure with clear description which registers are used.