Acorn officially halted work in all areas except set-top boxes in late 1998 and the company was renamed Element 14 (the 14th element of the periodic table being silicon) with a new goal to become purely a Silicon design business (like the previous very successful spin off of ARM from Acorn in 1990). RISC OS development was halted during the development of OS 4.0 for the RiscPC 2 (“Phoebe 2100″), whose completion was also cancelled. A beta version, OS 3.8 (“Ursula”) for the original RiscPC, had previously been released to developers. The project code names of Phoebe (for the hardware), Ursula (for the software) and Chandler (for the graphics processor chip) were taken from the names of characters in the TV series ”Friends” (Phoebe and Ursula were twin sisters in the series).

This led to a number of rescue efforts to try and keep the Acorn desktop computer business alive. Acorn held discussions with many interested parties, and eventually agreed to exclusively licence RISC OS to RISCOS Ltd, which was formed from a consortium of dealers, developers and end-users.

There were also a number of projects to bring the advantages of the RISC Operating System to other platforms by the creation of the ROX Desktop to provide a RISC OS-like interface on Unix and Linux systems.

Two similar projects, Impulse and Eidos’s Phoenix, have both stalled.

Adapted from the Wikipedia article RISC OS, under the G. N. U. Free Documentation License. Please also see http://en.wikipedia.org/wiki

No related posts.

The game is programmed in C++. It is cross-platform, and runs on AmigaOS 4, BeOS, FreeBSD, Linux (including OS flavors running on GP2X and Nokia n800, n810, and n900 handheld devices), Mac OS X, Microsoft Windows, MorphOS, NetBSD, OpenBSD, RISC OS, iPhone OS, and Solaris.

Wesnoth development is decentralized due to its free and open-source nature. The officially-blessed campaigns and units bundled with the game download are often derived from content created by the community, somewhat differently from the user-generated content in proprietary games where such content, while available, is usually not incorporated into official builds of the game. The Wesnoth forums and wiki are used to develop new campaigns, including new unit types and story artwork. The game is able to download new campaigns from a central add-on server. Content featured on the official campaign server must be licensed under the GNU GPL, like the game itself.

Even when not counting this community content, the list of contributors to the official version of the game as displayed in-game contains over 550 unique entries (May 2010). Developers of the game also include well known authors from the free software and open source scene, like the co-founder of the Open Source Initiative Eric S. Raymond, or Linux kernel programmer Rusty Russell.

Releases

First development release of Wesnoth 0.1 happened on June 18, 2003. In October 2005, the game reached its 1.0 milestone release. On April 1, 2010, version 1.8 was released. Various versions of Wesnoth have been downloaded from the central site over four million times. As of April 2010 the game is available in about 50 languages, 9 of which have more than 95% of messages translated.

Adapted from the Wikipedia article The Battle for Wesnoth, under the G. N. U. Free Documentation License. Please also see http://en.wikipedia.org/wiki

No related posts.

In computing, at least internally, metric time gained widespread use for ease of computation. Unix time gives date and time as the number of seconds since January 1, 1970, and Microsoft’s FILETIME as multiples of 100ns since January 1, 1601 . VAX/VMS uses the number of 100ns since November 17, 1858 and RISC OS the number of centiseconds since January 1, 1900. (Each of these is not strictly linear, as they have discontinuities at leap seconds.)

Adapted from the Wikipedia article Metric time, under the G. N. U. Free Documentation License. Please also see http://en.wikipedia.org/wiki

No related posts.

RISC OS is a computer operating system which was originally developed by Acorn Computers Ltd in Cambridge, England for their range of desktop computers, based on the ARM chipset. It was first released in 1988 as RISC OS 2.00, having been derived from Acorn’s Arthur operating system, with the addition of cooperative multitasking. The operating system takes its name from the RISC (”Reduced Instruction Set Computing”) architecture used on supported systems.

Since 1988, RISC OS has been bundled with nearly every Acorn computer model, including the Archimedes range of computers, and RiscPC and A7000 computers. After the breakup of Acorn in 1998, development of RISC OS was continued by several companies, including RISCOS Ltd and Castle Technology Ltd. Also since 1998, RISC OS has been bundled with a number of ARM based ‘Acorn Clone’ personal computers such as the Iyonix and A9home.

