so many questions, so many troubles

[Gunther]

Dave,

i think ES:BX points to the environment table - i forget

that's right: es:bx -> program's environment block.

Gunther

[FORTRANS]

Hi,

   The "MS-DOS Programmer's Reference" says that DS and ES
point to the PSP when the program starts.  The environment is
a different area in memory that has strings for the path and variables
that are set by the SET command for instance.

   The Hugi contest had some information on the registers on program
load.  Here is a cut and paste from their "GENERAL.TXT".

=============================================================================
            h u g i   s i z e   c o d i n g   c o m p e t i t i o n

                            g e n e r a l   i n f o
=============================================================================

You may assume that
  ... the registers have these values (all in hex):
      (xx - means an unknown value which MUST NOT be assumed)

          EAX = xxxx****
                AL = 00 if first FCB has valid drive letter,  FF if not
                AH = 00 if second FCB has valid drive letter, FF if not
          EBX = xxxx****
                BL = 00 if first FCB has valid drive letter,  FF if not
                BH = 00 if second FCB has valid drive letter, FF if not
          ECX = xxxx00FF
          EDX = xxxxxxxx
  DX  = CS = DS = ES = SS = xxxx, 0080 <= DX <=9000.
          ESI = xxxx0100
          EDI = xxxxFFFE
          EBP = xxxx09xx
          ESP = xxxxFFFE
          EIP = xxxx0100

Regards,

Steve N.

[dedndave]

