llm wrote on 2022-03-26, 09:53:

i though exe program do not allocate the complete free ram like com programs - am im wrong - can find any references

But only if the .exe does not request all the memory, and many linkers set it to request all the memory . See the value of the "Maximum allocation" in your .exe ( https://wiki.osdev.org/MZ ) , likely it is FFFF . I actually don't remember how to change this from MASM, I used to change it afterwards via EXEMOD or the like (but you can change it by hand for a test).

javispedro1 wrote on 2022-03-26, 11:57:

llm wrote on 2022-03-26, 09:53:

i though exe program do not allocate the complete free ram like com programs - am im wrong - can find any references

But only if the .exe does not request all the memory, and many linkers set it to request all the memory . See the value of the "Maximum allocation" in your .exe ( https://wiki.osdev.org/MZ ) , likely it is FFFF . I actually don't remember how to change this from MASM, I used to change it afterwards via EXEMOD or the like (but you can change it by hand for a test).

its seems that my MaxExtraParagraphs in the exe header is my problem

radare2-5.6.6-w64\bin\rabin2.exe -H output

1"hello.exe"
2ii 120 80
3[0000:0000]  Signature           MZ
4[0000:0002]  BytesInLastBlock    0x0078
5[0000:0004]  BlocksInFile        0x0001
6[0000:0006]  NumRelocs           0x0001
7[0000:0008]  HeaderParagraphs    0x0005
8[0000:000a]  MinExtraParagraphs  0x0021
9[0000:000c]  MaxExtraParagraphs  0xffff <------
10[0000:000e]  InitialSs           0x0003
11[0000:0010]  InitialSp           0x0200
12[0000:0012]  Checksum            0x0000
13[0000:0014]  InitialIp           0x0000
14[0000:0016]  InitialCs           0x0000
15[0000:0018]  RelocTableOffset    0x0040
16[0000:001a]  OverlayNumber       0x0000
17
18"exeload.exe"
19ii 184 80
20[0000:0000]  Signature           MZ
21[0000:0002]  BytesInLastBlock    0x00b8
22[0000:0004]  BlocksInFile        0x0001
23[0000:0006]  NumRelocs           0x0002
24[0000:0008]  HeaderParagraphs    0x0005
25[0000:000a]  MinExtraParagraphs  0x0021
26[0000:000c]  MaxExtraParagraphs  0xffff <------
27[0000:000e]  InitialSs           0x0007
28[0000:0010]  InitialSp           0x0200
29[0000:0012]  Checksum            0x0000
30[0000:0014]  InitialIp           0x0000
31[0000:0016]  InitialCs           0x0000
32[0000:0018]  RelocTableOffset    0x0040
33[0000:001a]  OverlayNumber       0x0000

i've got

latest EXEMOD.EXE 4.02 from Microsoft C 5.1 (DOS only)
latest EXEHDR.EXE 3.20 from Visual C++ 1.52c (runs also under Win64)

changed the max paragraphs to 0x21 for both - works

thanks for the info

llm wrote on 2022-03-27, 06:23:

latest EXEMOD.EXE 4.02 from Microsoft C 5.1 (DOS only)

MS-DOS Player could be helpful then.
http://takeda-toshiya.my.coocan.jp/msdos/

llm wrote on 2022-03-27, 06:23:

latest EXEHDR.EXE 3.20 from Visual C++ 1.52c (runs also under Win64)

It likely is a Win32 CLI application then.
I think older versions of Visual C++ tools ran on Windows 3.1x Command Prompt, as well.
So they likely were DOS text-mode applications, maybe with an extra Win32 CLI stub, not sure.

I remember MASM/LINK specifically has a command line argument to set the max allocation size to something else other than 0xFFFF. I also remember it's a command line argument, not a directive.
But I totally forgot the name of the flag 🙁
I always used later exemod since many linkers don't have this flag anyway. Cough, watcom.

your com program that is doing the 4B needs to resize its memory with 4A, taking your stack into account.

eg:

mov sp,end_stack
mov ah,0x4a
mov bx,sp
shr bx,4
inc bx
int 0x21

;; last line in your code
resw 128 dw 0
end_stack:

javispedro1 wrote on 2022-04-15, 12:34:

I remember MASM/LINK specifically has a command line argument to set the max allocation size to something else other than 0xFFFF. I also remember it's a command line argument, not a directive.
But I totally forgot the name of the flag 🙁
I always used later exemod since many linkers don't have this flag anyway. Cough, watcom.

im using exemod oder the -p- flag of UniLinker that sets the minimum in the header while linking

BloodyCactus wrote on 2022-04-15, 15:37:

your com program that is doing the 4B needs to resize its memory with 4A, taking your stack into account.

i don't need further dynamic memory allocation in this case, so i think it is ok that the called program claims all memory until its exited

llm wrote on 2022-04-16, 15:23:

BloodyCactus wrote on 2022-04-15, 15:37:

your com program that is doing the 4B needs to resize its memory with 4A, taking your stack into account.

i don't need further dynamic memory allocation in this case, so i think it is ok that the called program claims all memory until its exited

no, your exeload needs to resize itself to its minimum it needs, so the rest of memory is free for dos to load your hello program.

BloodyCactus wrote on 2022-04-16, 17:07:

llm wrote on 2022-04-16, 15:23:

BloodyCactus wrote on 2022-04-15, 15:37:

your com program that is doing the 4B needs to resize its memory with 4A, taking your stack into account.

i don't need further dynamic memory allocation in this case, so i think it is ok that the called program claims all memory until its exited

no, your exeload needs to resize itself to its minimum it needs, so the rest of memory is free for dos to load your hello program.

1. my problem is already solved since 2022-03-27
2. as i wrote: im using a linker command that reduces my minimum heap use in the exe header (so no need for modifiying my ram usage at runtime)
i can do also use EXEHDR.EXE or modify with int 21h/4Ah - but the linker is already doing the work for me

llm wrote on 2022-04-16, 18:42:

1. my problem is already solved since 2022-03-27
2. as i wrote: im using a linker command that reduces my minimum heap use in the exe header (so no need for modifiying my ram usage at runtime)
i can do also use EXEHDR.EXE or modify with int 21h/4Ah - but the linker is already doing the work for me

the moment anything else touches that header your screwed (a packer, encryption, virus, anything that can mod the exe), you should always do it yourself than rely on magic in the header that is always manipulated by anything that wants to touch the header.

BloodyCactus wrote on 2022-04-16, 21:08:

the moment anything else touches that header your screwed (a packer, encryption, virus, anything that can mod the exe), you should always do it yourself than rely on magic in the header that is always manipulated by anything that wants to touch the header.

What magic in the header, this is the actual documented method. You might as well claim that "why use exe at all, a virus could corrupt it, we should all stay with com as god intended". 😁

Also, I had to look at the MASM manual so I found it: the corresponding MS LINK.EXE option is /CP (apparently an abbrv of "CPARMAXALLOC" . with that mnemonic, no wonder I can't remember it ) . For whomever finds this thread 😀

javispedro1 wrote on 2022-04-16, 22:23:

BloodyCactus wrote on 2022-04-16, 21:08:

the moment anything else touches that header your screwed (a packer, encryption, virus, anything that can mod the exe), you should always do it yourself than rely on magic in the header that is always manipulated by anything that wants to touch the header.

What magic in the header, this is the actual documented method. You might as well claim that "why use exe at all, a virus could corrupt it, we should all stay with com as god intended". 😁

Also, I had to look at the MASM manual so I found it: the corresponding MS LINK.EXE option is /CP (apparently an abbrv of "CPARMAXALLOC" . with that mnemonic, no wonder I can't remember it ) . For whomever finds this thread 😀

its also /CPARMAXALLOC for OptLink (from Digitalmars dmc/dmd) and -p- for UniLinker , watcom wlink does not support such an option

BloodyCactus wrote on 2022-04-16, 21:08:

llm wrote on 2022-04-16, 18:42:

1. my problem is already solved since 2022-03-27
2. as i wrote: im using a linker command that reduces my minimum heap use in the exe header (so no need for modifiying my ram usage at runtime)
i can do also use EXEHDR.EXE or modify with int 21h/4Ah - but the linker is already doing the work for me

the moment anything else touches that header your screwed (a packer, encryption, virus, anything that can mod the exe), you should always do it yourself than rely on magic in the header that is always manipulated by anything that wants to touch the header.

why should that - the microsoft linker and some others support it
and for example exepack (and other exe modifying tools) need to directly rely on the header field infos - no tool can ignore the header info or the result will not work correct