Hi Pablo,
FreeDOS supports almost all int 21 functions of MS DOS 5/6,
so you can just read any generic "DOS programming" book to
get the details. I recommend Ralf Brown's Interrupt List,
which is freely downloadable (you should download it instead
of using the online HTML version if you plan to do a lot of
DOS programming) and very verbose.
When you download the kernel sources, some files about the
current state of implementation are included. One of the
missing features is for example DBCS (double byte character
support), so you cannot yet use Chinese or Japanese fonts.
The docs might be outdated, but they state:
Not implemented is:
+ DOS-65-00 - Change DOS-65-XX information
+ DOS-66-02 - Set active codepage
Note: The rough interface is available, but no code to actually
to change the codepage.
+ external TSR "NLSFUNC"
+ MUX-14-FF - DRDOS prepare codepage
Technical Data
DOS-C Systems Calls
The following table represents the industry standard kernel DOS calls
currently supported by DOS-C. This list is for Release 1.1, build
2003 as issued on Feb 28, 1999.
---- oops!
4b05h Set Execution State active 5.00 planned
...
5d00h Server Function Call active 3.10 supported
5d01h Commit All Files active 3.10 planned
5d02h Close File by Name active 3.10 planned
5d03h Close All Files for Computer active 3.10 planned
5d04h Close All Files for Process active 3.10 planned
5d05h Get Open File List active 3.10 planned
5d06h Get Multiple SDA active 4.00 supported
5d07h Get Redirected Printer Mode active 3.10 supported
5d08h Set Redirected Printer Mode active 4.00 supported
5d09h Flush Redirected Printer Output active 4.00 supported
5d0ah Set Extended Error active 4.00 planned
...
64h ? undocumented returns error
...
71h LONG FILENAME FUNCTIONS active 7.00 not supported
...
63h Multibyte char ops undocumented 3.20 Note 4
Note 4 - Returns error code.
All other documented DOS 5/6 int 21 functions are supported.
You can get long file name support by installing a separate
driver, which will also work for other DOS versions.
/* UNDOCUMENTED: server, share.exe and sda function */
case 0x5d:
switch (lr.AL)
...
/* Set Extended Error */
case 0x0a:
...
Looks like somebody DID implement int 21 function 5d0a in the
"unstable CVS" kernel branch :-). Note that functions 5d01-5d05
(commit all, close by name/computer/pspseg, get open file list)
are really not supported yet, as are the other "planned" item.
COUNT DosExec(COUNT mode, exec_blk FAR * ep, BYTE FAR * lp)
...
rc = DosExeLoader(lp, &TempExeBlock, mode, fd);
...
rc = DosComLoader(lp, &TempExeBlock, mode, fd);
...
COUNT DosComLoader(BYTE FAR * namep, exec_blk * exp, COUNT mode, COUNT fd)
...
supports: high bit of mode is some extra flag, mode 3 is OVERLAY,
other modes are handled by load_transfer(mem, exp, mode); ...
...
static void load_transfer(seg_t ds, exec_blk *ep, int mode)
...
supports mode 1, LOADNOGO and treats all other modes as normal LOAD and RUN.
DosExeLoader supports the same modes, as it also uses load_transfer.
We do not support the very exotic Siemens/European MS DOS 4.0 (not to be
confused with MS DOS 4.01) "load and execute in background" mode 4.
RBIL tells about mode 5, set execution state, D-214B05:
This is a DOS 5 / newer function and takes a pointer DS:DX to some
execution state structure as input. Returns AX=0 or AX=error code,
and in the latter case, sets the carry flag.
Note: used by programs which intercept AX=4B00h to prepare new programs for
execution (including setting the DOS version number). No DOS, BIOS
or other software interrupt may be called after return from this call
before commencement of the child process. If DOS is running in the
HMA, A20 is turned off on return from this call.
Format of execution state structure:
Offset Size Description (Table 01625)
00h WORD reserved (00h)
02h WORD type flags
bit 0: program is an EXE
bit 1: program is an overlay
04h DWORD pointer to ASCIZ name of program file
08h WORD PSP segment of new program
0Ah DWORD starting CS:IP of new program
0Eh DWORD program size including PSP
I believe int 21.4b05 is something like a low level interface
to call load_transfer directly. Or to be more exact, call the
MS DOS equivalent of it directly. To support this function in
FreeDOS, we need a wrapper because load_transfer will most
likely work in a different way than the MS kernel function.
Note that int 21.4b00 / 21.4b01 / 21.4b03 still work almost
exactly like the MS versions, or at least have the same result,
so compatibility is very good for those functions.
Eric
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
