mirror of
https://github.com/Zeal-Operating-System/ZealOS.git
synced 2025-01-13 16:16:31 +00:00
271 lines
14 KiB
Text
Executable file
271 lines
14 KiB
Text
Executable file
$WW,1$$FG,5$$TX+CX,"Glossary"$$FG$
|
|
|
|
$TR,"Abbreviations"$
|
|
$ID,2$$FG,2$Abs$FG$ Absolute
|
|
$FG,2$AC$FG$ AutoComplete
|
|
$FG,2$Acct$FG$ Account
|
|
$FG,2$ACD$FG$ AutoComplete Dictionary
|
|
$FG,2$Addr$FG$ Address
|
|
$FG,2$Alloc$FG$ Allocate
|
|
$FG,2$Alt$FG$ Alternate
|
|
$FG,2$AOT$FG$ Ahead-of-Time
|
|
$FG,2$AP$FG$ ApplicationProcessor (Core1 - Core7)
|
|
$FG,2$Arg$FG$ Argument
|
|
$FG,2$Asm$FG$ Assemble, Assembler or Assembly
|
|
$FG,2$Attr$FG$ Attribute
|
|
$FG,2$Aux$FG$ Auxilliary
|
|
$FG,2$BG$FG$ Backround
|
|
$FG,2$Bin$FG$ Binary
|
|
$FG,2$Blk$FG$ Block
|
|
$FG,2$Bmp$FG$ BitMap
|
|
$FG,2$Bttn$FG$ Button
|
|
$FG,2$Buf$FG$ Buffer
|
|
$FG,2$CB$FG$ Call-Back, Code Block
|
|
$FG,2$Clip$FG$ Clipboard
|
|
$FG,2$Clus$FG$ Cluster
|
|
$FG,2$Cmd$FG$ Command
|
|
$FG,2$Comp$FG$ Compiler
|
|
$FG,2$Count$FG$ Count
|
|
$FG,2$Const$FG$ Consant
|
|
$FG,2$Cont$FG$ Continue
|
|
$FG,2$Ctrl$FG$ Control. The ctrl key is indicated with "$FG,2$^$FG$" in documentation.
|
|
$FG,2$Cur$FG$ Current
|
|
$FG,2$Dbl$FG$ Double
|
|
$FG,2$DC$FG$ Device Context
|
|
$FG,2$Del$FG$ Delete
|
|
$FG,2$Desc$FG$ Descriptor, Description
|
|
$FG,2$Dev$FG$ Device
|
|
$FG,2$Dir$FG$ Directory, Direction
|
|
$FG,2$Div$FG$ Divide
|
|
$FG,2$Doc$FG$ Document
|
|
$FG,2$Drive$FG$ Drive
|
|
$FG,2$Disk$FG$ Disk
|
|
$FG,2$Dst$FG$ Destination
|
|
$FG,2$Ed$FG$ Edit, Editor
|
|
$FG,2$Elem$FG$ Element
|
|
$FG,2$Equ$FG$ Equal
|
|
$FG,2$Evt$FG$ Event
|
|
$FG,2$Exe$FG$ Execute
|
|
$FG,2$Ext$FG$ Extern, Extended, Extract
|
|
$FG,2$Feat$FG$ Feature
|
|
$FG,2$FG$FG$ Foreground
|
|
$FG,2$Fwd$FG$ Forward
|
|
$FG,2$FPS$FG$ Frames per Second, First Person Shooter
|
|
$FG,2$fp_$FG$ Function ptr
|
|
$FG,2$Fun$FG$ Function
|
|
$FG,2$Gen$FG$ Generate
|
|
$FG,2$Gr$FG$ Graphic
|
|
$FG,2$Hndlr$FG$ Handler
|
|
$FG,2$IDE$FG$ Integrated Drive Electronics, Integrated Development Environment
|
|
$FG,2$Id$FG$ Identification
|
|
$FG,2$Ident$FG$ Identifier, Identity, Identical
|
|
$FG,2$IDT$FG$ Interrupt Descriptor Table
|
|
$FG,2$Idx$FG$ Index
|
|
$FG,2$Init$FG$ Initialize
|
|
$FG,2$Ins$FG$ Insert, Install
|
|
$FG,2$Inst$FG$ Instruction
|
|
$FG,2$Int$FG$ Interrupt, Integer
|
|
$FG,2$Irq$FG$ Interrupt (Request)
|
|
$FG,2$JIT$FG$ Just-in-Time
|
|
$FG,2$Kbd$FG$ Keyboard
|
|
$FG,2$KD$FG$ Keyboard Device
|
|
$FG,2$Len$FG$ Length
|
|
$FG,2$Let$FG$ Letter
|
|
$FG,2$Lex$FG$ Lexical Analyser
|
|
$FG,2$Loc$FG$ Location, Lines of Code
|
|
$FG,2$Log$FG$ Logarithm, Logical
|
|
$FG,2$List$FG$ List
|
|
$FG,2$Man$FG$ Manual
|
|
$FG,2$Mem$FG$ Memory
|
|
$FG,2$Mgd$FG$ Managed
|
|
$FG,2$Mgr$FG$ Manager
|
|
$FG,2$Mid$FG$ Middle
|
|
$FG,2$Mon$FG$ Month
|
|
$FG,2$MP$FG$ MultiProcessor
|
|
$FG,2$Num$FG$ Number
|
|
$FG,2$Obj$FG$ Object
|
|
$FG,2$Occ$FG$ Occurrence
|
|
$FG,2$ODE$FG$ Ordinary Differential Equation
|
|
$FG,2$Opt$FG$ Option, Optimize
|
|
$FG,2$Paren$FG$ Parenthesis
|
|
$FG,2$Pix$FG$ Pixel
|
|
$FG,2$Pkg$FG$ Package
|
|
$FG,2$Poly$FG$ Polygon
|
|
$FG,2$Pos$FG$ Position
|
|
$FG,2$Pow$FG$ Power
|
|
$FG,2$Prec$FG$ Precedence
|
|
$FG,2$Prev$FG$ Previous
|
|
$FG,2$Pri$FG$ Primary
|
|
$FG,2$Prod$FG$ Product, Production
|
|
$FG,2$Prof$FG$ Profile, Profiler
|
|
$FG,2$Parse$FG$ Parse, Parser
|
|
$FG,2$Part$FG$ Partition
|
|
$FG,2$FunSeg$FG$ Program Section
|
|
$FG,2$Pt$FG$ Point
|
|
$FG,2$Ptr$FG$ Pointer
|
|
$FG,2$Queue$FG$ Queue
|
|
$FG,2$Rand$FG$ Random
|
|
$FG,2$Ref$FG$ Reference
|
|
$FG,2$Reg$FG$ Register, Registry, Regular
|
|
$FG,2$Rep$FG$ Report, Repeat
|
|
$FG,2$Res$FG$ Result
|
|
$FG,2$Rev$FG$ Reverse, Reversed
|
|
$FG,2$Rqst$FG$ Request
|
|
$FG,2$Reset$FG$ Reset
|
|
$FG,2$Rot$FG$ Rotation
|
|
$FG,2$Rx$FG$ Receive
|
|
$FG,2$Sched$FG$ Sceduler
|
|
$FG,2$Sec$FG$ Second, Secondary
|
|
$FG,2$Sect$FG$ Sector
|
|
$FG,2$Sel$FG$ Select, Selected
|
|
$FG,2$Seq$FG$ Sequence
|
|
$FG,2$Sound$FG$ Sound
|
|
$FG,2$SP$FG$ SingleProcessor
|
|
$FG,2$Src$FG$ Source
|
|
$FG,2$Stat$FG$ Status, Statistic
|
|
$FG,2$Std$FG$ Standard
|
|
$FG,2$Stack$FG$ Stack
|
|
$FG,2$Str$FG$ String
|
|
$FG,2$Sym$FG$ Symbol
|
|
$FG,2$Sync$FG$ Synchronization
|
|
$FG,2$Sys$FG$ System
|
|
$FG,2$Tbl$FG$ Table
|
|
$FG,2$Term$FG$ Terminal
|
|
$FG,2$Tmp$FG$ Temporary
|
|
$FG,2$Tri$FG$ Triangle
|
|
$FG,2$Tx$FG$ Transmit
|
|
$FG,2$UAsm$FG$ Unassemble
|
|
$FG,2$Val$FG$ Value
|
|
$FG,2$Var$FG$ Variable
|
|
$FG,2$Vect$FG$ Vector
|
|
$FG,2$Vis$FG$ Visible
|
|
$FG,2$Vol$FG$ Volume
|
|
$FG,2$Win$FG$ Window
|
|
$FG,2$Wiz$FG$ Wizard
|
|
$ID,-2$$TR,"Task/Process/Thread"$
|
|
$ID,2$There is no distinction between $FG,2$task$FG$, $FG,2$process$FG$ or $FG,2$thread$FG$. The $FG,2$Fs$FG$ segment register is kept pointing to the current task's $LK,"CTask",A="MN:CTask"$. There is only one window per task, and only $FG,2$Core0$FG$ tasks can have windows. Each task has a code and data heap so memory is returned when it dies. Each task has a $LK,"hash",A="HI:Hash"$ symbol table.
|
|
|
|
Since there is not friendly disk sharing and all tasks have the same address map, it might be accurate to call ZealOS, "multi-thread/single-process". You run a single application process on $FG,2$Core0$FG$ and it can create threads on the same core or others. If you run multiple processes, it should be safe, but one process will wait until another completely finishes a long disk access.
|
|
$ID,-2$$TR,"System Task"$
|
|
$ID,2$The System task is immortal. The system task is created at start-up and appears in the small window at the top beneath the user terminal windows. Since the System task is immortal, on its heap go all memory objects which you don't want destroyed by any single task's death. When created, the System task runs the file $LK,"::/StartOS.ZC"$. When start-up is finished, the system task enters a server mode where it accepts requests from other tasks. The $LK,"Sys",A="MN:Sys"$("") routine will make the System task compile and run text src code. $FG,2$#include$FG$ statements can be sent to $LK,"Sys",A="MN:Sys"$(""), creating system-wide code and data which are immortal.
|
|
$ID,-2$$TR,"Executive Tasks"$
|
|
$ID,2$Each CPU core has an $FG,2$Executive$FG$ task that is immortal. The System task on $FG,2$Core0$FG$ is also its $FG,2$Executive$FG$ task.
|
|
$ID,-2$$TR,"Code and Data Heaps"$
|
|
$ID,2$ZealOS uses the asm $FG,2$CALL$FG$ instruction, exclusively, and that instruction is limited to calling routines $FG,2$+/-2Gig$FG$ from the current code location. To prevent out-of-range issues, code and data are separated, placing all code within the lowest $FG,2$2Gig$FG$ of memory, addresses $FG,2$00000000$FG$-$FG,2$7FFFFFFF$FG$. The compiler and $LK,"Load",A="MN:Load"$()er alloc memory from the code heap to store code and global variables, unless the compiler option $LK,"OPTf_GLOBALS_ON_DATA_HEAP",A="MN:OPTf_GLOBALS_ON_DATA_HEAP"$ is used. When programs call $LK,"MAlloc",A="MN:MAlloc"$() is from the data heap, which in not limited in size, except by physical RAM memory. You can alloc from any heap in any task at any time on any core, even making $LK,"independent",A="MN:MemPagAlloc"$ heaps.
|
|
$ID,-2$$TR,"Parent, Child and PopUp Tasks"$
|
|
$ID,2$Often a task will $LK,"Spawn",A="MN:Spawn"$() or $LK,"PopUp",A="MN:PopUp"$() a task as a helper. The helper is known as a child Task, though you can $LK,"Spawn",A="MN:Spawn"$ a task and assign it a different parent... like $FG,2$System$FG$. Links are kept as to who's whose child, so when one task is $LK,"Kill",A="MN:Kill"$()ed the child helper tasks die, too. You can get a report of current system tasks with $LK,"TaskRep",A="MN:TaskRep"$(). There is just one window per task, so child tasks are needed for pop-ups.
|
|
$ID,-2$$TR,"ZealC"$
|
|
$ID,2$$LK,"ZealC",A="FI:::/Doc/ZealC.DD"$ is more than $FG,2$C$FG$ and less than $FG,2$C++$FG$. It has the default args of $FG,2$C++$FG$ and uses $FG,2$class$FG$ in place of $FG,2$struct$FG$. It uses $FG,2$U0,U8,U16,U32,I64$FG$ and $FG,2$I0,I8,I16,I32,I64$FG$ for signed and unsigned ints. It has different $LK,"operator precedence",A="FF:::/Doc/ZealC.DD,operator precedence"$. It has $FG,2$PASCAL$FG$-like function calls with no parens, but requires an $FG,2$&$FG,2$$FG$ when referring to function addresses.
|
|
$ID,-2$$TR,"AOT Compile Mode"$
|
|
$ID,2$$FG,2$Ahead-of-Time$FG$ compiling is conventional compilation mode. Do not use $FG,2$AOT$FG$, use $FG,2$JIT$FG$ compiling.
|
|
|
|
In $FG,2$AOT$FG$ mode, $FG,2$.PRJ$FG$ files are compiled to $FG,2$.ZXE$FG$ files, skipping $FG,2$.OBJ$FG$ files. After compiling, $FG,2$.ZXE$FG$ files are $LK,"Load",A="MN:Load"$()ed.
|
|
|
|
There is no $FG,2$main()$FG$ routine. Instead, statements outside functions are automatically executed upon loading. There is no way to unload except by killing the task. To invoke $FG,2$AOT Compiled Mode$FG$, $LK,"Comp",A="MN:Comp"$() is used. The $FG,2$Kernel$FG$ module and compiler are made in $FG,2$AOT$FG$ compiled mode. See $LK,"BootHDIns",A="MN:BootHDIns"$() which calls $LK,"MakeAll",A="MN:MakeAll"$() where $LK,"::/Boot/Kernel.ZXE",A="FI:::/Kernel/Kernel.PRJ"$ and $LK,"::/Compiler/Compiler.ZXE",A="FI:::/Compiler/Compiler.PRJ"$ are created.
|
|
$ID,-2$$TR,"JIT Compile Mode"$
|
|
$ID,2$In $FG,2$just-in-time$FG$ mode, the compiler places code and data in memory alloced from the heap, incrementally, making them immediately ready for in-place execution. This mode is used during cmd line operations. When you $FG,2$#include$FG$ a file, it is compiled function by function and code ends-up all over in the memory, at least in the first 2Gig of memory. The $LK,"ExeFile",A="MN:ExeFile"$() routine is the same as $FG,2$#include$FG$ but can be used in programs. $LK,"ExePrint",A="MN:ExePrint"$() routine will compile and run a string.
|
|
$ID,-2$$TR,"Compiler Intermediate Code"$
|
|
$ID,2$The compiler generates insts one step before making actual assembly (machine) language insts. This code is rev polish stack machine in nature and can be viewed with $LK,"PassTrace",A="MN:PassTrace"$(). The compiler does not $FG,2$interpret$FG$ code, except in the process of optimization to make the final machine code. Assembly language output can be viewed when code is compiled with the $LK,"Trace",A="MN:Trace"$(), or, afterward, with $LK,"U",A="MN:U"$() or $LK,"Uf",A="MN:Uf"$("").
|
|
$ID,-2$$TR,"Drive/Partition"$
|
|
|
|
$ID,2$There is no distinction between $FG,2$drive$FG$ or $FG,2$partition$FG$. They are specified with a single letter from $FG,2$A$FG$-$FG,2$Z$FG$.
|
|
|
|
'$FG,2$:$FG$' is the boot drive.
|
|
'$FG,2$~$FG$' is the home drive.
|
|
|
|
The letters are reserved for different uses.
|
|
|
|
$FG,2$A$FG$-$FG,2$B$FG$ are RAM drives.
|
|
$FG,2$C$FG$-$FG,2$L$FG$ are ATA hard drives.
|
|
$FG,2$M$FG$-$FG,2$P$FG$ are ISO file read drives.
|
|
$FG,2$Q$FG$-$FG,2$S$FG$ are ISO file write drives.
|
|
$FG,2$T$FG$-$FG,2$Z$FG$ are ATAPI CD/DVD drives.
|
|
|
|
For commands taking a drive letter as an argument, char $FG,2$0$FG$ is the current drive.
|
|
$ID,-2$$LK,"Bt, Bts, Btr, Btc, BEqual",A="HI:Bit"$
|
|
$LK,"Define",A="HI:Define"$
|
|
$LK,"DolDoc",A="FI:::/Doc/DolDocOverview.DD"$
|
|
$LK,"Editor Link Types",A="MN:LK_FILE"$
|
|
$LK,"files_find_mask",A="FI:::/Doc/FileUtils.DD"$
|
|
$LK,"Hash Table",A="HI:Hash"$
|
|
$LK,"InFile",A="HI:InFile"$
|
|
$LK,"Ona",A="HI:Sound"$
|
|
$LK,"Pag",A="HI:Memory/BlkPool"$
|
|
$LK,"RedSea File System",A="FI:::/Doc/RedSea.DD"$
|
|
$LK,"Sprite",A="HI:Graphics/Sprite"$
|
|
|
|
$TR,"CLI, STI, PUSHFD, POPFD"$
|
|
$ID,2$These are x86 assembly insts.
|
|
$FG,2$CLI$FG$ disable interrupts.
|
|
$FG,2$STI$FG$ enable interrupts.
|
|
$FG,2$PUSHFD$FG$ pushes the CPU flags.
|
|
$FG,2$POPFD$FG$ pops the CPU flags.
|
|
$ID,-2$$TR,"Filename Extention Types"$
|
|
$ID,2$$FG,5$$FG,5$*.???.C$FG$
|
|
Contiguous files - not fragmented on disk.
|
|
$FG,5$*.DD$FG$
|
|
Text Files
|
|
$FG,5$*.ZC$FG$
|
|
ZealC src files. The default ZealC compiler type is $FG,2$.ZC$FG$.
|
|
$FG,5$*.PRJ$FG$
|
|
ZealC src files to be compiled $FG,2$AOT$FG$.
|
|
$FG,5$*.HH$FG$
|
|
ZealC src header files.
|
|
$FG,5$*.MAP$FG$
|
|
Compiler "map" files
|
|
$FG,5$*.ZXE;*.ZXE$FG$
|
|
Binary executable files, created by $LK,"Comp",A="MN:Comp"$() and read by $LK,"Load",A="MN:Load"$().
|
|
$FG,5$*.DATA$FG$
|
|
Data files
|
|
$FG,5$*.ISO;*.ISO.C$FG$
|
|
CD/DVD image file. $LK,"RedSea",A="FI:::/Doc/RedSea.DD"$ or ISO9660.
|
|
$FG,5$*.IN$FG$
|
|
$FG,2$InFile$FG$ Basically a ZealC program whose stdout goes to the input of a task when $LK,"InFile",A="MN:InFile"$() is called.
|
|
$FG,5$*.GR$FG$
|
|
Graphics file
|
|
|
|
$LK,"FILEMASK_TXT",A="MN:FILEMASK_TXT"$
|
|
$LK,"FILEMASK_SRC",A="MN:FILEMASK_SRC"$
|
|
$LK,"FILEMASK_AOT",A="MN:FILEMASK_AOT"$
|
|
$LK,"FILEMASK_JIT",A="MN:FILEMASK_JIT"$
|
|
$LK,"FILEMASK_GR",A="MN:FILEMASK_GR"$
|
|
$ID,-2$$TR,"Naming Convention"$
|
|
$ID,2$Since there are no $FG,2$namespaces$FG$, it is highly recommended to put a 2-3 character module code prefix on symbols. e.g. $FG,2$WS$FG$, $FG,2$Doc$FG$, $FG,2$Lex$FG$
|
|
|
|
$FG,5$ALL_CAPS$FG$
|
|
Assembly Language labels are capitalized with underscores between words. So are $FG,2$#define$FG$'s.
|
|
|
|
$FG,5$_ALL_CAPS$FG$
|
|
Asm routines which are $LK,"ZealC",A="FI:::/Doc/ZealC.DD"$ callable must have a leading underscore.
|
|
|
|
$FG,5$MixedCaps$FG$
|
|
$LK,"ZealC",A="FI:::/Doc/ZealC.DD"$ Functions and class names are MixedCaps.
|
|
|
|
$FG,5$lower_case$FG$
|
|
Local function variables and global variables are lower case. Class member names are also lower_case.
|
|
|
|
$FG,5$_lower_case$FG$
|
|
Function args which are outputs (passed as pointers) have leading underscores. Also, args which have idently named local variable counterparts have leading underscores.
|
|
|
|
$FG,5$DOCf_????$FG$
|
|
Flags bit nums instead of bit values are designated with a lower case $FG,2$f$FG$.
|
|
|
|
$FG,5$DOCG_????$FG$
|
|
Flag groups are designated with "$FG,2$G$FG$".
|
|
|
|
$FG,5$res$FG$ is reserved for local variables that hold the function return value.
|
|
|
|
$FG,5$*$FG$ C++ like naming is used. $FG,2$New$FG$, $FG,2$Del$FG$, $FG,2$Init$FG$, $FG,2$Reset$FG$, ect. are placed on the end of a function name instead of at the beginning. $FG,2$ResetMusicSettings$FG$ should be $FG,2$MusicSettingsReset$FG$.
|
|
$ID,-2$$TR,"Fs"$
|
|
$ID,2$The CPU FS segment register. This register points to the current task's $LK,"CTask",A="MN:CTask"$.
|
|
$ID,-2$$TR,"Gs"$
|
|
$ID,2$The CPU GS segment register. This register points to the current core's $LK,"CCPU",A="MN:CCPU"$.
|
|
$ID,-2$$TR,"Heap"$
|
|
$ID,2$Programs can dynamically request chunks of memory alloced from a $FG,2$heap$FG$ using $LK,"MAlloc",A="MN:MAlloc"$(). They must $LK,"Free",A="MN:Free"$() it when finished. Pointers are used to refer to the chunk. The $FG,2$heap$FG$ is dynamically alloced mem.
|
|
$ID,-2$$TR,"Join"$
|
|
$ID,2$When two parts of a program have a common low-level routine, that routine is often labeled SomethingJoin.
|
|
$ID,-2$$TR,"user_data"$
|
|
$ID,2$Many operating system structures have space set aside for you to store values. You are on your own managing these with multiple applications and libraries.
|
|
$ID,-2$$TR,"Multicore Core0/CoreAP"$
|
|
$ID,2$Core0, has the $LK,"System Task",A="FF:::/Doc/Glossary.DD,System Task"$$FG$, and it is the master. The $FG,2$application processors$FG$ have an $LK,"Executive Task",A="FF:::/Doc/Glossary.DD,Executive Tasks"$ and are the slave processors. Only $FG,2$Core0$FG$ tasks can have windows and can launch applications. Slave cores are used if the application explicitly $LK,"Spawn",A="MN:Spawn"$s() a task or $LK,"JobQueue",A="MN:JobQueue"$() a job on them.
|
|
$ID,-2$
|