| SCRIPT: I use this to describe code which behaves like batch files, though, in LoseThos, there is no difference between an application, a system tool, or something you create to automate backups. All are written in C+ and all are compiled, not interpreted. C+: The programming language of LoseThos. It's more than standard C and less then C++. DYNAMIC COMPILATION: When you #include a program at the command line, it gets compiled and placed in the task's heap memory. Each function is compiled separately and they result in discontinuous locations depending on what memory MAlloc() provides to the compiler to store the code. There is no need to include header files for the operating system routines because they are compiled at boot and all info about code and classes stays around. There is debug info, also, and don't give me crap for wasting memory. You have a lot of nerve if you compare LoseThos to Windows or Linux. These days, you must work hard to run-out of memory when you're not using multimedia files. LoseThos is for programmers and debug info is handy. Line numbers for source code are stored and will appear when you disassemble with Dasm() or profile with Prof(). STATIC COMPILATION: LoseThos can generate compiled binary executable files, but this is not the preferred approach. I had no choice when making the Kernel and Compiler, obviously. Assembly language programming is only available with static mode, so I did some time-critical graphics routines in static mode, too. Boot sectors code, too, must be "static". You can load debug info from map files created for static modules with LoadMapFile(). In the map files are stored binary data beyond the end of the text. With static mode, you must include headers. This is just like conventional compilers, except it skips object files and linking and makes binary executables directly. Binaries are less compatible with future upgrades to the operating system then source code which gets dynamically compiled. Static modules store code continuously and are loaded with Load(). ADAM TASK: Each task has a symbol table which stores names of functions and variables #included by that task. A task is chained to it's parent and inherits the symbols of it's parent. This provides name space scoping. The parent of all tasks is called ADAM and it's symbols are available to all tasks. FS: In LoseThos, this is a special pointer-type thingy which points to the current task's state record. It is named Fs because the CPU segment register known as FS is maintained pointing to this structure. I want people to understand the inner-workings and feel comfortable with them. As you are debugging, you might want to display registers of tasks. Many variables in this structure are intended to be modified by applications. I don't like the hassle of the C++ concept of wrapping objects, providing routines just to access variables or change them. Obviously it's more risky. |
|