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.

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.

2021-12-05 at 15:01 -0800, muta...@gmail.com wrote:
> 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.

SS might be somewhere else in the small model. Your remark is perfectly
valid for the tiny model of course. MAXALLOC is a way (for the
compiler/programmer) to tell DOS "please try putting this program
somewhere in memory where extra space is available because I might want
to use such near memory". From within a C program, the usual way (for
the programmer) to reclaim this memory is via malloc/calloc.

I can only imagine that's why the tlink thing maxes out MAXALLOC: it
assumes it might be used as a memory pool for runtime C near
malloc/calloc calls. This is, however, for those like Rudy using tasm,
since in a constrained environment (last 64K block used by DOS to load
the program) they won't be able to obtain any memory via int 21h,48h.

A possible workaround is to pre-allocate the necessary buffers through
a table (or some other filler) within assembly. The downside of this
solution is that it will obviously make the on-disk size of the program
that much larger. And you must know the amount of memory you need in
advance, too.

Mateusz

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

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