The filesystem is highly inspired from the UNIX one, but taking in consideration the user only needs to access his files, applications, volumes or shared files most of the time. Consequently, the following directories are available at top level: "Apps", "Data", "System" and "Volumes". The "System" directory could even have been called ".System" to only let the advanced users access it via the common interfaces. It could even be considered that the place of an executable in the filesystem hierarchy could determine its privileges; this can't be a security risk, since when one gains access to the filesystem, then he has already access to the full system. It contains a sub-directory per applications group. In this sub-directory one man find the following directories: Binaries: the applications binaries Engines: the applications' engines binaries Libraries: the shared libraries System: the applications administration binaries Sources: the applications source code (a sub-directory per package) Shared data: documentation, hosted files, ... System hierarchy. Contains the following sub-directories: Apps: system essential applications and libraries, containing a Apps/subdirectory like hierarchy. Devices: equivalent to the /dev Kernel: equivalent to the /proc on Linux Sources: the associated source code (a sub-directory per entity) Hard disks, CD-ROM and DVD-ROM drives, USB keys, etc, that get automatically mounted. To gain read and write access on them, one should have the necessary privileges though. FIXME: think about a DTD for configuration files, with maybe a type enforcement (boolean, integer, enum, string), a way to specify multiple lines in strings, and a way to handle lists of values. Configuration files contain variable names along with their values, nested inside sections. Default variables and values can be set in the global section, which name is "" (empty string). The global section is the default one. Comments are allowed on their own lines. #this is a comment #default section is global variable=value [section] variable=value [another section] #another comment variable=value another variable=value [] #this is global section again variable=value Prefix is "Buffer". new(): Buffer new(Size size): Buffer delete() get_size(): Size set_size(Size size): Bool Prefix is "Config". new(): Config delete() load(File file): Bool save(File file): Bool get(String section, String name): String set(String section, String name, Variable variable): Bool Prefix is "File". new(): File delete() open(String filename, FileOpenMode mode): Bool close() is_end(): Bool read(Buffer buffer): Size write(Buffer buffer): Size flush() set_position(Offset offset) set_position(Offset offset, FilePositionFrom) Prefix is "List". new(): List new(ListType type): List delete() get_type(): ListType set_type(ListType type) Prefix is "String". A string can be stored in different encodings, possibly longer than the 7-bit ascii, or 8-bit ascii extensions ones (eg UTF-8). Strings are always properly terminated when manipulated using this interface. new(): String //creates an empty string new(Buffer buffer): String //creates a string from `buffer` using //the default encoding new(Buffer buffer, StringEncoding encoding): String //creates a string from `buffer` encoded //as `encoding` delete() get_size(): Size //get string buffer size set_size(Size size) //set string buffer size to `size` get_length(): Size //get string length set_length(Size size) //set string length to `size` Prefix is "Variable". This type is used for data conversions. new(VariableType type, Buffer data): Variable //creates a `type` variable from `data` delete() get(VariableType type): //get variable as `type` set(VariableType type) //set default type to `type` set(VariableType type, Buffer data) //set variable as `type` from `data` Prefix is "AppEngine". new(): AppEngine delete() Prefix is "AppIface". new(): AppIface delete() Prefix is "G". A list of a possible implementation guidelines follows. a GCanvas is a surface, containing GCanvasItems a GCanvasItem is a graphical primitive GCanvasItems can be grouped inside GCanvasGroups a GWindow contains a GCanvas a GCanvas is a GWidget every GWidget is a GCanvas Consequently, every graphical item on screen is a GCanvasItem, GWidgets are groups of GCanvasItems, and can contain other GWidgets, possibly being GCanvases. This is a big advantage for code reuse. A problem is, it doesn't handle resizing properly as is. Prefix is "Canvas". //FIXME functions applying to GCanvases, but not to GWidgets Prefix is "CanvasItem". delete() //deletes properly, whichever the type show() //shows item hide() //hides item Prefix is "Label". new(): GLabel new(String string): GLabel delete() get_text(): String set_text(String string) Prefix is "Window". new(): GWindow new(String title): GWindow new(GWindowType type): GWindow new(GWindowType type, String title): GWindow delete() get_type(): GWindowType set_type(GWindowType type) get_size(): Size set_size(Size x, Size y) Bootable file containing: memory management code; process handling code; the plugin for the / filesystem; it then reads and launches the following AppServers off /System in sequence, waiting until they each have their system call interface ready: VFS; Init. Maintains the system's session, just like users' session do. Shares the necessary system and subsystems states with authorized users. Has plugins for the different necessary filesystems. Maps volumes to the filesystem hierarchy if necessary. Connects to other VFS AppServers if necessary. May run as multiple instances on a system, with different priviledges ("chroot" equivalent). Has the list of mappings between hardware identifiers and drivers. Watches after the various hardware buses and loads/unloads the drivers consequently. The assembly utility, "as", and the disassembly one "disas", are to be based on a library, "libas". It should provide the following distinct facilities: parsing, if possible on top of the parsing library; file output, using a dynamic plug-in system for architecture and file format; disassembly, if it actually requires any significant additional code at all. The C compiler, "cc", is to be based on top of a library, "libcc". It should parse C code on top of the parsing library if possible, and provide this functionality to other programs. A C interpreter, and other development assisting tools would also be desired on top of this library. The server is to use a common API for hardware access, implementing directly the necessary OpenGL layer calls. It serves the OpenGL interface as an AppServer, plus functions to handle user interaction and whatnot. Each window has its own OpenGL context, and is actually drawing into a texture and not directly on the screen, except while running fullscreen. The window manager is an optional plug-in, which would benefit from a common library ("libGWM"), and hook some or all of the window handling functions. It should provide syntax highlighting, through dynamic plugins, built on top of the existing parsing libraries. Built on top of a series of plugins to connect to the different existing networks protocols. It focuses on multipart conversations (private ones being just 2 parties conversations), with audio/video support. It could interact with the users' session managers to update lists of allowed clients to shared applications (drawing program for whiteboard, etc). Built on top of the XML parsing library, using strict mode for XHTML if possible, else tolerant mode to also parse HTML code to valid XHTML.