Adapted from the Wikipedia article RISC OS, under the G. N. U. Free Documentation License. Please also see http://en.wikipedia.org/wiki

No related posts.

Acorn Computers

An early implementation of the taskbar concept is seen in Acorn Computers Arthur operating system, which was released in 1987 for their Acorn Archimedes computer. It is called the ”Iconbar” and remains an essential part of Arthur’s succeeding RISC OS operating system. The Iconbar holds icons which represent mounted disc drives and RAM discs, running applications and system utilities. These icons have their own context-sensitive menus and support drag and drop behaviour.

Unix and Unix-like=

KDE

In various KDE distributions, the taskbar is run by the Kicker program, which shows rectangular ”panels” that can contain ”applets”, one of which is the taskbar. Applets can be arbitrarily relocated, for instance, the notification area can be moved away from the taskbar. The bar can be placed not only at the bottom, but also at the top or (vertically) at the left or the right and its size can be altered (from 24 to 256 pixels), as well as the length in % of the screen size. And several other bars with various specific functions can be added in different locations, e.g., one bar at the left and one at the right or even overlapping (one fixed and one with automatic hiding).

Since KDE 4, the taskbar is implemented as a Plasma widget.

GNOME

Similarly, the GNOME desktop environment uses its own type of taskbar, known as panels (the program responsible for them is therefore called gnome-panel). By default, GNOME usually contains two full-width panels at the top and bottom of the screen. The top

The bottom panel is commonly empty by default, other than a set of buttons to navigate between desktops and a button to minimize all windows and show the desktop, due to its use in the navigation between windows (windows minimize to the bottom panel by default).

These panels can be populated with other customizable menus and buttons, including new menus, search boxes, and icons to perform quick-launch like functions. Other applications can also be attached to the panels, and the contents of the panels can be moved, removed, or configured in other ways.

Window managers that provide an integrated taskbar

* fluxbox

* fvwm95

* icewm

* jwm

* qvwm

* windowlab

Other Unix environments

There are many programs that offer standalone taskbars for desktop environments or window managers without one. Example include pypanel, fbpanel, perlpanel, tint2, and others.

Apple Macintosh computers

The Dock, as featured in Mac OS X and its predecessor NEXTSTEP, is also a kind of taskbar. The Mac OS X Dock is application-oriented instead of window-oriented. Each running application is represented by one icon in the Dock regardless of how many windows it has on screen. A textual menu can be opened by right-clicking on the dock icon that gives access to an application’s windows, among other functions determined by the app. Minimized windows also appear in the dock, in the rightmost section, represented by a graphical thumbnail. The trash can is also represented in the Dock, as a universal metaphor for deletion. For example, dragging selected text to the trash should remove the text from the document and create a clipping file in the trash.

The right side of OS X’s Menu bar also contains several notification widgets and quick access functions, called Menu extras.

Adapted from the Wikipedia article Taskbar, under the G. N. U. Free Documentation License. Please also see http://en.wikipedia.org/wiki

No related posts.

OS core

* Stored in ROM – This gives a fast bootup time and safety from operating system corruption. RISC OS 4 and 5 are stored in 4 MB of Flash ROM, allowing the operating system to be updated without having to replace the ROM chip.

* Module-based – The operating system is made up of a number of modules. These can be added and replaced, including soft-loading of modules not present in ROM at run time and on-the-fly replacement. This design has led to OS developers releasing rolling updates to its version of RISC OS, while third parties are able to write OS replacement modules to add new features. OS modules are accessed via software interrupts (SWIs), similar to system calls in other operating systems.

* Single user, co-operative multitasking – While most current desktop operating systems use pre-emptive multitasking (PMT) and multithreading, RISC OS remains with a co-operative multitasking system and basic pthread support. Although this is preferential for RISC OS’ many embedded applications, many users have called for the OS to migrate to PMT. The OS also has only rudimentary memory protection, and all users have full superuser privileges.

