dosbox | Modification of dosbox with VNC support | Game Engine library

The choice command is available for dosbox and probably the only way to achieve what you want:

In the settings for this extension there's one called Working mode. By default it's set to single file. If you change to workspace it will mount the whole dir.

The .COM format has no structure, it's a flat binary.

The program (the whole file) is loaded to address 100h in some segment. Below that, you'll find the PSP for your program. The last usable word in the segment (usually at offset fffeh) will be overwritten with 0000h and the stack pointer pointed to it. This allows you to exit the program with a ret instruction.

DOS's program-loader sets all of CS, DS, ES, and SS to the segment of your program. Then, the DOS kernel jumps to address 0100h (i.e. the start of your program) to run it. (Technically, the program loader doesn't set cs until it does a far jmp or iret to the cs:100h; if it had set CS earlier, any IP value would be inside the new program's memory, not the DOS kernel.)

That's really all there is to it. Your program doesn't have to care about segmentation at all, as long as the flat 64K of the "tiny" memory model is sufficient for all your static code+data loaded from the file, stack at the top, and any memory in between as BSS or "heap". Any segment base works the same, so for example [bx] and [bp] address the same linear address even though bp implies ss: and bx implies ds:.

Note that because the DOS kernel picks a segment for your program, it won't collide with any already loaded programs or the DOS kernel. It'll just work as expected.

As for writing COM programs, I recommend using an assembler like NASM with output format “binary” (i.e. no output format). The general template is this:

The window() function from conio.h only defines an active window on the text screen. The default screen will be the 80x25 text screen. The coordinates that you specified in window(100, 100, 200, 200); are offscreen, so no window got created.
Try this:

Your code has much improved since your previous question, but because of the many errors that are still in there, I doubt it if someone could fully answer your "WHY???"

I will focus on one of your procedures, boundries, where you want to end the game if the snake collides with the top- or bottom rows or left- or right columns

The first test, cmp di,160 ja keep_playing, means that you keep playing provided the snake does not touch the top row of the screen. None of the other borders is even verified!
What you need if inverting the conditional jump like in cmp di, 160 jb stop_playing.

In the fourth test (for the right side border) you divide an odd number (because of the inc ax) by 160. This will always yield a non-zero remainder. So, not a useful test. To test for left- and right borders, you can do with just one division and interpret the remainder twice: 0 is a left side collision and 158 is a right side collision.

I just tried setting the ReadOnly attribute from a program running in DOSBox and it didn't work.

DOSBox's help via help /all, reports that the ATTRIB command does nothing and that it's provided for compatibility only. Therefore it stands to reason that the DOS.function 43h (Get/Set File Attributes) will not have been implemented.

Since DOSBox is primarily meant to emulate old DOS games, there's perhaps little reason to want to change attributes.

From comments

MOV AX, 'A' MOV BX, 10 DIV BL MOV AH, 2 INT 21h

This byte-sized division will leave a quotient in AL and a remainder in AH.
But the DOS.PrintCharacter function 02h expects its input in the DL register.

After DIV: ADD AH, 48 ADD AL, 48

Fine to convert, but you can do it in one go with ADD AX, 3030h

I got this output: ##

Try next code:

1. The game uses about 25MB of RAM in Linux, so does it have to use such an amount in DOS, too?

Linux executables are 32 or 64-bit whereas DOS is a 16-bit OS so many objects will be smaller in DOS. However many 32/64-bit operations in DOS would be longer in DOS due to obvious reasons, which means they'll require larger code space to accommodate. Depending on the code the memory usage in DOS may be smaller or larger

1. Is there a boundary value that limits the usage of RAM in DOS?

DOS (hence also FreeDOS) doesn't manage memory like that. Only a single process (excluding TSRs) runs at a single time so they own the whole memory space and manage that themselves. There's no need for process protection, a process can access everything

Besides DOS can't support more than 1MB RAM of memory. You have only 640KB of userspace RAM and that's the limit you get

You can access more memory with EMS, XMS but they don't belong to DOS and you'll have to explicitly load those libraries and call the appropriate APIs

For more information read DOS memory management