Hi I'm new here. I have been writting an OS for about two years off and on called instinct (formerly LeeOS). The project was suspended for a year and a half but I'm back to working on it. My site is http://www.lostcommunity.org/forum/default.asp but the OSs code has not yet been uploaded. That is a link to my discussion boards.
On the subject of kernel interfacing and calling conventions, I was wondering if anyone has tried using far CALLs to call needed APIs directly. This would be faster and would make it practical to use C calling conventions for system calls. The application would contain the FAR CALL instructions and a patch-table. The OS would need to use the patch table to modify the application's code at load-time to point to the actual function itself. The same system could be used for shared libraries in general (not just for calling OS functions).
I've started working on a file format called "Shared Library & Executable (SLEX or SLX)". I have not yet begun to impliment this file format into my OS project. Its still on the drawing board. Basically though, a small header at the beginning of the SLX file points to various tables. This header has the format:
hdrSignature dd 'slex'
hdrSLEXVersion dd 0
hdrFileSize dd ?
hdrCheckSum dd ?
hdrHeader section <0, ?>
hdrSegmentsTable section <?, ?>
hdrSegmentsPatchTable section <?, ?>
hdrExternalsTable section <?, ?>
hdrExternalsPatchTable section <?, ?>
hdrPublicProcsTable section <?, ?>
The 'section' struc has the following format:
section struc
locate dd ?
length dd ?
section ends
The 'version' header field is 0 now (pre-emplimented) but should be at least 00000001h when implimented. The filesize is in bytes and includes the entire file including the header. The checksum is a checksum of the entire file including the header (with the checksum field itself being processed as 00000000h).
The sections pointed to in the header can exist anywhere in the file with the exception of the header section which must start at offset 0h. All offsets are 32-bit integers relative from the beginning of the file.
The 'segments table' section is a table of 'segment' elements describing each segment in the file. The last element in this table should consist of all NULLs. For example:
segment <0h, offset codeSegment1, sizeof codeSegment1, 3h>
segment <1h, offset codeSegment2, sizeof codeSegment2, 1h>
segment <0h, 00000000h, 00000000h, 0h, 0h>
the 'segment' struc has the following format:
segment struc
id dw ?
locate dd ?
length dd ?
flags dd ?
segment ends
The ID field is unique for each segment. 0h is reserved for the NULL terminating descriptor. The locate and length fields specify the position and size of the segment within the file and follow the same rules as they do in the 'section' struc. The flags field specifies the type of segment and how the segment should be loaded and used.
The 'segments patch table' is a table containing 32-bit elements and terminated with a NULL element. Each element points to a WORD in the file by its offset within the file itself. The word it points to is a reference to a segment. This reference needs to be modified to point to the actual location in memory that the segment was loaded to. The WORDs initial value will be the ID of a segment in the segments table.
The 'externals' table is a stream of library/procedure pairs. For example:
db 'kernel.slx',0
db 'quit',0
This table holds a list of external dependancies that the file requires. The above entry specifies a dependancy on the file 'kernel.slx' and the procedure 'quit' specifically.
The 'externals patch' table formatted exactly like the 'segments patch table'. It contains 32-bit elements which point to DWORDs within the file. These DWORDs which are being pointed to are also pointers which point to a position within the 'externals table'. Lost yet? The 'externals' table points to CALL instructions inside the code segments. These CALL instructions contain a FAR PTR to a descripter within the 'externals' table. The OS needs to first load the external dependacy, then modify the DWORD within the code segment to point to the appropriate function within that dependacy.
The 'public procs' table is the opposite of the 'externals' table. It points to and describes procedures that it contains and is willing to share with other resident SLX files. This table is an array of 'publics' strucs. The last element in this table should be NULLed. The format of the publics struc follows:
segment struc
id db 32 DUP(?)
locate dd ?
length dd ?
flags dd ?
segment ends
The id field is the name of the procedure (ascii). The locate and length fields point to the procedure the same way the section struc points to sections. It is up to the OS to determine which segment contains the shared procedure based on its position within the file. The flags field describes the type of procedure and how it can be accessed.
That's about the whole format right now. I'm sure it will change be the time I get around to implimenting it though. Take it or leave it I guess.
-Robert