* Volume-oriented filesystem – The top level of the file hierarchy is a volume (disc, network share) prefixed by the filesystem type. The OS uses metadata to determine file type; file extensions are not used. Colons are used to separate the filesystem from the rest of the path; the root is represented by a dollar ($) sign and directories by a period (.). Extensions from foreign filesystems are shown using a forward slash (‘example.txt’ becomes ‘example/txt’). For example, ”ADFS::HardDisc4.$.” is the root of the disc named HardDisc4 using the ADFS filesystem.

* Image filing systems – A filesystem can present a file of a particular type as a volume in its own right – similar to an automatic loopback device. This allows transparent handling of archives and similar files – they just appear like a directory with some special properties, and files inside the archive (”image file”) appear in the hierarchy underneath the parent archive. It is not necessary for the archive to contain the data it refers to: some symbolic link and network share filesystems simply put a reference inside the image file and go elsewhere for the data.

* Filters and vectors – Almost everything in RISC OS has a defined ABI. The OS provides many ways the programmer can intercept and modify operation of the OS, which makes it simple to write modules that modify OS behaviour – either in the GUI or deeper. Through this mechanism there is a multitude of third-party programs which allow customising of the OS look and feel.

The Desktop

* Intuitive window manager – Launched during the time of Windows 2.0 and Mac OS System 6, the RISC OS WIMP incorporates three-buttoned mouse operation (named ‘Select’, ‘Menu’ and ‘Adjust’), context-sensitive menus, window order control (i.e. send to back) and dynamic window focus (a window can have input focus at any position on the stack).

* Icon bar – Similar to the NextStep/Mac OS X dock and the Windows taskbar, but predating both. The bar holds icons which represent mounted disc drives and RAM discs, running applications and system utilities. These icons have their own context-sensitive menus and support drag and drop behaviour. These represent the running application as a whole, irrespective of whether it has open windows.

* Filer-based – The GUI is centred around the concept of files. The Filer displays the contents of a disc. Applications are run from the Filer view, files can be double clicked to open them, and dragged to and from the Filer view from applications to save and load them.

* Full drag-and-drop support – The user is able to copy and move data between application windows and disc locations via the Filer by direct manipulation.

* Self-contained application view – Applications are represented by a directory whose name begins with an exclamation mark (pronounced pling). Double-clicking on such a directory launches the application rather than opening the directory. The application’s executable files and resources are contained within the directory, but normally they remain hidden from the user. Because applications are self-contained, this allows drag and drop installation and removal.

* Sub-pixel positioning anti-aliasing – The outline font manager provides anti-aliasing of fonts. RISC OS was one of the first operating systems to include such a feature.

* Consistent look and feel across all applications – Introduced by Acorn with RISC OS 3, the RISC OS Style Guide is a 130-page document specifying the rules on application appearance and behaviour.

Bundled applications

Applications bundled with RISC OS vary slightly between versions, but typically include:

* !Paint – a basic pixel-based drawing program

* !Draw – a vector-based (or object-based) drawing program

* !Calc – a basic calculator application

* !Edit – a text editor

* !Maestro – a simple scorewriter, with playback

* !Alarm – an iconbar clock program, with ability to set alarms

* !Chars – a special character insertion utility

* !Help – an interactive, context sensitive help feature giving help for items under the mouse pointer

Adapted from the Wikipedia article RISC OS, under the G. N. U. Free Documentation License. Please also see http://en.wikipedia.org/wiki

No related posts.

The concept of a ”resource manager” for graphics objects, to save memory, originated in the OOZE package on the Alto in Smalltalk-76. The concept is now largely universal in all modern operating systems. However, the concept of the resource fork remains peculiar to the Macintosh. Most operating systems used a binary file containing resources, which is then “tacked onto” the end of an existing program file. This solution is used on Microsoft Windows for instance, and similar solutions are used with the X Window System, although the resources are often left as a separate file.

Although the Windows NT NTFS can support forks (and so can be a file server for Mac files), the native feature providing that support, called an alternate data stream, (introduced for this very reason) has never been used extensively — certainly not as a true resource fork. However, Windows operating system features (such as the standard Summary tab in the Properties page for non-Office files) and Windows applications are using them more often now, and Microsoft was developing a next-generation file system that has this sort of feature as basis.