hi Steve
those look like values for, possibly, a .COM program
however, i think you're right about ES:BX not pointing to the environment table
the segment for the environment block is in the PSP, someplace
the ES:BX thing may have applied for the Exec loader (i don't remember the INT number)

for a .COM program, CS = DS = ES = SS = PSP segment
for a .EXE program, CS = code, DS = ES = PSP, and SS = stack segment

as far as i recall, AX is the only general register that carried any info
the others were set to 0

when the CPU is reset, the DX register has something in it - i forget what

[jj2007]

16-bit exe on Win XP SP3:

include \masm32\MasmBasic\DosBasic.inc         ; download the complete MasmBasic library
PrintReg MACRO arg
  pushad
  mov ebx, arg
  ifidn <arg>, <esp>
        add ebx, 32
  endif
  Print Hex$(bx), " is &arg", 13, 10
  popad
ENDM

  Init                        ; DosBasic inspired by DednDave
  PrintReg eax
  PrintReg ebx
  PrintReg ecx
  PrintReg edx
  PrintReg esi
  PrintReg edi
  PrintReg ebp
  PrintReg esp
  Inkey "bye"                ; wait for a key
  Exit                        ; ExitProcess, DOS style
end start

Output:
0FC2 is eax
0000 is ebx
00FF is ecx
0F85 is edx
0000 is esi
0200 is edi
091E is ebp
0200 is esp

[dedndave]

your Init macro alters some registers
EAX, at least - that looks like the data segment   :P

you might try

Code: [Select]

    pushad
    Init
    mov    ebp,esp

;[EBP+28]  ;EAX
;[EBP+24]  ;ECX
;[EBP+20]  ;EDX
;[EBP+16]  ;EBX
;[EBP+12]  ;ESP
;[EBP+8]   ;EBP
;[EBP+4]   ;ESI
;[EBP]     ;EDI
you can test AL and AH by filling the FCB's

Code: [Select]

C:\>programname somevalidfilename1 somevalidfilename2

[jj2007]

your Init macro alters some registers
EAX, at least - that looks like the data segment   :P

Thanks, that's right, but it concerns eax only:
  mov ax, @DATA   ; set the DS register to DGROUP
  mov ds, ax      ; for ds:si (lods)
  mov es, ax      ; for es:di (scas, stos)

Real eax is zero.

[dedndave]

 :t

what about PrintReg - it probably preserves everything
EDX looks like it might be the code segment

[MichaelW]

This is the structure from the Microsoft documentation… complete with the we-could-tell-you-what-they-are-but-then-we’d-have-to-kill-you members.

Code: [Select]

PSP STRUC
   pspInt20             dw ?
   pspNextParagraph     dw ?
   pspReserved1         db ?
   pspDispatcher        db 5 dup(?)
   pspTerminateVector   dd ?
   pspControlCVector    dd ?
   pspCritErrorVector   dd ?
   pspReserved2         dw 11 dup(?)
   pspEnvironment       dw ?
   pspReserved3         dw 23 dup(?)
   pspFCB_1             db 16 dup(?)
   pspFCB_2             db 16 dup(?)
   pspReserved4         dd ?
   pspCommandTail       db 128 dup(?)
PSP ENDS


[dedndave]

Ralf has descriptions of the other fields, which vary from OS to OS of course   :P
but, it's nice to see the "official" names - thanks Michael   :t

it's a little nostalgic to see the old "STRUC" keyword - lol

[FORTRANS]

hi Steve
those look like values for, possibly, a .COM program

Hi Dave,

   Correct.  For a size competition *.COM programs are smaller
than *.EXE.  I just showed the other info to show what they had
found.

   The MS-DOS reference only mentions the setting of AH, AL, the
segment registers, IP, and SP.  The rest are not mentioned.  ES,
and DS point to the PSP for both *.COM and *.EXE programs, as
you showed below.  And as AH and AL are treated the same in
both program types, maybe the other registers would be also.

however, i think you're right about ES:BX not pointing to the environment table
the segment for the environment block is in the PSP, someplace
the ES:BX thing may have applied for the Exec loader (i don't remember the INT number)

for a .COM program, CS = DS = ES = SS = PSP segment
for a .EXE program, CS = code, DS = ES = PSP, and SS = stack segment

as far as i recall, AX is the only general register that carried any info
the others were set to 0

when the CPU is reset, the DX register has something in it - i forget what

   The 386, and later, powers up with stepping information in DX
or EDX.  This is from memory, with all the usual disclaimers.

Regards,

Steve N.

[dedndave]

i'm going to go out on a limb, here, and say that
BX, CX, DX, SI, DI, and BP are undefined
Jochen shows they have some values in them
but, if you fire up a COM or EXE in DEBUG, they are mostly 0's
it uses BX:CX to show loaded file size - strictly a DEBUG thing

AX will be 0 unless you place some parsable filenames on the command line
this is a DOS thing

[FORTRANS]

Hi,

   Yes, starting in DEBUG gives different results.  That has bitten
me at least once.  Though I cannot find anything that says what
or when it was.

   But I did find a few other things.  One of which is a link that has
some tests of various versions of DOS.

http://www.fysnet.net/yourhelp.htm

Regards,

Steve N.

[dedndave]

i am going to update my EXE template

Code: [Select]

        mov     dx,@data
        mov     ds,dxthat way, the contents of AX are not destroyed
Jochen may want to make the same change in his Init macro

[Sam]

Hi Sam,

Your code runs fine on Win7-32 if
a) you add the start: label,
b) you add end start
c) you use the 16-bit linker in \masm32\bin\link16.exe (Hutch will explain to you how to do that from qEditor - I use my own editor).

Greetings to Syria,
JJ

.MODEL SMALL
.DATA
var1 db 33h
var2 dw 0101h
var3 dd 0aaaa5555h
; include io.mac
.code
.386
start:
mov ax,0
mov al,0ah
mov [bx],al
mov [bx+1],al
mov eax,12345678h
.exit
end start

hey buddy so I did that and the editor went crazy I gave like tons of this error: A2044 invalid character in file, and it actually in this link16.exe

[Sam]

Mutter, I have not played with 16 bit dos since 1994.

SAM.ASM

Code: [Select]

.386
.MODEL SMALL
.DATA
  var1 db 33h
  var2 dw 0101h
  var3 dd 0aaaa5555h

;;; include io.mac      ; you have to supply the file IO.MAC

.code

start:                  ; the start label

  mov ax, 0
  mov al, 0ah
  mov [bx], al
  mov [bx+1], al
  mov eax, 12345678h

end start

Builds with the following batch file in the same directory,

Code: [Select]

@echo off
\masm32\bin\ml.exe /omf sam.asm
\masm32\bin\link16.exe sam.obj,sam.exe ,,, /nod /noe /packc /stack:4096
dir sam.exe
pause


thanks my frnd for ur help
so waht am I suppposed to do with this batch thing?? am I supposed to just copy it to the code??