Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.os.msdos.programmer > #4081

Re: initial memory

Newsgroups comp.os.msdos.programmer
Date 2021-12-03 03:18 -0800
References <8808cb98-5cfd-444d-87ac-a71ef937f64cn@googlegroups.com> <socrrm$1tl0$1@gioia.aioe.org>
Message-ID <0e2bde4b-b93c-481c-9525-cdb03d863b1dn@googlegroups.com> (permalink)
Subject Re: initial memory
From "muta...@gmail.com" <mutazilah@gmail.com>

Show all headers | View raw


On Friday, December 3, 2021 at 9:34:34 PM UTC+11, R.Wieser wrote:

> > tlink (which is what I originally used) puts x'ffff' as the number 
> > of paragraphs to allocate, meaning allocate all memory.

> Indeed it does (using Borlands Tasm v4.1 and TLink v7.1). I've never been 
> able to find a "minimize footprint" switch or setting, which has irked me to 
> no end. You see, one of the fields in an .EXEs header is 
> "min_extra_paragraphs" , containing - you guessed it - exactly how much it 
> needs. As such I wrote a small program that copies that field into the 
> "max_extra_paragraphs" one (which is, in our case, the culprit), recalculate 
> the SS:SP value from it and put it into their respective fields. 

Could you explain these min/max/ss:sp rules please?

I see from here:

http://blog.marcinchwedczuk.pl/a-closer-look-at-portable-executable-msdos-stub

e_cp: 0x0003           // Pages in file

e_minalloc: 0x0000           // Minimum extra paragraphs needed
e_maxalloc: 0xffff           // Maximum extra paragraphs needed

        e_ss: 0x0000           // Initial (relative) SS value
        e_sp: 0x00b8           // Initial SP value

What I would guess is that e_minalloc is the size of the
bss and stack segment. e_cp is the size of the code and
data segments (not including bss).

And thus I don't know why you can't just copy the minalloc
value to the maxalloc.

Or maybe minalloc is ONLY the bss size, in which case the
maxalloc extends the BSS, and the stack is placed after that.
That would be surprising though, as it means when you
release the memory you create a hole. But maybe the
allocated memory doesn't include the stack in the first place.

Looking at the PDOS/86 code it looks like the stack size is
included, and you can't create a hole otherwise your stack
will be overwritten by a spawned program.

BFN. Paul.

Back to comp.os.msdos.programmer | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

initial memory "muta...@gmail.com" <mutazilah@gmail.com> - 2021-12-02 14:07 -0800
  Re: initial memory JJ <jj4public@gmail.com> - 2021-12-03 15:05 +0700
    Re: initial memory "muta...@gmail.com" <mutazilah@gmail.com> - 2021-12-03 00:38 -0800
      Re: initial memory Mateusz Viste <mateusz@xyz.invalid> - 2021-12-03 09:45 +0100
        Re: initial memory "muta...@gmail.com" <mutazilah@gmail.com> - 2021-12-03 01:22 -0800
        Re: initial memory JJ <jj4public@gmail.com> - 2021-12-04 14:00 +0700
          Re: initial memory "R.Wieser" <address@not.available> - 2021-12-04 08:39 +0100
          Re: initial memory Mateusz Viste <mateusz@xyz.invalid> - 2021-12-04 09:35 +0100
            Re: initial memory "R.Wieser" <address@not.available> - 2021-12-04 13:00 +0100
              Re: initial memory Mateusz Viste <mateusz@xyz.invalid> - 2021-12-04 13:12 +0100
                Re: initial memory "R.Wieser" <address@not.available> - 2021-12-04 15:55 +0100
                Re: initial memory Mateusz Viste <mateusz@xyz.invalid> - 2021-12-04 16:30 +0100
                Re: initial memory "R.Wieser" <address@not.available> - 2021-12-04 18:11 +0100
                Re: initial memory Mateusz Viste <mateusz@xyz.invalid> - 2021-12-04 19:04 +0100
                Re: initial memory "R.Wieser" <address@not.available> - 2021-12-04 21:02 +0100
                Re: initial memory "muta...@gmail.com" <mutazilah@gmail.com> - 2021-12-05 15:01 -0800
                Re: initial memory Mateusz Viste <mateusz@xyz.invalid> - 2021-12-06 09:27 +0100
            Re: initial memory JJ <jj4public@gmail.com> - 2021-12-05 14:03 +0700
      Re: initial memory JJ <jj4public@gmail.com> - 2021-12-04 14:01 +0700
        Re: initial memory "muta...@gmail.com" <mutazilah@gmail.com> - 2021-12-04 02:00 -0800
          Re: initial memory JJ <jj4public@gmail.com> - 2021-12-05 14:12 +0700
            Re: initial memory "muta...@gmail.com" <mutazilah@gmail.com> - 2021-12-05 15:02 -0800
              Re: initial memory JJ <jj4public@gmail.com> - 2021-12-06 13:28 +0700
  Re: initial memory "R.Wieser" <address@not.available> - 2021-12-03 11:25 +0100
    Re: initial memory "muta...@gmail.com" <mutazilah@gmail.com> - 2021-12-03 03:18 -0800
      Re: initial memory "R.Wieser" <address@not.available> - 2021-12-03 14:19 +0100
        Re: initial memory "muta...@gmail.com" <mutazilah@gmail.com> - 2021-12-03 11:35 -0800
          Re: initial memory "R.Wieser" <address@not.available> - 2021-12-03 22:30 +0100
            Re: initial memory - SS:SP "R.Wieser" <address@not.available> - 2021-12-06 14:32 +0100
              Re: initial memory - SS:SP "R.Wieser" <address@not.available> - 2021-12-06 14:51 +0100

csiph-web