When some/all com/exe receive control from MSDOS,
all available memory has been allocated and the onus
is on the executable to free it if it wishes to be able to
do some mallocs in the future.
What is the rationale for this, and what is the situation?
I have startup code below that resizes that memory, as
per rules I no longer remember. I'd like to remove this
code if possible because it hardcodes the segment
shift (4), and it prevents the code/data/stack being
placed in non-contiguous areas of memory.
Where do I stand?
Thanks. Paul.
So for all executables, all of memory is allocated until
released?
Do you think that ideally MSDOS 2.0 should have included
a call to auto-release extra memory?
That code shouldn't removed for TSRs and programs which need to spawn other program.
Do you think that ideally MSDOS 2.0 should have included
a call to auto-release extra memory?
There is no reliable way to know how much memory your program needs.
Only you know that.
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
So for all executables, all of memory is allocated until
released?
tlink (which is what I originally used) puts x'ffff' as the number
of paragraphs to allocate, meaning allocate all memory.
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?
What I would guess is that e_minalloc is the size of the
bss and stack segment.
And thus I don't know why you can't just copy the minalloc
value to the maxalloc.
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.
Or maybe minalloc is ONLY the bss size
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.
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.
If the SS/SP are disturbed it implies that the difference between
minalloc and maxalloc is put between the bss and stack.
That's a good idea.
2021-12-03 at 00:38 -0800, muta...@gmail.com wrote:
So for all executables, all of memory is allocated until
released?
AFAIK this is true only for COM files, where CS=DS=ES=SS.
On Friday, December 3, 2021 at 7:06:01 PM UTC+11, JJ wrote:
So for all executables, all of memory is allocated until
released?
Do you think that ideally MSDOS 2.0 should have included
a call to auto-release extra memory?
PDOS/86 has the ability to add extra calls like that. But I
need some way of testing whether I am running under a
PDOS-compliant (or some other existing standard). I was
thinking of getting the MSDOS version number and if it
was 0.1 or something like that, then it meant additional
calls were available to find more things like manufacturer
and capability (extra INT 21H calls).
BFN. Paul.
EXE files can be made to allocate the maximum available memory.
e.g. compiling a tiny model program into an EXE.
On Fri, 3 Dec 2021 09:45:00 +0100, Mateusz Viste wrote:
2021-12-03 at 00:38 -0800, muta...@gmail.com wrote:
So for all executables, all of memory is allocated until
released?
AFAIK this is true only for COM files, where CS=DS=ES=SS.
EXE files can be made to allocate the maximum available memory. e.g. compiling a tiny model program into an EXE.
PDOS/86 has the ability to add extra calls like that. But I
need some way of testing whether I am running under a
PDOS-compliant (or some other existing standard). I was
thinking of getting the MSDOS version number and if it
was 0.1 or something like that, then it meant additional
calls were available to find more things like manufacturer
and capability (extra INT 21H calls).
You can use the DOS OEM number returned by AH=30h. Though, that service is DOS 2.0+ only. For DOS 1.0, I don't think there's a CP/M specification to provide ID for CP/M variants.
In the case of Borlands Tasm it seems to be by design. And with no
option to override *I* had to "fiddle" the EXE headers. :-\
And pardon me saying so, but how is "by design" *not* "on purpose" :-)
"can be made", yes, through fiddling with exe headers,
but then that's done on purpose, and not a by-design
behavior, right?
Still, the Tasm tool does it on purpose.
It has choice, it just decides oterwise.
When dealing with COM files, there is no choice.
You sound as if you think it made the wrong one. Which decision do
you think should it have made and on what grounds ?
Now, just wondering aloud: is there an obvious reason why...
Tasm does not pre-set MAXALLOC to be the same as MINALLOC?
Isn't it because the EXE header is, in fact, not generated
by Tasm, but by the linker (tlink)?
Really ? You're suggesting that Tasm is some kind of culprit
and than "solve" it by telling us that its actually TLink who does it
I never suggested that, you did. Almost exactly 6 hours ago.
You seem to be misreading me. I am not solving anything,
merely suggesting that perhaps the problem is not where
you are pointing at.
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.
2021-12-04 at 14:00 +0700, JJ wrote:
On Fri, 3 Dec 2021 09:45:00 +0100, Mateusz Viste wrote:
2021-12-03 at 00:38 -0800, muta...@gmail.com wrote:
So for all executables, all of memory is allocated until
released?
AFAIK this is true only for COM files, where CS=DS=ES=SS.
EXE files can be made to allocate the maximum available memory. e.g.
compiling a tiny model program into an EXE.
"can be made", yes, through fiddling with exe headers, but then that's
done on purpose, and not a by-design behavior, right?
Mateusz
In the case
of high-level compilers, having a big MAXALLOC allows the runtime
to provide near pointers to the program via malloc(),
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.
to use a near pointer (offset only), the maxalloc won't
be able to be more than 64k, less the size of the stack,
less the size of the bss, less the size of the data section.
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.
... 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 :
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 415 |
Nodes: | 16 (2 / 14) |
Uptime: | 146:32:19 |
Calls: | 8,706 |
Calls today: | 10 |
Files: | 13,266 |
Messages: | 5,950,326 |