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

Groups > comp.os.msdos.programmer > #4075 > unrolled thread

initial memory

Back to article view | Back to comp.os.msdos.programmer

Contents

  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

Page 2 of 2 — ← Prev page 1 [2]

#4106

On Sat, 4 Dec 2021 02:00:15 -0800 (PST), muta...@gmail.com wrote:
> 
> I see that Freedos already has a number. I might make
> contact with them. I really need a number that does not
> represent a particular OEM but instead a "standard". And
> I just realized that if MSDOS was theoretically updated to
> follow the standard, they wouldn't be able to switch to that
> new number. Hmmm. Maybe they could. Maybe everyone
> who wished to follow the standard could switch to that
> number, and then if they wanted the "true manufacturer"
> they have to do another API call.

Nowadays, OS detection by detecting OS features is more reliable than simply 
reading the OS ID.

[toc] | [prev] | [next] | [standalone]

#4115

On Sunday, December 5, 2021 at 6:12:53 PM UTC+11, JJ wrote:

> > I see that Freedos already has a number. I might make 
> > contact with them. I really need a number that does not 
> > represent a particular OEM but instead a "standard". And 
> > I just realized that if MSDOS was theoretically updated to 
> > follow the standard, they wouldn't be able to switch to that 
> > new number. Hmmm. Maybe they could. Maybe everyone 
> > who wished to follow the standard could switch to that 
> > number, and then if they wanted the "true manufacturer" 
> > they have to do another API call.

> Nowadays, OS detection by detecting OS features is more reliable than simply 
> reading the OS ID.

It's actually OS features rather than OS ID that I want. How do
you suggest I do that? I need to know if the new style memory
allocation routine exists etc.

Thanks. Paul.

[toc] | [prev] | [next] | [standalone]

#4117

On Sun, 5 Dec 2021 15:02:36 -0800 (PST), muta...@gmail.com wrote:
> 
> It's actually OS features rather than OS ID that I want. How do
> you suggest I do that? I need to know if the new style memory
> allocation routine exists etc.
> 
> Thanks. Paul.

You'll have to try using a feature and check whether the OS supports it or
not. Though, standard/common features are likely already supported by most
DOS variants. So, undocumented features are better targets. Or check
features which are non standard, or specific to a DOS variant. Preferrably,
those which are actually used by the included tools of those DOS variants to
check whether they're running in their own OS or not.

Other things that can be used is the fact that while all DOS variants likely
to already support all standard DOS features, their implementations are not.
It could be that some DOS services have different behaviour/algorithm, or
give different result. Or the OS has different/unusual data placements/order
for e.g. BUFFERS, FILES, and standard devices such as AUX, CON, PRN, etc.

[toc] | [prev] | [next] | [standalone]

#4080

Muta,

> I have startup code below that resizes that memory, as
> per rules I no longer remember.
...
> mov ax, sp
> mov cl, 4
> shr ax, cl ; get sp into pages

When a COM runs SP is set to the end of the SS segment.  As a COM has all 
the segments overlapping its upto how big your program is how much stack you 
are actually reserving. But looking at my own programs I don't think that 
reserving 60KB stack for a 4KB program is normally called for.

Hence I set SP myself (sometimes even to the programs top at 0100h) and 
instead use a LASTBYTE label to figure out how much room I actually need 
calculated the # of pages from it :

- - - - - - - - - - - - - - - - - - - -
 lea sp,[StackTop]        ;Set new Stack-top

 mov bx,(offset LASTBYTE)+000Fh ;number of bytes in program + round-up
 mov cl,04h    ;convert to pages
 shr bx,cl    ;/
 mov ah,4ah    ;resize program space
 int 21h    ;/
 jc @@Main_Error   ;ERROR : Out of Memory !
- - - - - - - - - - - - - - - - - - - -

As you might see, I also made sure I could actually allocate it, as its 
possible a COM gets loaded in a memory fragment thats not actually large 
enough to hold it and the "extra" memory it needs.

> So for all executables, all of memory is allocated until
> released?

Yes for a .COM style program, and "it depends" for a .EXE style one - as 
that latter one has got a header wich specifies lots of stuff.

> 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.

From than on the OS does, for the .EXE, all the work for me, allowing me to 
drop the "shrink my memory" code from it. :-)

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#4081

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.

[toc] | [prev] | [next] | [standalone]

#4082

Mta (paul),

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

Perhaps.  Its a while ago ...

> What I would guess is that e_minalloc is the size of the
> bss and stack segment.

Yup.

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

Thats exactly what I did.

But when you do that you also need to recalculate SS/SP, otherwise it most 
likely will point far beyond your program.  Which is not a good idea.

> Looking at the PDOS/86 code it looks like the stack size is
> included,

Yep.  Its comprised of all data areas that have no ititial value.

> and you can't create a hole otherwise your stack
> will be overwritten by a spawned program.

I think we need to define what a "hole" is here.   But yes, its never a good 
idea use memory areas you do not own for either BSS or stack.

