DOS memory / .COM files

[southbird]

So I know that .COM files are basically really simplistic executables (at their leanest anyway) that are assumed to start at 0x100 and run within a single segment... normally.

What I'm curious is, how hard is it for a .COM to be "bad" and utilize more segments?

Is it dangerous to switch arbitrarily to another segment and start writing memory into it, or is there a proper way to declare I want another segment?

Is it just plain better practice to use a full scale EXE file when multiple segments are required?

Note that the theoretical .COM itself will not exceed 64KB in size. I'm just looking to create a small program that may operate on a larger-than-one-64KB-segment size dataset.

 

[Chuck(G)]

When a .COM file starts, it's normally given all of the available contiguous memory from its load segment. You can find out how much that is by looking at PSP + 02,03, for your total available memory size in paragraphs.

That's why you have to tell DOS how much memory to keep when you're writing a terminate-and-stay-resident program.

Now, there may be more memory available to you, but it's not going to be contiguous to your program area. You can determine where and how much that is by using the DOS memory allocation calls.

A COM program is restricted to 64K on load; i.e., DOS will not load a program file larger than that. However, there's no reason a COM program can't load more code of its own; many older programs do just that.

 

[southbird]

How likely is it that the memory is going to be contiguous? That is, does DOS typically push TSRs and other drives to the end of memory, or is it potentially scattered?

 

[Chuck(G)]

TSRs generally occupy memory starting wtih lower locations. Fragmentation can occur, particularly if a TSR make sue of the DOS memory allocation calls. Use the "mem /d" command to see how memory is allocated on your own system.