mirror of
https://github.com/reactos/documentation.git
synced 2024-10-07 00:53:25 +00:00
a471449bfa
svn path=/trunk/rosdocs/; revision=4534
392 lines
15 KiB
Plaintext
392 lines
15 KiB
Plaintext
==================
|
|
= ROSDOCS PRIMER =
|
|
================== [by your beloved librarian KJK::Hyperion]
|
|
|
|
HISTORY
|
|
=======
|
|
20 Jan 2003: initial version
|
|
|
|
FOREWORD
|
|
========
|
|
This document should be written in RosDocs, to demonstrate its power. But
|
|
since RosDocs is, let's be frank, vaporware, and since I'm still looking for an
|
|
XML editor that 1) doesn't suck and 2) isn't written in Java (but this is a bit
|
|
redundant), *and* since I was supposed to finish this document some two weeks
|
|
ago, hand-formatted plaintext wins, for the moment. It should be a matter of
|
|
half a hour with lex+yacc to write a converter
|
|
|
|
Also note that "Win32" and "NT" are trademarked. In this document you'll
|
|
never find mentions of "Win32" or "NT", but "Ros32" and "Native" - and you're
|
|
encouraged to do the same, except when exclusively talking about Microsoft's
|
|
implementation (for example, to document a function's availability on various
|
|
Microsoft products). In abbreviations and identifiers, don't use "w32", "win32"
|
|
or "nt", except for Microsoft-specific code and documentation, or as an
|
|
abbreviation of the families of system calls (i.e. Nt*, NtUser* and W32k*) -
|
|
in all other cases, use "r32", "ros32" and "ntv", respectively. Avoid using
|
|
"Windows" in the same contexts as well - use "ReactOS". And remember that
|
|
Alphonse Capone wasn't jailed for extortion and mass murder, but for tax
|
|
evasion
|
|
|
|
CONCEPTS
|
|
========
|
|
RosDocs, in its current incarnation, is a fairly complex documentation
|
|
system, but that can still be managed and authored with simple and promptly
|
|
available tools, such as text editors and file managers (yet allowing for more
|
|
sophisticated tools to be developed in the future)
|
|
|
|
It's not vital to grasp all the concepts behind RosDocs to start authoring
|
|
documentation for the ReactOS project, since one of the tenets of RosDocs is the
|
|
strict separation between content, storage and presentation. Should any of the
|
|
three be found flawed, the other two wouldn't need to be throwed away as well
|
|
|
|
Let's spend a few more words about content, storage and presentation:
|
|
|
|
CONTENT
|
|
-------
|
|
There's two ways to add content to RosDocs:
|
|
|
|
- Doxygen comments. If you're going to write reference pages (think Unix man
|
|
pages), this is the format you should get accostumed to. It consists of
|
|
special comments, containing markup that a tool called Doxygen can extract
|
|
into a variety of formats. If you already know JavaDoc, or the QT comment-
|
|
based documentation system, Doxygen supports those as well
|
|
|
|
There's currently no strict guidelines, since RosDocs is still being planned,
|
|
so you have a great deal of freedom. Don't abuse it, though. Avoid any
|
|
structural markup, except paragraphs, lists, etc. And, at the moment, don't
|
|
worry about storage as discussed in another section of this document
|
|
|
|
- DocBook XML documents. Doxygen can be abused to write manuals and books, but
|
|
a better long-term solution is learning the DocBook XML DTD. You can also use
|
|
DocBook for reference pages, but Doxygen is preferred for that. Also note
|
|
that, at the moment, reference pages are more important than guides
|
|
|
|
No guidelines yet for DocBook, either. In general, don't write books yet.
|
|
Limit yourself to articles. A good starting point is writing short tutorials
|
|
for the Knowledge Base, since no earth-shaking changes are expected in that
|
|
field
|
|
|
|
STORAGE
|
|
-------
|
|
This is where things get tough. Remember, though, that this specification is
|
|
draft at best. Future directions include:
|
|
|
|
- support for DocBook books
|
|
- filling the text of hyperlinks with the title of the target topic
|
|
- SELECT queries, resolved at compile-time, to build tables of links
|
|
|
|
All things that, with the very strict decoupling of content and storage
|
|
outlined here, would be impossible, or involve run-time processing. For this
|
|
reason, limit yourself to reference pages and Knowledge Base articles. Guides,
|
|
overviews and examples can wait
|
|
|
|
That said, here are the storage concepts of RosDocs:
|
|
|
|
DOMAINS
|
|
If you are familiar with other schemes featuring domains, such as Internet
|
|
host names, or the Java third-party classes, this is nearly the same. Otherwise,
|
|
read on
|
|
|
|
Since some package names are awfully common, and since third-party
|
|
contributions are encouraged, it's necessary to compartment package names on a
|
|
vendor, product and, for complex products, feature basis. Such namespaces are
|
|
encoded as follows:
|
|
|
|
[ [ <vendor-specific subdivision>. ]<scope>. ]<vendor>
|
|
|
|
The scope can be a product or book name, as in the following examples:
|
|
|
|
- ReactOS Platform SDK: psdk.reactos
|
|
- GCC manual: gcc.fsf
|
|
- Bruce Eckel's Thinking in C++: ticpp.eckel
|
|
|
|
Further, optional subdivisions are possible:
|
|
|
|
- GCC internals manual: guts.gcc.fsf
|
|
|
|
Note, however, that, at the moment, only the following domains are accepted:
|
|
|
|
- psdk.reactos (ReactOS Platform SDK)
|
|
- ssdk.reactos (ReactOS Subsystem Development Kit)
|
|
- ddk.reactos (ReactOS Driver Development Kit)
|
|
- kb.reactos (ReactOS Knowledge Base)
|
|
|
|
PACKAGES
|
|
Packages are collections of topics and indexes. They are the base unit of
|
|
storage. A package may additionally contain one or more of the following items:
|
|
|
|
- secondary indexes
|
|
- a table of contents
|
|
- configuration metadata
|
|
|
|
Packages are an interface that exposes topics and indexes, they don't
|
|
dictate a specific implementation, neither in their "source" nor in their
|
|
"compiled" form. Possible implementations of the compiled form ("engines")
|
|
include:
|
|
|
|
- database on a remote server
|
|
- filesystem directory
|
|
- compressed archive
|
|
|
|
There's no well-defined standard for the source form yet, but it's expected
|
|
to be a derivative of DocBook XML. Third parties can obviously choose other
|
|
formats than the future standard for the source form, but official ReactOS
|
|
documentation will have to be written in the standard
|
|
|
|
For your documentation, you're free to organize your topics in as many
|
|
packages as you like. For ReactOS books and manuals, the following packages are
|
|
defined:
|
|
|
|
- psdk.reactos domain:
|
|
|
|
- ros32. The Ros32 subsystem's structure and boot sequence; the RPC APIs to
|
|
the Windows and Console servers; general considerations on the API
|
|
|
|
- err. Ros32 error codes; messages, parameters and meanings
|
|
|
|
- base. Basic Ros32 APIs. These include file, device and console I/O and
|
|
control; registry, memory, handles, thread, process and service
|
|
management; DLL loading; and basic error handling
|
|
|
|
- ui. Basic Ros32 user interface APIs. These include windows, MDI windows,
|
|
window classes, resources, hooks, DDE, keyboard and mouse input, and
|
|
standard controls
|
|
|
|
- gdi. Ros32 GDI and printer spooler APIs
|
|
|
|
- rtl. Ros32 Runtime Library support. These include string formatting,
|
|
large integer support and interlocked memory access
|
|
|
|
- ipc. Ros32 APIs to synchronization objects, shared memory, named and
|
|
anonymous pipes, and mailslots
|
|
|
|
- sec. Ros32 interfaces to access control; standard access rights for Ros32
|
|
object types; GINA API and implementation; Network Providers API and
|
|
implementation; general security considerations and guidelines
|
|
|
|
- dbg. Ros32 debugger API; Ros32 SEH support
|
|
|
|
- psapi. Process Status Helper API
|
|
|
|
- tlhlp. Tool Helper API
|
|
|
|
- commdlg. Common Dialog Box Library
|
|
|
|
- commctrl. Common Controls Library
|
|
|
|
- ssdk.reactos domain:
|
|
|
|
- ntv. ReactOS Native architecture; system structure and boot sequence; RPC
|
|
API to the Base server; the Process Environment Block; the Thread
|
|
Environment Block; the Kernel/User Shared Data
|
|
|
|
- err. NTSTATUS error codes; messages, parameters and meanings
|
|
|
|
- obj. Native objects and handles; overview of predefined object types;
|
|
Object Manager basics; the system objects namespace
|
|
|
|
- sec. The Native security model; explanation of token objects; SIDs, ACEs
|
|
and ACLs; generic access rights; standard access rights for kernel object
|
|
types
|
|
|
|
- seh. Structured Exception Handling internals
|
|
|
|
- lpc. The Local Procedure Call protocol
|
|
|
|
- dbg. Debugging interfaces, both kernel and user mode; the debugger LPC
|
|
protocol
|
|
|
|
- ntzw. System calls (Nt* and Zw*), both kernel and user mode
|
|
|
|
- rtl. Runtime library interfaces, both kernel and user mode; list of
|
|
supported C runtime interfaces, both kernel and user mode
|
|
|
|
- ldr. The PE Loader API (Ldr*), both kernel and user mode
|
|
|
|
- csr. The Client-Server Runtime API (Csr*); server modules API and
|
|
implementation
|
|
|
|
- nls. National Language Support API (Nls*), both kernel and user mode
|
|
|
|
- ntuser. Native User Interface (NtUser*) system calls, both kernel and user
|
|
mode
|
|
|
|
- w32k. Native GDI (W32k*) system calls, both kernel and user mode
|
|
|
|
- peexe. Structure and semantics of the PE executable format
|
|
|
|
- ddk.reactos domain:
|
|
|
|
- err. Bugcheck codes; messages, parameters and meanings
|
|
|
|
- ke. The Kernel; architecture and API
|
|
|
|
- hal. The Hardware Abstraction Layer; architecture and API
|
|
|
|
- cc. The Cache Manager subsystem; architecture and API
|
|
|
|
- cm. The Configuration Manager subsystem; architecture and API;
|
|
implemented object types
|
|
|
|
- ex. The Executive Support subsystem; architecture and API;
|
|
implemented object types
|
|
|
|
- io. The I/O Manager subsystem; architecture and API; implemented object
|
|
types
|
|
|
|
- kd. Kernel debugging; protocols and API
|
|
|
|
- ki. Predefined interrupt handlers
|
|
|
|
- lpc. The Local Procedure Call subsystem; architecture and API;
|
|
implemented object types
|
|
|
|
- mm. The Virtual Memory Manager subsystem; architecture and API;
|
|
implemented object types
|
|
|
|
- ob. The Object Manager subsystem; architecture and API; implemented
|
|
object types
|
|
|
|
- ps. The Process Structure Manager subsystem; architecture and API;
|
|
implemented object types
|
|
|
|
- se. The Security Reference Monitor subsystem; architecture and API;
|
|
implemented object types
|
|
|
|
TOPICS
|
|
Topics are the base unit of documentation. They contain the actual content,
|
|
and are organized in physical units of storage called packages
|
|
|
|
[placeholder]
|
|
|
|
INDEXES
|
|
Indexes are an addressing mechanism to retrieve a topic from a package.
|
|
Addresses in an index are strings, called keys, associated to each topic in
|
|
their source form. There's essentially two kinds of indexes:
|
|
|
|
- Identification indexes. They provide a many-to-one mapping between keys
|
|
and topics. That is, a topic can be pointed at by one or more keys in the
|
|
same identification index. Identification indexes are typically used for
|
|
unambiguous identification of topics
|
|
|
|
Currently, a number of predefined identification indexes are defined.
|
|
There's a strong bias towards developer's documentation at the moment, but
|
|
it will be solved by specializing generic indexes. Here are the generic
|
|
identification indexes currently defined:
|
|
|
|
- page. Self-contained documents containing detailed information about a
|
|
specific topic. Examples include Knowledge Base articles, reference
|
|
pages of user commands, library functions, etc. They usually contain
|
|
links to related references or sections
|
|
|
|
- section. Any topic with structural meaning, i.e. not self-contained.
|
|
They usually contain links to child sections or references
|
|
|
|
For developer's documentation, the following specialization of the section
|
|
index are defined:
|
|
|
|
- subsection. A subsection of strongly-related topics
|
|
|
|
- overview. Pages containing general information about a subsection
|
|
|
|
- example. Pages containing code samples about a subsection
|
|
|
|
- reference. Pages with an index of detailed information about a
|
|
subsection. The distinction between "overview", "example" and "reference"
|
|
indexes is necessary to simplify authoring, since, this way, the root
|
|
subnodes of a subsection can be given the same key, as in the following
|
|
example:
|
|
|
|
TOC | Index[key]
|
|
---------------------------+-----------------------------
|
|
User Interface | <none>
|
|
+ ReactOS User Interface | section[rosui]
|
|
+ Windowing | section[windowing]
|
|
+ Windows | subsection[windows]
|
|
+ Overview | overview[windows]
|
|
+ Examples | example[windows]
|
|
+ Reference | reference[windows]
|
|
|
|
For an analogous reason, there's a further specialization for child nodes
|
|
of reference sections to create indexes of functions, structures, macros,
|
|
etc. These specialized indexes are:
|
|
|
|
- functions. Functions other than class methods
|
|
|
|
- structures. Types declared with the C/C++ struct or union constructs,
|
|
and that have no methods
|
|
|
|
- enumerations. Types declared with the C/C++ enum construct
|
|
|
|
- types. Integral, array or pointer types with a special meaning
|
|
|
|
- constants. Groups of macros that comply with the following
|
|
requirements:
|
|
- they have no parameters
|
|
- they can be fully evaluated at compile time
|
|
- they are strongly related. For example, they are interchangeable
|
|
values for the same parameter, or flags, or both
|
|
- they are referenced from more than one reference page. If they are
|
|
referenced just once, they must be documented in the page that
|
|
references them
|
|
|
|
- errors. Specialization of the constants index. Constants used to return
|
|
status codes
|
|
|
|
- macros. Macros, or groups of macros, that comply with at least one of
|
|
the following requirements:
|
|
- they have parameters
|
|
- they are used for conditional compilation
|
|
- they are used as declaration modifiers
|
|
- they have side effects
|
|
Function aliases for type-generic string handling (_t* for the C
|
|
runtime and *W/*A for the Ros32 API) are excluded, and must be
|
|
documented as functions (in all their possible variants for the C
|
|
runtime, and in their type-generic form for the Ros32 API). Macros
|
|
returning l-values (e.g. errno) should be listed in the objects
|
|
index
|
|
|
|
- interfaces. Abstract classes
|
|
|
|
- classes. Classes with an implementation
|
|
|
|
- objects. Statically allocated memory objects. The type of such
|
|
objects should be documented separatedly
|
|
|
|
- messages. Window messages
|
|
|
|
- notifications. Window messages delivered through WM_NOTIFY
|
|
|
|
- guide. Root node of a guide/how-to/tutorial
|
|
|
|
- Search indexes. They provide a one-to-many mapping between keys and topics.
|
|
That is, a key in a search index can point to one or more topics. Search
|
|
indexes are typically used for keyword searches among many topics
|
|
|
|
[placeholder]
|
|
|
|
TOCS
|
|
[placeholder]
|
|
|
|
CATALOGS
|
|
[placeholder]
|
|
|
|
PRESENTATION
|
|
------------
|
|
|
|
AUTHORING
|
|
=========
|
|
[placeholder]
|
|
|
|
USING DOXYGEN
|
|
-------------
|
|
[placeholder]
|
|
|
|
USING DOCBOOK
|
|
-------------
|
|
[placeholder]
|
|
|
|
GUIDELINES
|
|
----------
|
|
[placeholder]
|