The Atari Resource

File Operations

GEMDOS places no restrictions on what a file may contain. Most applications assume that text files contain lines separated with carriage-return linefeeds, with a control-Z indicating the end of file. The format of executable files is documented in the Appendix.

The GEMDOS calls FcreateQ and Fopen() return small, positive 16-bit integers, called handles, that refer to open files. A file may be opened for reading only, for writing only, or for reading and writing. Closing the file relinquishes the handle, allowing the handle to be re-used.

There are three kinds of handles. Standard handles range from 0 to 5, and may refer to character devices or files. Non-standard handles start at 6, and refer only to files. Character handles refer only to character devices; the handle numbers range from Oxfffd to Oxffff. which are WORD negative, but not LONG negative.

When a process does a Pexec() call the child process inherits the parent's standard handles. Handle 0 is often referred to as "standard input" or "standard output"; normally it is connected to the console, CON:. With Fdup() and Fforce() calls it is possible to redirect a process's standard I/O to or from a file or. another character device.

When a media change occurs, all files open on the disk that was removed are forced closed by GEMDOS.

BUGS

There is no concept of "standard error" output.

Jtari n^MT^OC

PROCESSES

Although GEMDOS does not support multitasking, it is possible to execute processes in a subroutine-like manner. A process may "call" another with Pexec(); the child process will terminate with a WORD return code.

A process owns any files it opens and any memory it allocates. Open files are closed and memory is deallocated when the process terminates.

Before a process is actually terminated GEMDOS will call extended vector 0x102. This allows applications to make a "last ditch" effort to recover from error conditions, or to deinstall themselves.

The memory model used by GEMDOS is similar to MSDOS's. A process runs in the TPA (Transient Program Area). The first 0x100 bytes of the TPA is the process's basepage, which contains process-specific information.

Basepage Structure

offset		name	description 1
0x00		_1 owtpa	-> base of TPA |
0x04	P_	_hi tpa	-> end of TPA |
0x08	P_	_tbasre	base of text segment \
0x0c	P_	_t len	size of text segment j
0x10	P_	_dbase	base of data segment |
0x14	P_	_dlen	size of data segment J
0x18	P_	_bbase	size of BSS segment j
Ox 1 c	P_	blen	base of BSS segment J
0x20	P_	"dta	Disk Transfer Address (DTA)\
0x24	P_	parent	-> parent's basepage \
0x28	(reserved)
0x2c	P_	_env	-> enviroment string j
0x80	P_	_cmdl in	commandline image |

"p_lowtpa' points to the basepage (to itself). Kp_hitpa' points to the TPA's limit, to the first unusable 1ocation. "p_tbase' , vp_t1 en' and so on contain the starting addresses and sizes of the text, data and BSS segments. vp_parent' points to the process's parent process1s basepage. Vp_env' points to the enviroment string [see Pexec ()] .

The first byte of the command1ine image contains the number of characters in the command1ine. The second through Nth bytes contain the image. The image is not guaranteed to be null-terminated.

An application receives control at the starting address of its text segment. The second longword on the stack, 4(sp), will contain a pointer to the process's basepage. Normally all free memory is allocated to a new process; if the process is going to use MallocQ or Pexec() then it must relocate its stack and call MshrinkQ to release memory back to the system. The stack segment starts near the highest TPA location and grows toward the BSS.

0 0