> Or maybe minalloc is ONLY the bss size

Definitily not.

But why don't you just try to make a program in which you enlarge the code, 
BSS and stack areas (several combinations) and look at how the fields in the 
EXE header change ?   I found the EXE header info on the web and that is 
what I did to verify if I understood it right.

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#4083

On Saturday, December 4, 2021 at 12:20:05 AM UTC+11, R.Wieser wrote:

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

> Thats exactly what I did. 
> 
> But when you do that you also need to recalculate SS/SP, otherwise it most 
> likely will point far beyond your program. Which is not a good idea.

If the SS/SP are disturbed it implies that the difference between
minalloc and maxalloc is put between the bss and stack.

In addition, it means when MSDOS is loading the program,
it would need to manipulate the SS itself, depending how
much memory between minalloc and maxalloc it was able
to allocate.

> But why don't you just try to make a program in which you enlarge the code, 
> BSS and stack areas (several combinations) and look at how the fields in the 
> EXE header change ? I found the EXE header info on the web and that is 
> what I did to verify if I understood it right. 

That's a good idea.

Thanks. Paul.

[toc] | [prev] | [next] | [standalone]

#4084

Muta (paul),

> If the SS/SP are disturbed it implies that the difference between
> minalloc and maxalloc is put between the bss and stack.

Nope.  Minalloc refers to to the end of the combined the bss and following 
stack segments.  Maxalloc can go, as you read yourself, way beyond that.

But I owe you an apology : I remember updating SS/SP after setting MaxAlloc 
to MinAlloc, but a peek into my program (still have it!) showed I made it 
optional.  In case I did not define a stack segment at all (but just kept 
some BSS space free for it), causing SS:SP to be Zero in the EXE header. 
And that ofcourse doesn't really work.  So, I than can force it to be set to 
the end of the BSS segment itself.

IOW, for a program in which a stack segment has been defined you only need, 
as you mentioned, to copy MinAlloc into MaxAlloc.

I hope I did not create to much of a confusion.

> That's a good idea.

:-)  Its the way I've had to, and still do figure out lots of stuff, which 
sometimes makes you run into the darnest things.  And even when full 
documentation was/is available I always had/have the need to verify what was 
said.

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#4120 — Re: initial memory - SS:SP

Muta (paul),

> But I owe you an apology : I remember updating SS/SP after setting 
> MaxAlloc to MinAlloc, but a peek into my program (still have it!) showed I 
> made it optional.  In case I did not define a stack segment at all (but 
> just kept some BSS space free for it), causing SS:SP to be Zero in the EXE 
> header. And that ofcourse doesn't really work.  So, I than can force it to 
> be set to the end of the BSS segment itself.

I took another look at the EXE header and how it sets up SS:SP. I had to 
notice that regardless of the memory model I chose (tiny, small, etc.) it 
was either 0:0, or SS being an offset to the defined ".stack ..." area and 
SP its size.  IOW, it /never/ pointed at what DS should be(come).

As I always use the "tiny" memory model (again, my programs never get /that/ 
big), a (p)recalculation of SS:SP is rather simple : add (SS - CS) * 10h to 
SP and set SS to Zero.   In the program itself than only CS needs to be 
copied to DS (and possibly ES).

In all other memory models this is not possible as there DS is never equal 
CS, and DS is not mentioned in the executables header (meaning you can't 
recalculate SS in reference to it)

... having said that, if you want to use memory models other than "tiny" you 
could try to see if you could find the start of the _DATA segment from the 
generated .LST file :

-- "Tiny" memory model

DGROUP      Group
..STACK      16  0100 Para   Stack   STACK
.._BSS      16  000E Word   Public  BSS
.._DATA      16  0017 Word   Public  DATA
.._TEXT      16  0958 Word   Public  CODE

(".." indicates indentation)

The above looks to be indicating that all groups are inside DGROUP.

-- "Small" memory model

DGROUP      Group
..STACK      16  0100 Para   Stack   STACK
.._BSS      16  0800 Word   Public  BSS
.._DATA      16  0043 Word   Public  DATA
_TEXT      16  0288 Word   Public  CODE

Here the "_TEXT" group is outside the DGROUP.  The start of the "_DATA" 
segment /should/ therefore be the size of the "_TEXT" segment, rounded-up to 
the next segment ofcourse -> 0290.  And a quick check in the executable 
shows that is indeed the case.

A double check using "mov ax,_DATA" shows the same (subtract CS and multiply 
by 10h)

Caveat : I've only looked at the TINY and SMALL models, in Tasms default 
configuration (its possible to have the segments in a different order).

Hope that helps.

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#4122 — Re: initial memory - SS:SP

Muta (paul),

> ... having said that, if you want to use memory models other than "tiny" 
> you could try to see if you could find the start of the _DATA segment from 
> the generated .LST file :

I forgot all about the .MAP file.  Even easier, as it already contains the 
starting offsets of each segment.

Regards,
Rudy Wieser

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.os.msdos.programmer

csiph-web