Early versions of the BeOS implemented a database within the filesystem, which could be used in a manner analogous to a resource fork. Performance issues led to a change in later releases to a system of complex filesystem attributes. Under this system resources were handled in a fashion somewhat more analogous to the Mac.

AmigaOS does not use forked files. Its executable files are internally divided into a modular structure of large

NeXT operating systems NeXTSTEP and OPENSTEP, and its successor, Mac OS X, and other systems like RISC OS implemented another solution. Under these systems the resources are left in an original format, for instance, pictures are included as complete TIFF files instead of being encoded into some sort of container. These resources are then placed in a directory along with the executable code and “raw data”. The directory (called a “bundle” or “application directory”) is then presented to the user as the application itself. This solution provides all of the same functionality as the resource fork, but allows the resources to be easily manipulated by any application – a “resource editor” (like ResEdit) is not needed. From the command line interface, the bundle appears to be a normal directory. This approach was not an option on the original Mac OS, since the file system (MFS) did not support folders/directories. Mac OS X does retain the classic Resource Manager API as part of its Carbon libraries for backward compatibility. However, the resources themselves can now be stored in separate data files within the filesystem — the Resource Manager now hides this implementation change from the client code.

Adapted from the Wikipedia article Resource fork, under the G. N. U. Free Documentation License. Please also see http://en.wikipedia.org/wiki

No related posts.

Through the evolution of user interfaces, the menu bar has been implemented in different ways by different user interfaces and application programs.

Macintosh

In the Macintosh operating system, the menu bar is a horizontal “bar” anchored to the top of the screen. In Mac OS X, the left side contains the Apple menu and the currently focused application’s menus (e.g. File, Edit, View, Window, Help). On the right side, it contains menu extras (for example the system clock, volume control, and the Fast user switching menu if enabled) and the Spotlight icon. All of these menu extras (excluding Spotlight) can be moved horizontally by command-clicking and dragging left or right. If an icon is dragged and dropped vertically it will disappear with a puff of smoke, much like the icons in the dock. In the classic Mac OS (versions 7 through 9), the right side contains the application menu, allowing the user to switch between open applications.

There is only one menu bar, so the application menus displayed are those of the application that is currently focused. Therefore, for example, if the System Preferences application is focused, its menus are in the menu bar, and if the user clicks on the Desktop which is a part of the Finder application, the menu bar will then display the Finder menus.

Early Apple experiments in GUI design initially used multiple menu bars anchored to the tops of windows, but this was quickly dropped in favor of the current arrangement, as it proved slower to use (in accordance with Fitts’s law). The idea of separate menus in each application was later implemented in Microsoft Windows.

The universal graphical menu bar first appeared in the Apple Lisa in 1983, and has been a feature of all versions of the Macintosh system since the first Macintosh was released in 1984. It is still used in Mac OS X. Earlier than LISA came, some UI’s had drop-down menus but they were found complex when multiple menus were shown.

Microsoft Windows

The menu bar in Microsoft Windows is usually anchored to the top of a window under the title bar; therefore, there can be many menu bars on screen at one time. Menus in the menu bar can be accessed through shortcuts involving the Alt key and the mnemonic letter that appears underlined in the menu title. Additionally, pressing Alt or F10 brings the focus on the first menu of the menu bar.

Linux and UNIX

KDE allows users to turn Macintosh-style and Windows-style menu bars on and off. It is possible to have both types in use at the same time.

GNOME uses a menu bar at the top of the screen, but this menu bar only contains Applications and System menus and status information (such as the time of day); individual programs have their own menu bars as well. However, it is possible to change this behavior for some applications.

Other window managers and desktop environments use a similar scheme, where programs have their own menus, but clicking one or more of the mouse buttons on the root window brings up a menu containing, for example, commands to launch various applications or to log out.

Window manager menus in Linux are typically configurable either by editing text files, by using a desktop-environment-specific Control Panel applet, or both.

;Window managers that provide a menubar

* amiwm (Temporary menubar provides a box to enter commands, programs not listed, no start button, not a taskbar)

* awesome Provides a menu bar, but it is only available when the desktop is visible

* cwm

* fluxbox (Provides a combined taskbar showing running applications)

* fvwm95 (Provides a start button and combined taskbar showing running applications)

* icewm (Provides a start button and combined taskbar showing running applications)

* jwm (Provides a start button and combined taskbar showing running applications)

* qvwm (Provides a start button and combined taskbar showing running applications)

* whim

* windowlab – This provides a taskbar only, which does not show a menu,

* xpwm (Provides a start button and combined taskbar showing running applications)

Commodore Amiga

The Amiga used a menu-bar style similar to the Macintosh, with the exception that the machine’s custom graphics chips allowed each program to have its own “screen”, with its own resolution and colour settings, which could be dragged down to reveal the screens of other programs. The title/menu bar would typically sit at the top of the screen, and could be accessed by pressing the right mouse button, revealing the names of the various menus. When the right menu button was not pressed down, the menu/title bar would typically display the name of the program which owned the screen, and some other information such as the amount of memory used.

The Workbench screen title bar would typically display the internal Kickstart and Workbench version, the total amount of chip and fast memory, and the amount of free Chip RAM and Fast RAM. An unusual feature of the Amiga menu system was that the Workbench screen would display a “Workbench” menu instead of a “File” or “Apple” menu, whilst conforming applications would display “Project” and “Tools” menus (”projects” and ”tools” being, respectively, the Amiga terms for what in other systems are called ”files” or ”documents”, and ”programs” or ”applications”).

Keyboard shortcuts could be accessed by pressing the left-hand “left Amiga” key along with a normal alphanumeric key. (Some early keyboards had a Commodore key to the left of the spacebar instead of a “left-Amiga” key.) The filled-in and hollowed-out designs, respectively, of the left-and-right Amiga (or Commodore and Amiga) keys were inspired by the similar closed-Apple and open-Apple keys of Macintosh and Apple II keyboards.

NeXTstep

The NeXTstep OS for the NeXT machines would display a “menu list”, by default at the top left of the screen. Clicking on the entries in the menu list would display submenus of the commands in the menu. The contents of the menu change depending on whether the user is “in” the Workspace Manager or an application. The menus and the sub-menus can easily be torn off.

Power users would often switch off the always-on menu, leaving it to be displayed at the mouse pointer’s location when the right mouse button was pressed. The same implementation is used by GNUstep and conforming apps, though applications written for the host operating system or another toolkit will use the menu scheme appropriate to that OS or toolkit.

Atari TOS

The TOS operating system for the Atari ST would display menu bars at the top of the screen like Mac OS.

RISC OS

In RISC OS, clicking the middle button displays a menu list at the location of the mouse pointer. The RISC OS implementation of menus is similar to the context menus of other systems, except that menus will not close if the right mouse button is used to select a menu entry. This allows the user to implement or try out several settings before closing the menu.

Adapted from the Wikipedia article Menu bar, under the G. N. U. Free Documentation License. Please also see http://en.wikipedia.org/wiki

No related posts.

filename extension is a suffix to the name of a computer file applied to indicate the encoding convention (file format) of its contents.

In some operating systems (for example UNIX) it is optional, while in some others (such as DOS) it is a requirement. Some operating systems limit the length of the extension (such as DOS and OS/2, to three characters) while others (such as UNIX) do not. Some operating systems (for example RISC OS) do not use filename extensions. UNIX accepts the separator dot as a legal character but does not give it a special recognition on the OS level.

Adapted from the Wikipedia article Filename extension, under the G. N. U. Free Documentation License. Please also see http://en.wikipedia.org/wiki

No related posts.

Ruby MRI is available for the following operating systems:

* Acorn RISC OS

* Amiga

* BeOS

* DOS (32-bit)

* Internet Tablet OS

* Linux

* Mac OS X

* Microsoft Windows 95/98/2000/2003/NT/XP/Vista

* Microsoft Windows CE

* MorphOS

* OS/2

* OpenVMS

* Syllable

* Symbian OS

* Blue Gene/L compute node kernel

* Most flavors of Unix

This list may not be exhaustive.

Adapted from the Wikipedia article Ruby MRI, under the G. N. U. Free Documentation License. Please also see http://en.wikipedia.org/wiki

No related posts.