Windows NT startup process

The Windows NT startup process is the process by which Windows NT 4.0, Windows 2000, Windows XP and Windows Server 2003 operating systems initialize. In Windows Vista and later, this process has changed significantly; see Windows Vista startup process for information about what has changed.
Installer.
The Windows NT installer works very similarly to a regular Windows NT install except that it runs from a CD-ROM. For this boot method to work, the BIOS must be compatible with the El Torito specification. The ISO 9660 file system on the install CD is not fully compatible with the standard. Although it is "Level 1", the file names don't have the file version appended to it. The boot image is of the "no emulation" type, 1 sector long (2048 bytes) and is loaded at segment 0x7c0. It can be extracted from an ISO image by using a file-extraction program such as 7-Zip or WinZip. The ISO image is also not hybridized like ISO images from most Linux distributions and therefore it does not contain any master boot record (MBR) which makes it unable to boot by just copying the image over a block device such as a pen drive.
The installer can also be run from a MS-DOS command prompt so previous versions of Microsoft Windows that are already installed can be upgraded. To run the installer from a MS-DOS based operating system such as Windows 98 or Windows ME, the user must start the system "in DOS mode" and then execute I386/WINNT.EXE on the CD-ROM.
A floppy disk containing MS-DOS can be used to start the installer. Versions of the installer in floppies were also available for sale. From Windows Vista onwards, the installer runs from BOOT.WIM which contains a bootable version of Windows PE. Windows PE 2.0 is based on the Windows Vista kernel, later Windows PE versions are based on later Windows versions.
CD-ROM boot image phase.
On a regular CD-ROM install, the BIOS executes the POST and then searches for a boot descriptor on the CD-ROM. The boot descriptor points to a boot catalog file on the ISO 9660 file system. The BIOS searches for a boot image compatible with the current architecture, loads it into memory and then runs it. The boot image is analogous to the boot sector on a hard drive. The boot image loads SETUPLDR.BIN which is analogous to NTLDR. If this fails for any reason, a message is displayed saying that NTLDR was not found, which may of itself be misleading; moreover, the NTLDR on the CD is never used during the loading phase of the installer. The process also assumes that file versions are unavailable.
Before starting the boot loader, the boot image checks whether there is a Windows install (system) already present and, if so, it starts codice_1. If no install is found, or if the disk does not have an MBR, then it starts the boot loader directly, thus obviating the need for codice_1. If codice_1 is started, it displays the string "Press any key to boot from CD." and waits for user input. If none is detected for some seconds, then it boots the next device, and so on. This behavior is essential for booting the second stage of the installer, which starts from the hard disk.
Boot loader phase.
Both codice_4 and codice_5 are composed of two binary files concatenated.
They also can be found on the installation CD as compressed CAB files.
The first file is codice_6, which is a flat binary file that just loads the second file. The second file is a regular EXE file in the Portable Executable format.
In codice_4 the second file is codice_8 and in codice_5 the second file is codice_10. Both codice_8 and codice_10 have embedded file system drivers for basic access on FAT, NTFS and ISO 9660. Differently from regular *.SYS drivers, the boot loader uses BIOS interrupts to access the boot disk. It also contains a built-in INI parser and CAB decompressor.
After the installer starts running, it prints the string "Setup is inspecting your computer's hardware configuration...". codice_13 is called and the system information is stored in memory. It then displays a blue screen in VGA text mode with the title "Windows Setup", or "Windows *version name here* Setup", with a white line on the bottom that serves as a status bar.codice_13then looks for codice_15 and parses it. This file works as a key-value database just like the registry or an *.INI or *.INF file. The keys may either contain a list of files associated with their install location or a script line. Therefore, the database stores data and code. During the parsing, the blank lines are ignored and sections with the same name are merged.
The file codice_16 is also loaded to resolve hardware quirks.
The key-value syntax in the codice_17 section is as follows:
filename_on_source = disk_id,subdir,upgrade_code,new_install_code,spare,spare,new_filename
The installer asks if any additional drivers need to be loaded and loads text mode drivers.
If so, they can be loaded from a floppy disk only. There is a hidden feature that shows a screen prompting the user to select a computer type if F5 is pressed during the first message.
Text mode drivers are a different from PnP drivers as they are loaded regardless if the hardware is present or not. The loading phase of the installer displays some messages on the screen about the current file being loaded. The message is "Setup is loading files ([the file description])...". The files loaded in this phase are those located in sections ending in codice_18. In those sections, the key gives a driver name and the value gives a file. The driver name is then looked up in the same section without the codice_18 suffix to find the driver's user-friendly name. The kernel also needs a registry hive mounted to load the registry from, so codice_20 is also loaded. All the file names of the files loaded by the boot loader are hard-coded except for the drivers.
As for PnP devices, after being identified by a bus driver, the address in checked in the section codice_21 and a corresponding driver name is given. But those are not used in this step.
Kernel phase.
After all boot files are loaded by the boot loader, the message "Setup is starting Windows" is displayed and the kernel starts. Just like a normal install, it starts the drivers and loads the only service which is codice_22. It runs in kernel mode and starts a GUI still in text mode. From now on, all the drivers are NT based and BIOS interrupts are not used anymore.
The user is asked to choose a file system layout. The selected partition is formatted if necessary and the files from TXTSETUP.SIF are copied to the system. Then it creates the registry hives and automatically restarts the system so the NT system can start and bootstrap itself. The section HiveInfs points to the files used to fill the hives with the default values. On a fresh install this section is named codice_23. The files are not reg files but are also ini files that can be understood by the ini interpreter bundled with the installer. The disk formatter program is statically linked with codice_22.
Remastering.
There are many freeware tools available on the internet that customize TXTSETUP.SIF for the creation of unattended installs or to integrate drivers and hotfixes. This process is sometimes referred as slipstreaming.
The following command shows how a remastered CD can be created with a minimum set of options on Linux. It assumes that the current directory is the CD mount point. The image will be created at the home directory.
mkisofs -b Bootable_NoEmulation.img -no-emul-boot -N . > ~/ntsetup.iso
The file codice_25 can be used to make the install unattended but it is not required to be present. There is a model file on the CD named codice_26. Setup tries to detect winnt.sif in the codice_27 directory or on the root directory of a floppy disk.
Boot loader phase.
Windows NT startup process starts when the computer finds a "Windows boot loader", a portion of Windows operating system responsible for finding Microsoft Windows and starting it up. Prior to Windows Vista however, the boot loader was NTLDR. Microsoft has also released operating systems for Intel Itanium processors which use IA-64 architecture. The boot loader of these editions of Windows is IA64ldr.efi (later referred as simply IA64ldr). It is an Extensible Firmware Interface (EFI) program.
Operating system selection.
The boot loader, once executed, searches for Windows operating systems. Windows Boot Manager does so by reading Boot Configuration Data (BCD), a complex firmware-independent database for boot-time configuration data. Its predecessor, codice_5, does so by reading the simpler codice_29. If the boot.ini file is missing, the boot loader will attempt to locate information from the standard installation directory. For Windows NT and 2000 machines, it will attempt to boot from codice_30. For Windows XP and 2003 machines, it will boot from codice_31.
Both databases may contain a list of installed Microsoft operating systems that may be loaded from the local hard disk drive or a remote computer on the local network. NTLDR supports operating systems installed on disks whose file system is NTFS or FAT file systems, CDFS (ISO 9660) or UDFS. Windows Boot Manager also supports operating systems installed inside a VHD file, stored on an NTFS disk drive.
In Windows 2000 or in later versions of Windows in which hibernation is supported, the Windows boot loader starts the search for operating systems by searching for "hiberfil.sys". NTLDR looks into the root folder of the default volume specified in boot.ini. Windows Boot Manager looks up the location of hiberfil.sys in BCD. If this file is found and an active memory set is found in it, the boot loader loads the contents of the file (which is a compressed version of a physical memory dump of the machine) into memory and restores the computer to the state that it was prior to hibernation.
Next, the boot loader looks for a list of installed operating system entries. If more than one operating system is installed, the boot loader shows a boot menu and allow the user to select an operating system. If a non NT-based operating system such as Windows 98 is selected (specified by an MS-DOS style of path, e.g. C:\), then the boot loader loads the associated "boot sector" file listed in "boot.ini" or BCD (by default, this is "bootsect.dos" if no file name is specified) and passes execution control to it. Otherwise, the boot process continues.
Loading the Windows NT kernel.
The operating system starts when certain basic drivers flagged as "Boot" are loaded into memory.
The appropriate file system driver for the partition type (NTFS, FAT, or FAT32) which the Windows installation resides in are amongst them. At this point in the boot process, the boot loader clears the screen and displays a textual progress bar, (which is often not seen due to the initialization speed); Windows 2000 also displays the text "Starting Windows..." underneath. If the user presses F8 during this phase, the advanced boot menu is displayed, containing various special boot modes including Safe mode, with the Last Known Good Configuration, with debugging enabled, and (in the case of Server editions) Directory Services Restore Mode. Once a boot mode has been selected (or if F8 was never pressed) booting continues.
The following files are loaded sequentially.
Next, NTDETECT.COM and the Windows NT kernel ("Ntoskrnl.exe") and the Hardware Abstraction Layer ("hal.dll") are loaded into memory. If multiple hardware configurations are defined in the Windows Registry, the user is prompted at this point to choose one.
With the kernel in memory, boot-time device drivers are loaded (but not yet initialized). The required information (along with information on all detected hardware and Windows Services) is stored in the codice_32 portion of the registry, in a set of registry keys collectively called a "Control Set". Multiple control sets (typically two) are kept, in the event that the settings contained in the currently-used one prohibit the system from booting. codice_32 contains control sets labeled codice_34, codice_35, etc., as well as codice_36. During regular operation, Windows uses codice_36 to read and write information. codice_36 is a reference to one of the control sets stored in the registry. Windows picks the "real" control set being used based on the values set in the codice_39 registry key:
When a control set is chosen, the codice_45 key gets set accordingly. The codice_41 key is also set to the same as codice_45 until the end of the boot process. codice_43 is also set to codice_45 if the boot process completes successfully.
Which services are started and the order which each group is started in are provided by the following keys:
For the purposes of booting, a driver may be one of the following:
With this finished, control is then passed from the boot loader to the kernel.
Kernel phase.
The initialization of the kernel subsystem and the Windows Executive subsystems is done in two phases.
During the first phase, basic internal memory structures are created, and each CPU's interrupt controller is initialized. The memory manager is initialized, creating areas for the file system cache, paged and non-paged pools of memory. The Object Manager, initial security token for assignment to the first process on the system, and the Process Manager itself. The System idle process as well as the System process are created at this point.
The second phase involves initializing the device drivers which were identified by NTLDR as being system drivers.
Through the process of loading device drivers, a "progress bar" is visible at the bottom of the display on Windows 2000 systems; in Windows XP and Windows Server 2003, this was replaced by an animated bar which does not represent actual progress. Prior to Windows XP, this part of the boot process took significantly longer; this is because the drivers would be initialized one at a time. On Windows XP and Server 2003, the drivers are all initialized asynchronously.
Session Manager.
Once all the Boot and System drivers have been loaded, the kernel (system thread) starts the Session Manager Subsystem (codice_52).
Before any files are opened, Autochk is started by "smss.exe". Autochk mounts all drives and checks them one at a time to see whether or not they were cleanly unmounted. If autochk determines one or more volumes are dirty, it will automatically run chkdsk and provides the user with a short window to abort the repair process by pressing a key within 10 seconds (introduced in Windows NT 4.0 Service Pack 4; earlier versions would not allow the user to abort chkdsk). Since Windows 2000, XP and 2003 show no text screen at that point (unlike NT 3.1 to 4.0, which displayed a blue text screen), the user will see a different background picture holding a mini-text-screen in the center of the screen and show the progress of chkdsk there.
At boot time, the Session Manager Subsystem:
The Session Manager stores its configuration at codice_59. The exact operation of most of these items is based on the configuration set in the registry.
Authentication.
Winlogon starts the Local Security Authority Subsystem Service (LSASS) and Service Control Manager (SCM), which in turn will start all the Windows services that are set to "Auto-Start". It is also responsible for responding to the secure attention sequence (SAS), loading the user profile on logon, and optionally locking the computer when a screensaver is running.
The login process is as follows:
If the user is trying to log into the local host then the codice_71 key will be used as database. If the user is trying to log into another host then the NetLogon service is used to carry the data.
msv1_0.dll<->netlogon<->remote netlogon<->remote msv1_0.dll<->remote SAM
On Windows XP, GINA is only shown if the user presses the secure attention sequence.
Winlogon has support for plugins that get loaded and notified about specific events and LSASS also supports plugins (security packages). Some rootkits bundle Winlogon plugins because they are loaded before any user logs in. Some keys allow multiple comma-separated values to be supplied that allow a malicious program to be executed at the same time as a legitimate system file. The hashing algorithms used to store credentials in the SAM database are weak and can be brute-forced quickly on consumer hardware.
Winlogon's responsibilities and the login process have changed significantly from the above in Windows Vista.
Shell.
Userinit is the first program that runs with the user credentials. It is responsible to start all the other programs that compose the user shell environment.
The shell program (typically codice_72) is started from the registry entry codice_73 pointed to by the same registry entry in key
codice_74; its default value is codice_75, which evaluates to codice_76.
Userinit runs startup programs from the following locations:
Remote booting and installation.
To successfully boot, the client must support PXE booting and the Windows Deployment Services (WDS) component must be installed on the server. It is not installed by default. WDS is the successor of Remote Installation Services (RIS).
The PXE program is found on the BIOS or on a ROM chip on the network card.
PXE booting is not a technology specific to Windows and can also be used to start a Linux system. In fact, a Linux system can act as a server to service DHCP or TFTP.
PXE can be used to start Windows Setup to install the system on the client computer or to run the operating system from RAM. The latter, called Remote Boot, was introduced by Windows XP Embedded SP1 and is only available for this flavor of Windows.
The general process for both methods is as follows:
The Boot Information Negotiation Layer (BINL) is a Windows 2000 service running on the server that communicates with the client after the NBP was already loaded by the PXE.


GENCMD.COM


System partition and boot partition

The system partition and the boot partition (also known as the system volume and the boot volume) are computing terms for disk partitions of a hard disk drive or solid-state drive that must exist and be properly configured for a computer to operate. There are two different definitions for these terms: the common definition and the Microsoft definition.
Common definition.
In context of every operating system, save those developed by Microsoft, the system partition and the boot partition are defined as follows:
In Linux, a single partition can be both a boot and a system partition if both codice_1 and the root directory are in the same partition.
Microsoft definition.
Since Windows NT 3.1 (the first version of Windows NT), Microsoft has defined the terms as follows:
A single partition may be both a system and a boot partition. However, in case they are separate, the boot partition does not contain the boot loader and the system partition does not have the system root.
Before Windows 7, the system and boot partitions were, by default, the same and were given the "C:" drive letter. Since Windows 7, however, Windows Setup creates, by default, a separate system partition that is not given an identifier and therefore is hidden. The boot partition is still given "C:" as its identifier. This configuration is suitable for running BitLocker, which requires a separate unencrypted system partition for booting.


MCC Interim Linux

MCC Interim Linux was a Linux distribution first released in February 1992 by Owen Le Blanc of the Manchester Computing Centre (MCC), part of the University of Manchester. It was the first Linux distribution created for computer users who were not Unix experts and featured a menu-driven installer that installed both the kernel and a set of end-user and programming tools.
The MCC first made Linux available by anonymous FTP in November 1991. Le Blanc's irritations with his early experiments with Linux, such as the lack of a working fdisk (he would later write one), the need to use multiple FTP repositories to acquire all the essential software, and library version problems, inspired the creation of this distribution.
Le Blanc claimed he referred to the distributions as "interim" because "...they are not intended to be final or official. They are small, harmonious, and moderately tested. They do not conform to everyone's taste -- what release does? -- but they should provide a stable base to which other software can be added."
History.
Prior to its first release, the closest approximation to a Linux distribution had been H J Lu's "Boot/Root" floppy disk images from early 1992. These were two 5¼" diskette images containing the Linux kernel and the minimum tools required to get started. So minimal were these tools that to be able to boot from a hard drive required editing its master boot record with a hex editor.
The first release of MCC Interim Linux was based on Linux 0.12 and made use of Theodore Ts'o's ramdisk code to copy a small root image to memory, freeing the floppy drive for additional utilities diskettes.
He also stated his distributions were "unofficial experiments", describing the goals of his releases as being:
Indeed, no attempt was ever made to distribute it with a wide range of software or even the X386 windowing system.
Successors.
Soon after the first release came other distributions such as TAMU, created by individuals at Texas A&M University, Martin Junius's MJ, Softlanding Linux System and H J Lu's small base system. These in turn were quickly superseded by Debian, Red Hat Linux and Slackware, the oldest surviving distributions.
The 1.0 distribution of MCC Interim pointed out that Debian was "five times the size of MCC, and quite comprehensive", and the final distribution encouraged users to switch to Debian by providing transitional support.
Included software.
Version 0.95c+.
As discussed in an email dated 23 April 1992, the boot and utilities disk pair included:
An optional pair of disks contained gcc and g++ 2.1, kermit and shoelace.
Version 0.99.p8.
Released on 14 April 1993. Added to version 0.95c+ were bison, flex, gdb, gprof, groff, gzip and man.
Version 0.99.p8+.
Released on 26 April 1993. Added to version 0.99.p8 were emacs and info.
Version 1.0+.
Added to version 0.99.p8+ were elm, lp, mail, progman, timezone and words


JO.SYS


Beavis and Butt-Head (video game)

Beavis and Butt-Head (advertised as MTV's Beavis and Butt-Head: The Game) were three tie-in video games based on the animated television series of the same name that were released by Viacom New Media in 1994 for the Super NES, Genesis/Mega Drive and Game Gear. The three versions differ from each other, sharing only the basic premise involving the titular characters searching for tickets to a Gwar concert. The games were advertised as featuring music by the band. A fourth version was later released for the Game Boy by GT Interactive Software in 1998 without the Gwar tie-in.
Premise.
It is based on MTV's animated series of the same name, and follows the title characters Beavis and Butt-Head as they attempt to find their torn-up Gwar concert tickets.
Development.
The Super NES version was developed by Realtime Associates, the Game Gear version by NuFX, and the Genesis/Mega Drive version by Radical Entertainment, all which were published by Viacom New Media and released in 1994. A Game Boy version was released in 1998, developed by Torus Games and published by GT Interactive, which revolved around the boys trying to join Todd's gang.
Reception.
Reviewing the Genesis version, "GamePro" commented that ""Beavis and Butt-Head" is for gamers who possess both thumb speed and the patience to undertake a lengthy junk hunt to crack obscure puzzles." They criticized the extensive trial-and-error involved in obtaining items, but praised the controls and the visual style's coherence with the look of the TV show. "Electronic Gaming Monthly" assessed that fans of the TV show would probably like the game, but that anyone else would definitely not like it. "Next Generation" stated that ""Beavis and Butt-Head" is a game that shows while moronic humor and plenty of flatulence may make great TV, it stinks as a game."
"GamePro"s review of the Super NES version was subdued, commenting that the game "doesn't suck, but it doesn't rule either." They again praised the controls and the game's recreation of the TV show's look, but described the gameplay as "straightforward but uninspired".
"Next Generation" reviewed the PC version of the game, stating that "Regardless of the content, the interface and smooth design of the game make it a great graphic adventure. This game rules!"


Acorn MOS

The Machine Operating System (MOS) or OS is a discontinued computer operating system (OS) used in Acorn Computers' BBC computer range. It included support for four-channel sound, graphics, file system abstraction, and digital and analogue input/output (I/O) including a daisy-chained expansion bus. The system was single-tasking, monolithic and non-reentrant.
Versions 0.10 to 1.20 were used on the BBC Micro, version 1.00 on the Electron, version 2 was used on the B+, and versions 3 to 5 were used in the BBC Master series.
The final BBC computer, the BBC A3000, was 32-bit and ran RISC OS, which kept on portions of the Acorn MOS architecture and shared a number of characteristics (e.g. "star commands" CLI, "VDU" video control codes and screen modes) with the earlier 8-bit MOS.
Versions 0 to 2 of the MOS were 16 KiB in size, written in 6502 machine code, and held in read-only memory (ROM) on the motherboard. The upper quarter of the 16-bit address space (0xC000 to 0xFFFF) is reserved for its ROM code and I/O space.
Versions 3 to 5 were still restricted to a 16 KiB address space, but managed to hold more code and hence more complex routines, partly because of the alternative 65C102 central processing unit (CPU) with its denser instruction set plus the careful use of paging.
User interface.
The original MOS versions, from 0 to 2, did not have a user interface per se: applications were expected to forward operating system command lines to the OS on its behalf, and the programming language BBC BASIC ROM, with 6502 assembler built in, supplied with the BBC Micro is the default application used for this purpose. The BBC Micro would halt with a codice_1 error if no ROM is present that advertises to the OS an ability to provide a user interface (called "language ROMs"). MOS version 3 onwards did feature a simple command-line interface, normally only seen when the CMOS memory did not contain a setting for the default language ROM.
Application programs on ROM, and some cassette and disc-based software also, typically provide a command line, useful for working with file storage such as browsing the currently inserted disc. The OS provides the line entry facility and obeys the commands entered, but the application oversees running the command prompt.
Cassette and disc based software typically relies on BBC BASIC's own user interface in order to be loaded, although it is possible to configure a floppy disk to boot up without needing to have BASIC commands executed, this was rarely used in practice.
In BBC BASIC, OS commands are preceded with an asterisk or passed via the OSCLI keyword, to instruct BASIC to forward that command directly to the OS. This led to the asterisk being the prompt symbol for any software providing an OS command line; MOS version 3 onwards officially uses the asterisk as the command prompt symbol. When referring to an OS command, they generally include the asterisk as part of the name, for example , , etc., although only the part after the asterisk is the command. The asterisk was called a "star" and the commands were called "star commands".
Unrecognised commands are offered to any "service" (extension) ROMs; filing system ROMs will often check to see if a file on disc matches that name, the same most other command-line interfaces do. The operating system call OSWORD with accumulator = 0 does however offer programs single line input (with ctrl-U for clear line and the cursor copying keys enabled) with basic character filtering and line length limit.
The MOS command line interpreter features a rather unusual idea: abbreviation of commands. To save typing a dot could be used after the first few characters, such as for and for . was abbreviated to alone. , the command to catalogue (list) a cassette or disc, can be abbreviated down to .
Service ROMs.
3rd party ROMs generally also support command abbreviation, leading to ambiguity where two service ROMs provide commands which are very similar in name but possibly different in function. In this case, the MOS would prioritise the command from the ROM in the higher numbered ROM slot, e.g., 7 has precedence over 6.
Some 3rd party suppliers would get around this by prefixing their star commands with other letters. For example, Watford Electronics ROMS would have their star commands prefixed with codice_2 thus making them unique.
Extension.
The lower 16 KiB of the ROM map (0x8000 to 0xBFFF) is reserved for the active Sideways address space paged bank. The Sideways system on the BBC Micro allows for one ROM at a time from sockets on the motherboard (or expansion boards) to be switched into the main memory map. Software can be run from ROM this way (leaving the RAM free of user program code, for more workspace) and the OS can be extended by way of such ROMs. The most prevalent sideways ROM after BASIC is the Acorn Disc Filing System used to provide floppy disc support to the machine.
During a reset, every paged ROM is switched in and asked how much public and private workspace it needs. Each ROM is allocated a chunk of private workspace that remains allocated at all times, and a single block of public workspace, equal to the size of the largest request, is made available to the active ROM. During operation, the paged area is rapidly switched between ROMs when file system commands are issued and unrecognised commands are put to the OS.
MOS allocates a 3.5 KiB block of memory (0x0000 to 0x0DFF) from the bottom of the memory map for operating system and language ROM workspace:
On a cassette-only machine, 0x0E00 is the start of user program memory. With OS extension ROMs fitted such as the a filing system ROM, more memory is allocated above this point; DFS ROMs generally use another 2.75 KiB to cache the disc catalogue and manage random access buffers. A network filing system ROM (for Econet) allocates another 0.5 KiB on top of this. This is a serious problem because MOS does not support relocation of machine code, which must be run from the address at which it was assembled, so some programs which assumed a fixed start of user program memory could overwrite MOS workspace. The problem was alleviated in versions 3 to 5 by allowing ROMs to allocate workspace in an alternative RAM bank at 0xC000 to 0xDFFF which was present in Master series computers, though old ROMs could continue to allocate blocks of main memory.
The OS also maintains a vector table of all its calls which can be updated to hook any OS calls for user extension. By altering or 'hooking' these vectors, developers could substitute their own routines for those provided as defaults by the MOS.
Text, graphics, printing.
The MOS permits textual output intended for the screen to be directed instead to the printer, or both at once, allowing for very trivial printing support for plain text. Graphics printing is not supported and has to be written separately.
Graphics and in general all screen output is handled in a very unusual way. The ASCII control characters are almost entirely given new significance under MOS: known as the "VDU drivers", because the documentation described them in relation to the VDU statement in BBC BASIC, they are interpreted as video control characters. (i.e. ASCII 30) moves the cursor to (0, 0), VDU 4 and 5 select whether text should be drawn at the graphics or text cursor, VDU 12 clears the screen and VDU 14 and 15 turn scroll lock on and off. Thus, pressing ctrl-L will clear the screen and ctrl-N will enable scroll lock. VDU 2 and 3 toggle whether screen output is echoed to the printer. The BBC BASIC VDU statement is equivalent to the conventional BASIC and many of the control codes (such as 12 for "clear screen" and 7 for "beep") have the same functions as on other contemporary machines.
Many more control characters take parameters: one or more characters that follow are used solely for their bit value as a parameter and not as a control code. VDU 19 handles palette remap; the following five bytes represent the palette entry, the desired colour and three reserve bytes. VDU 31 locates the text cursor to the location held in the following two bytes. VDU 17 sets the text colour and 18 the graphics colour. VDU 25 uses the succeeding five bytes to move the graphics cursor and plot solid and dashed lines, dots and filled triangles, the documented extent of graphics in MOS 0 and 1. The first byte is the command code, followed by the x and y co-ordinates as two byte pairs. Other graphic functions such as horizontal line fill bounded by a given colour were available by use of undocumented or poorly documented command codes.
BBC BASIC contained aliases for the commonly used VDU codes (such as GCOL for VDU 18 or PLOT for VDU 25). Some statements were direct equivalents to VDU codes, such as CLS for VDU 12. Some statements were less exact equivalents as they incorporated functionality specific to BASIC as well as calling the OS routines; for example the statement would set screen mode and adjust the BASIC system variable HIMEM according to the amount of memory the new mode left available for BASIC, while would set the screen mode only, without altering HIMEM. This allowed a programmer to allocate a block of memory from BASIC for example to load machine code routines into by lowering the value of HIMEM at the start of a program, and still be free to switch screen modes without deallocating it as a side effect.
There is one operating system command to write a character, OSWRCH, which is responsible for all text and graphics. For example, to move the cursor to (10, 15), needed, in 6502 assembler:
 LDA #31: JSR OSWRCH \ move text cursor
 LDA #10: JSR OSWRCH \ x-coordinate
 LDA #15: JSR OSWRCH \ y-coordinate
(LDA loads a value into the accumulator; JSR is "jump to subroutine".) On the third OS call, the cursor will move. The following code would draw a line from (0, 0) to (0, +100):
 LDA #25: JSR OSWRCH \ begin "PLOT" (ASCII 25) command
 LDA #4: JSR OSWRCH \ command k=4, or move absolute
 LDA #0: JSR OSWRCH: JSR OSWRCH: JSR OSWRCH: JSR OSWRCH
 \ send (0, 0) as low, high byte pairs
 LDA #25: JSR OSWRCH \ begin PLOT
 LDA #1: JSR OSWRCH \ k=1 - draw relative
 LDA #0: JSR OSWRCH: JSR OSWRCH \ x = 0
 LDA #100: JSR OSWRCH \ y = 100 (low byte)
 LDA #0: JSR OSWRCH \ high byte
BBC BASIC allows performing the above as any of the following:
 VDU 25, 4, 0; 0; 25, 4, 100; 0;
 PRINT CHR$(25); CHR$(4); CHR$(0); ... etc.
 PLOT 4, 0, 0: PLOT 1, 0, 100
 MOVE 0, 0: DRAW 0, 100: REM absolute co-ords only!
 OSWRCH=&FFEE: A%=25: CALL OSWRCH: A%=4: CALL OSWRCH: A%=0: CALL OSWRCH ... etc.
Graphics in the Acorn MOS use a virtual graphics resolution of 1280×1024, with pixel positions mapped to the nearest equivalent pixel in the current graphics mode. Switching video resolution will not affect the shape, size or position of graphics drawn even with completely different pixel metrics in the new mode, because this is all accounted for by the OS.
MOS does provide two other OS calls that handle text output: codice_3 and codice_4. OSNEWL writes a line feed and carriage return to the current output stream. OSASCI forwards all characters directly to OSWRCH except for carriage return, which triggers a call to OSNEWL instead. The precise code for OSASCI and OSNEWL five lines of 6502 assembler is documented in the BBC Micro User Guide.
MOS implements character recognition so that text printed on screen in the system font can be selected with the arrow keys and input with the key as though it was being typed. To activate "screen editing" the user moves the hardware cursor to the text to be read and the OS displays a second cursor in software at the original position. Pressing copies one character from the hardware cursor to the software cursor and advances both, so that holding the key down copies a section of the text, the cursors wrapping around the vertical edges of the screen as necessary. If the screen scrolls during editing, the hardware cursor's position is adjusted to follow the text. The user can make changes to the text during the copy, and user-defined characters are recognised in graphics modes. Screen editing is terminated when or are pressed, which have their usual effects. Character recognition is made available to users in the API with a call to read the character at the current cursor position.
Sound.
Sound generation is carried out through another OS call, OSWORD, which handles a variety of tasks enumerated via a task code placed into the accumulator. All OSWORD calls bear a parameter block used to send and receive multiple data; the address of this block is passed in the X and Y registers, with the low byte in X and the high byte in Y. There are four buffered sound channels three melodic and one noise-based on the sound chip found in the BBC Micro. There is only one waveform for melodic channels; the supported note parameters are pitch, duration, amplitude, envelope selection and various control options. For the amplitude parameter, a zero or negative sets a static amplitude, and a positive value select an amplitude and pitch envelope (a predefined temporal variation) to apply to the note.
Control parameters was passed through the channel parameter, and include flush (the buffer is cleared and the channel silenced before the note is played), synchronise count (as soon as the same sync count is received for that many channels, all the synchronised notes are played together), and control over the Speech system upgrade where fitted.
OSWORD handles many functions other than sound, many of which do not have direct support in BASIC. They may be accessed from BASIC by setting up the parameter block, loading its address into X% and Y% and the task code into A%, and then calling the routine.
Other I/O and second processor support.
The BBC Micro had support for a second processor connected via the "Tube", which allowed direct access to the system bus. The driver code for the Tube interface is not held in the MOS, usually being supplied by an external service ROM.
The OS has calls to handle reading and writing to all I/O (ports and screen memory) and programmers are strongly advised to use these by the Acorn documentation. The reason for this is that when a second processor is installed, user software is run from the separate memory map on the far side of the Tube processor bus, and direct access to memory-mapped I/O registers and video memory is impossible. However, for the sake of performance, many apps including many games, write directly to main address space for I/O, and hence crash or give a blank screen if a 6502 second processor is attached. One such performance-critical area is sprite support: BBC Micro hardware does not support sprites, and games must implement sprites in software. In practice, the widespread use of direct access in place of the OS calls very rarely caused problems. Second processor units were expensive and very little software was written to make use of them, so few people bought them, and those who did have them could simply switch them off or unplug the cable if a problem arose.
The MOS contains two built-in file systems: cassette and ROM. These are quite similar (try , , with a suitable ROM installed) and share a great deal of code. They feature a rudimentary copy protection mechanism where a file with a certain flag set cannot be loaded except to execute it. (Before Amstrad's launch of a mass-market twin cassette recorder in 1987, most home users did not have facilities to dub cassettes without loading the files into the computer for re-saving.) The Advanced Disc Filing System (ADFS), installed as standard in the Master series, has a similar mechanism.
Versions.
Releases 0 and 1.
Versions for the BBC Micro family, starting at 0.10 and finishing at 1.20. Confusingly the Electron shipped with version 1.00 despite being released after the BBC Micro's version 1.20, because it was the first release of a ROM for the electron. The MOS version number was not intended as an API definition: the Electron ROM was not "based on" the BBC Micro ROM version 1.0 in any sense.
Release 2.
This version is for the BBC Model B+, essentially the same as MOS 1.20 except with the addition of support for the sideways and shadow RAM present on the B+.
Releases 3 to 5.
MOS 3 to MOS 5 shipped with the BBC Master Series systems, in the Master 128, Master ET, and Master Compact models respectively.
The initial release of MOS 3 expanded upon the facilities provided in MOS 2 on the B+ to support additional hardware, provide a command line facility and extend the VDU driver code with enhanced graphics plotting abilities. Two notable versions were made public: version 3.20 being the most common, and version 3.50 (although this had more functionality and bug fixes it was not 100% compatible with some popular applications software so was offered as an optional upgrade only).
MOS 4 was a stripped down version of MOS 3 intended for the similarly minimized Master ET, and a few minor bugs fixed.
MOS 5 shipped with the Master Compact, and was much altered with some functions removed or highly amended.
Credits.
With the exception of MOS 3.50 where the space was reclaimed for more code, the area normally hidden by the input/output memory locations (the 768 bytes from 0xFC00-0xFEFF inclusive) in the MOS ROM contained a list of names of contributors to the system. This could be recovered by extracting the ROM and reading its contents in an EPROM programmer. Those who did not have such a device could access the ROM on a Master by setting a test bit of an access control register, then using a machine-code program to copy the ROM directly to text-mode screen memory.
The full text of the credit string in MOS 1.20 is as follows; no spaces occur after the commas to save memory:
"(C) 1981 Acorn Computers Ltd. Thanks are due to the following contributors to the development of the BBC Computer (among others too numerous to mention):- David Allen,Bob Austin,Ram Banerjee,Paul Bond, Allen Boothroyd, Cambridge,Cleartone, John Coll,John Cox,Andy Cripps, Chris Curry,6502 designers,Jeremy Dion,Tim Dobson,Joe Dunn,Paul Farrell, Ferranti, Steve Furber,Jon Gibbons,Andrew Gordon,Lawrence Hardwick,Dylan Harris, Hermann Hauser, Hitachi, Andy Hopper, ICL,Martin Jackson,Brian Jones,Chris Jordan,David King,David Kitson,Paul Kriwaczek, Computer Laboratory,Peter Miller, Arthur Norman,Glyn Phillips,Mike Prees,John Radcliffe,Wilberforce Road, Peter Robinson, Richard Russell,Kim Spence-Jones,Graham Tebby,Jon Thackray,Chris Turner,Adrian Warner, Roger Wilson,Alan Wright."
Reception.
In interviews in 1993 and 2001, Acorn cofounder Hermann Hauser recounted that Microsoft's Bill Gates, having noticed that 1.5 million BBC Micros were sold, tried to sell MS-DOS to Acorn, but Hauser considered that adopting MS-DOS would have been a "retrograde step" compared to retaining Acorn's system.


Virtual DMA Services

In computing, Virtual DMA Services (VDS) refer to an application programming interface that allow DOS and Win16 applications and device drivers to perform DMA operations while running under protected or virtual 8086 mode.


NASCAR 2000

NASCAR 2000 is a racing simulator video game developed and published by EA Sports and co-developed by Stormfront Studios.
Publication history.
The game was released in 1999 for the Nintendo 64 and for the PlayStation and in 2000 for the PC and for the Game Boy Color. The game is based on the 1999 NASCAR Winston Cup Series, with Adam Petty's 1999 Busch Series car and several legends such as Richard Petty and Alan Kulwicki also included. The game, along with "NASCAR 98", is regarded as one of the best of EA Sports NASCAR series of video games. It was the last game for PC until "NASCAR Thunder 2003". This game was the fourth title of the series.
Reception.
IGN.com said for the PlayStation version: "As they say, fans of the genre are going to love this great new update. All else, stay away". They awarded this version a 7.0 (Good). For the PC version, IGN.com wrote: "Get ready ... there's a left turn coming up". They awarded this version a slightly higher score of 7.2 (Good). For the N64, IGN.com was less impressed: "Stock car racing might be redundant but a videogame shouldn't be". This version only scored a disappointing 6.5 (Okay). Finally, IGN.com reviewed this game one last time with the Game Boy color version: "Not for everybody (and probably shouldn't be for anybody), but THQ's NASCAR runs well on cheap gas". GBC version scored same as the PS version with a 7.0 (Good).
Doug Trueman reviewed the PlayStation version of the game for "Next Generation", rating it two stars out of five: "This would have been a terrific title several years ago, but now it looks and sounds incredibly dated".


Unix International

Unix International (UI) was an association created in 1988 to promote open standards, especially the Unix operating system. Its most notable members were AT&T and Sun Microsystems, and in fact the commonly accepted reason for its existence was as a counterbalance to the Open Software Foundation (OSF), itself created in response to AT&T's and Sun's Unix partnership of that time. UI and OSF thus represented the two sides of the Unix wars in the late 1980s and early 1990s.
In May 1993, the major members of both UI and OSF announced the Common Open Software Environment (COSE) initiative. This was followed by the merging of UI and OSF into a "new OSF" in March 1994, which in turn merged with X/Open in 1996, forming The Open Group.


Voodoo3

Voodoo3 was a series of computer gaming video cards manufactured and designed by 3dfx Interactive. It was the successor to the company's high-end Voodoo2 line and was based heavily upon the older Voodoo Banshee product. Voodoo3 was announced at COMDEX '98 and arrived on store shelves in early 1999. The Voodoo3 line was the first product manufactured by the combined STB Systems and 3dfx.
History.
The 'Avenger' graphics core was originally conceived immediately after Banshee. Due to mis-management by 3dfx, this caused the next-generation 'Rampage' project to suffer delays which would prove to be fatal to the entire company.
Avenger was pushed to the forefront as it offered a quicker time to market than the already delayed Rampage. Avenger was no more than the Banshee core with a second texture mapping unit (TMU) added - the same TMU which Banshee lost compared to Voodoo2. Avenger was thus merely a Voodoo2 with an integrated 128-bit 2D video accelerator and twice the clock speed.
Architecture and performance.
Much was made of Voodoo3 (christened 'Avenger') and its 16-bit color rendering limitation. This was in fact quite complex, as Voodoo3 operated to full 32-bit precision (8 bits per channel, 16.7M colours) in its texture mappers and pixel pipeline as opposed to previous products from 3dfx and other vendors, which had only worked in 16-bit precision.
To save framebuffer space, the Voodoo3's rendering output was dithered to 16 bit. This offered better quality than running in pure 16-bit mode. However, a controversy arose over what happened next.
The Voodoo3's RAMDAC, which took the rendered frame from the framebuffer and generated the display image, performed a 2x2 box or 4x1 line filter on the dithered image to almost reconstruct the original 24-bit color render. 3dfx claimed this to be '22-bit' equivalent quality. As such, Voodoo3's framebuffer was not representative of the final output, and therefore, screenshots did not accurately portray Voodoo3's display quality which was actually much closer to the 24-bit outputs of NVIDIA's RIVA TNT2 and ATI's Rage 128.
The internal organisation of Avenger was not complex. Pre-setup notably featured a guardband clipper (eventually part of hardware transformation and lighting) but the pixel pipeline was a conventional single-issue, dual-texture design almost identical to that featured on Voodoo2, but capable of working on 32-bit image data as opposed to Voodoo2's pure 16-bit output. Avenger's other remarkable features included the 128-bit GDI accelerator debuted in Banshee. This 2D engine led the Voodoo3 to be considered one of the more high-performance video cards of its generation.
The Voodoo3 2000, 3000 and 3500 differed mainly in clock frequencies (memory and core were synchronous). The clock rates were 143 MHz, 166 MHz and 183 MHz respectively. While this gave the 3000 and 3500 a notable theoretical advantage in multi-textured fillrate over its main rival, the TNT2 clocked at 125 MHz, the TNT2 had nearly twice the single-textured fillrate of the Voodoo3. In addition, the Voodoo3 consisted of one multi-texturing pipeline, the TNT series consisted of twin single texturing pipelines. As a result, Voodoo3 was disadvantaged in games not using multiple texturing. The 2000 and 3000 boards generally differed in their support for TV output; the 3500 boards also carried a TV tuner and provided a wide range of video inputs and outputs.
At the time modern multi-texturing games such as "Quake III Arena" and "Unreal Tournament" were considered Voodoo3's performance territory, as Voodoo3's primary competition upon release was the dated RIVA TNT. NVIDIA's RIVA TNT2 arrived shortly thereafter and the two traded places frequently in benchmark results.
Although the Voodoo3 was a replacement for the Voodoo2, it was often beaten by Voodoo2 SLI cards in direct comparisons.
Voodoo3 remained performance competitive throughout its life, eventually being comprehensively outclassed by NVIDIA's GeForce 256 and ATI's Radeon. 3dfx created the ill-fated Voodoo 5 to counter.
3dfx Velocity.
3dfx released a line of business / value-oriented cards based on the Voodoo3 Avenger chipset. With the purchase of STB Systems, 3dfx had acquired several popular brand names. The Velocity brand had appealed to OEM system builders for years, with boards such as the S3 Graphics ViRGE VX-based "STB Velocity 3D" and NVIDIA RIVA 128-based "Velocity 128" being used in many OEM systems from companies such as Gateway. The 3dfx Velocity boards came with only 8 MiB of RAM, compared to 16 MiB on a regular Voodoo3. In addition, one of the texture management units came disabled as well, making the board more like a Banshee. Enthusiasts discovered that it was possible to enable the disabled TMU with a simple registry alteration. The board's clock speed was set at 143 MHz, exactly the same as a Voodoo3 2000.
Drivers.
The last set of drivers officially released for the Voodoo 3 on Win9x was version 1.07.00. For Win2000 the latest version is 1.03.00. Dual monitor support with V1.1.3b for Mac OS 8 and 9. After 3dfx shut its doors 3rd party drivers for Windows 98/98SE, Windows 2000 and XP were developed by loyal 3dfx customers .
Models.
1 - 3Dfx Velocity cards only have 1 working TMU enabled on OpenGL and Glide games, but both TMUs working under DirectX games


System virtual machine

In computing, a system virtual machine is a virtual machine that provides a complete system platform and supports the execution of a complete operating system (OS). These usually emulate an existing architecture, and are built with the purpose of either providing a platform to run programs where the real hardware is not available for use (for example, executing on otherwise obsolete platforms), or of having multiple instances of virtual machines leading to more efficient use of computing resources, both in terms of energy consumption and cost effectiveness (known as hardware virtualization, the key to a cloud computing environment), or both. A VM was originally defined by Popek and Goldberg as "an efficient, isolated duplicate of a real machine".
System virtual machines.
System virtual machine advantages:
The main disadvantages of VMs are:
Multiple VMs running their own guest operating system are frequently engaged for server consolidation in order to avoid interference from separate VMs on the same actual machine platform.
The desire to run multiple operating systems was the initial motivation for virtual machines, so as to allow time-sharing among several single-tasking operating systems. In some respects, a system virtual machine can be considered a generalization of the concept of virtual memory that historically preceded it. IBM's CP/CMS, the first systems to allow full virtualization, implemented time sharing by providing each user with a single-user operating system, the CMS. Unlike virtual memory, a system virtual machine entitled the user to write privileged instructions in their code. This approach had certain advantages, such as adding input/output devices not allowed by the standard system.
As technology evolves virtual memory for purposes of virtualization, new systems of memory overcommitment may be applied to manage memory sharing among multiple virtual machines on one actual computer operating system. It may be possible to share "memory pages" that have identical contents among multiple virtual machines that run on the same physical machine, what may result in mapping them to the same physical page by a technique known as Kernel SamePage Merging. This is particularly useful for read-only pages, such as those that contain code segments; in particular, that would be the case for multiple virtual machines running the same or similar software, software libraries, web servers, middleware components, etc. The guest operating systems do not need to be compliant with the host hardware, thereby making it possible to run different operating systems on the same computer (e.g., Microsoft Windows, Linux, or previous versions of an operating system) to support future software.
The use of virtual machines to support separate guest operating systems is popular in regard to embedded systems. A typical use would be to run a real-time operating system simultaneously with a preferred complex operating system, such as Linux or Windows. Another use would be for novel and unproven software still in the developmental stage, so it runs inside a sandbox. Virtual machines have other advantages for operating system development, and may include improved debugging access and faster reboots.
Techniques.
Different virtualization techniques are used, based on the desired usage. "Native execution" is based on direct virtualization of the underlying raw hardware, thus it provides multiple "instances" of the same architecture a real machine is based on, capable of running complete operating systems. Some virtual machines can also emulate different architectures and allow execution of software applications and operating systems written for another CPU or architecture. Operating-system-level virtualization allows the resources of a computer to be partitioned via kernel's support for multiple isolated user space instances, which are usually called containers and may look and feel like real machines to the end users. Some computer architectures are capable of hardware-assisted virtualization, which enables efficient full virtualization by using virtualization-specific hardware capabilities, primarily from the host CPUs.
Virtualization of the underlying raw hardware (native execution).
This approach is described as full virtualization of the hardware, and can be implemented using a type 1 or type 2 hypervisor: a type 1 hypervisor runs directly on the hardware, and a type 2 hypervisor runs on another operating system, such as Linux or Windows. Each virtual machine can run any operating system supported by the underlying hardware. Users can thus run two or more different "guest" operating systems simultaneously, in separate "private" virtual computers.
The pioneer system using this concept was IBM's CP-40, the first (1967) version of IBM's CP/CMS (1967–1972) and the precursor to IBM's VM family (1972–present). With the VM architecture, most users run a relatively simple interactive computing single-user operating system, CMS, as a "guest" on top of the VM control program (VM-CP). This approach kept the CMS design simple, as if it were running alone; the control program quietly provides multitasking and resource management services "behind the scenes". In addition to CMS communication and other system tasks are performed by multitasking VMs (RSCS, GCS, TCP/IP, UNIX), and users can run any of the other IBM operating systems, such as MVS, even a new CP itself or now z/OS. Even the simple CMS could be run in a threaded environment (LISTSERV, TRICKLE). z/VM is the current version of VM, and is used to support hundreds or thousands of virtual machines on a given mainframe. Some installations use Linux on IBM Z to run Web servers, where Linux runs as the operating system within many virtual machines.
Full virtualization is particularly helpful in operating system development, when experimental new code can be run at the same time as older, more stable, versions, each in a separate virtual machine. The process can even be recursive: IBM debugged new versions of its virtual machine operating system, VM, in a virtual machine running under an older version of VM, and even used this technique to simulate new hardware.
The standard x86 instruction set architecture as used in the modern PCs does not actually meet the Popek and Goldberg virtualization requirements. Notably, there is no execution mode where all sensitive machine instructions always trap, which would allow per-instruction virtualization.
Despite these limitations, several software packages have managed to provide virtualization on the x86 architecture, even though dynamic recompilation of privileged code, as first implemented by VMware, incurs some performance overhead as compared to a VM running on a natively virtualizable architecture such as the IBM System/370 or Motorola MC68020. By now, several other software packages such as Virtual PC, VirtualBox, Parallels Workstation and Virtual Iron manage to implement virtualization on x86 hardware.
Intel and AMD have introduced features to their x86 processors to enable virtualization in hardware.
As well as virtualization of the resources of a single machine, multiple independent nodes in a cluster can be combined and accessed as a single virtual NUMA machine.
Emulation of a non-native system.
Virtual machines can also perform the role of an emulator, allowing software applications and operating systems written for another computer processor architecture to be run.
Operating-system-level virtualization.
Operating-system-level virtualization is a server virtualization technology which virtualizes servers on an operating system (kernel) layer. It can be thought of as partitioning: a single physical server is sliced into multiple small partitions (otherwise called virtual environments (VE), virtual private servers (VPS), guests, zones, etc.); each such partition looks and feels like a real server, from the point of view of its users.
For example, Solaris Zones supports multiple guest operating systems running under the same operating system such as Solaris 10. Guest operating systems can use the same kernel level with the same operating system version, or can be a separate copy of the operating system with a different kernel version using Solaris Kernel Zones. Solaris native Zones also requires that the host operating system is a version of Solaris; other operating systems from other manufacturers are not supported. However, Solaris Branded Zones would need to be used to have other operating systems as zones.
Another example is System Workload Partitions (WPARs), introduced in version 6.1 of the IBM AIX operating system. System WPARs are software partitions running under one instance of the global AIX OS environment.
The operating system level architecture has low overhead that helps to maximize efficient use of server resources. The virtualization introduces only a negligible overhead and allows running hundreds of virtual private servers on a single physical server. In contrast, approaches such as full virtualization (like VMware) and paravirtualization (like Xen or UML) cannot achieve such level of density, due to overhead of running multiple kernels. From the other side, operating system-level virtualization does not allow running different operating systems (i.e., different kernels), although different libraries, distributions, etc. are possible. Different virtualization techniques are used, based on the desired usage. Native execution is based on direct virtualization of the underlying raw hardware, thus it provides multiple "instances" of the same architecture a real machine is based on, capable of running complete operating systems. Some virtual machines can also emulate different architectures and allow execution of software applications and operating systems written for another CPU or architecture. Operating-system-level virtualization allows the resources of a computer to be partitioned via kernel's support for multiple isolated user space instances, which are usually called containers and may look and feel like real machines to the end users. Some computer architectures are capable of hardware-assisted virtualization, which enables efficient full virtualization by using virtualization-specific hardware capabilities, primarily from the host CPUs.
Virtualization-enabled hardware.
Examples of virtualization-enabled hardware include the following:


List of AMD Turion microprocessors

Turion 64 is the name of a family of CPUs designed by AMD for the mobile computing market.


Larswm

larswm is a window manager for the X window system that follows the tiling window manager paradigm. Using ideas from the older 9wm window manager, it features automatic tiling and virtual desktops. It also borrows other ideas, for example a limited form of plumbing, from the Acme development environment. Objects are tiled into non-overlapping areas, instead of using windows that can be stacked, as this approach can result in lower memory and CPU requirements.


Bratz (video game)

Bratz is a 2002 video game based on the Bratz doll line.
Gameplay.
In the game, the player must dance through each level using platform-specific controls. Each completed level unlocks new fashions, dance moves to use in the "freestyle" mode, and the next level. At the end of the game, the player unlocks a bonus level. There are 5 different bonus levels, each one specific to the five Bratz girls available to play (Yasmin, Cloe, Sasha, Jade, or Meygan).


4NT (shell)


Intel Dynamic Acceleration

Intel Dynamic Acceleration (IDA) sometimes called Dynamic Acceleration Technology (DAT) is a technology created by Intel Corp. in certain multi-core Intel microprocessors. It increases the clock rate of a single core for every two cores above its base operating frequency if the other cores are idle. It is designed for single threaded programs to run faster on multi-core Intel microprocessors. Intel later released a version of IDA called enhanced Dynamic Acceleration Technology (eDAT) for its quad core processors that boosts the performance of 2 cores when only 2 cores are being utilized.
History.
Intel Dynamic Acceleration was first released with the Core 2 Duo mobile processor line, as new microprocessor lines were released, Intel changed the technology and naming scheme slightly.
Dual Dynamic Acceleration.
With the introduction of quad core processors, Intel modified IDA and released "Dual Dynamic Acceleration" ("DDA").
Intel Turbo Boost.
The later released Nehalem microarchitecture of Intel microprocessors made additional changes to the original IDA and released an improved version called "Intel Turbo Boost".


ASSIGN (command)


List of tools to create Live USB systems

This is a list of utilities for creating Live USB. Only those listed on Wikipedia are included.
Overview.
Multiboot means that the tool allows multiple systems on the USB stick, as well as a bootloader on the USB flash drive to choose which system to load at boot time.


PATH (command)


CMDXSWP.COM


Link (Unix)

The link utility is a Unix command line program that creates a hard link from an existing directory entry to a new directory entry. It does no more than call the "link()" system function. It does not perform error checking before attempting to create the link. It returns an exit status that indicates whether the link was created (0 if successful, >0 if an error occurred). Creating a link to a directory entry that is itself a directory requires elevated privileges.
The "ln" command is more commonly used as it provides more features: it can create both hard links and symbolic links, and has error checking.
Synopsis.
link (-s) source target
Note that source must specify an existing folder or file, and target must specify a non-existent entry in an existing directory.
Standards.
The link command is part of the Single UNIX Specification (SUS), specified in the "Shell and Utilities" volume of the IEEE 1003.1-2001 standard.


Ubuntu Budgie

Ubuntu Budgie is an official community flavor of Ubuntu featuring the Budgie desktop. It combines the stable and thoroughly-tested Ubuntu core with a modern, lightweight and traditional-looking desktop developed by the Solus project.
The latest release is 21.04, released on April 22, 2021.
History.
Ubuntu Budgie started out as an unofficial community flavor in parallel with Ubuntu 16.04 LTS, referred to as budgie-remix. Budgie-remix 16.10 was later released by strictly following the time frame issued for Ubuntu 16.10.
It was eventually recognized as an official community flavor of Ubuntu, and was rebranded as Ubuntu Budgie.
Vincenzo Bovino was hired as the new brand and PR Manager.
Ubuntu Budgie 17.04 was released in April 2017, and was updated to version 17.10 in October 2017.
In Ubuntu Budgie 18.10, 32-bit support has been dropped. 32-bit support has also been dropped in Ubuntu MATE.
Releases.
budgie-remix 16.04.
budgie-remix 16.04 was released on April 25, 2016, four days after the release of Ubuntu 16.04.
The system contains Budgie Desktop 10.2.5. Has a window manager based on Mutter, a customizable panel, notification center settings. The Arc-GTK+ theme is used. Compared to Ubuntu 16.04, budgie-remix has Nautilus version 3.18, as at that time Ubuntu had a version of Nautilus 3.14. Also has a dock-panel Plank version 0.11.1, gedit version 3.18, GNOME 3.18 photos, gThumb 3.4.3, Rhythmbox 3.3, Totem 3.18, GNOME Terminal 3.18, LibreOffice 5.1.2, Mozilla Firefox 45.0, Transmission 2.84, GTK+ 3.18.9, Mesa 11.2.0, XOrg 1.18.3 and the Linux kernel 4.4.0.
budgie-remix 16.10.
budgie-remix 16.10 was released on October 16, 2016, three days after the release of Ubuntu 16.10.
The system contains a shell Budgie Desktop 10.2.7, GTK+ 3.22, the Linux kernel 4.8. There are many new features implemented in this version, such as full disk encryption, home folder encryption, and support for multiple languages during installation. Has the theme of design Arc GTK+, a new theme icons Pocillo.
One of the developers of budgie-remix, David Mohammed, says:
Ubuntu Budgie 17.04.
Ubuntu Budgie 17.04 was released on April 19, 2017. budgie-remix was renamed to this name after the distribution became official for the Ubuntu community.
The system contains the Budgie Desktop 10.2.9 shell, the Linux 4.10 kernel, Mesa 17.0.3, Xorg 1.19.3. Budgie-Welcome application was updated, support for application indicator appeared, sound applets were managed, GNOME 3.24 applications were enabled, GNOME Terminal was replaced with Termix and Chromium replaced Google Chrome , and GTK+ theme support for Qt was enabled. Use the theme of the design Arc GTK+, the theme of the icons Moka.
In the record about the release of this version, it was written as follows:
Ubuntu Budgie 17.10.
Ubuntu Budgie 17.10 was released on October 19, 2017.
The system contains the Budgie Desktop 10.4 shell, the Linux 4.13 kernel. The Budgie 10.4 desktop environment is equipped with a set of native features that include a new stylish Alt-Tab, support for Spotify in Raven, support for switching window controls to the left or right, support for SMB files and encrypted volumes through the addition of applets and supports customizing the appearance of dates and times. In addition, there is support for left or right side panels in Budgie Desktop 10.4, support for converting panels in the dock, transparency and dynamic auto-image for all panels, and the ability to replenish the bottom panel to work without a terrible "jump" effect. Other noteworthy improvements in the release of Ubuntu Budgie 17.10 include Night Light and Caffeine tools, Tilix as the default terminal emulator instead of Termix, as well as support for Tilix Quake mode with the F12 key, updated panel icons and new wallpapers.
On December 20, 2017, Canonical withdrew the Ubuntu 17.10 distribution in October and hid the link on the site for downloading. The reason was a critical bug with BIOS damage on some Lenovo notebook models and one Acer model.
On January 12, 2018, version 17.10.1 was released, which contained the correction of a serious problem in version 17.10.
Ubuntu Budgie 18.04.
Ubuntu Budgie was released on April 26, 2018.
The system includes the Linux 4.15 kernel. It became possible to install OpenVNC through network-manager. New applets have appeared, such as Quick Note for notes, DropBy for downloading and viewing data from USB devices, Hot Corners for moving windows to the corner of the screen, Windowpreviews for viewing open windows, Clockworks for viewing some time zones, Autoswitch for tying the keyboard layout to the application, Window Mover in order to quickly move the window to another virtual desktop. All GNOME applications have been updated to version 3.28, but Nautilus has version 3.26.


Direct Machine Environment


Lode Runner 3-D

Lode Runner 3-D is a Nintendo 64 game in the "Lode Runner" franchise. The game was developed by Big Bang and was released in 1999 in North America and Europe by Infogrames and in Japan by Banpresto. It is the first 3D game in the "Lode Runner" series.
Gameplay.
The game mechanics are similar to the original: the players outrun enemies by using alternate routes, sliding on ropes, climbing ladders, or drilling holes in the ground to trap them. This game differs from the other incarnations of games from the series because of its apparent three-dimensional perspective. While essentially running in 2-dimensional space, the player has an option to move in another direction every so often. The levels are mostly spirals that require climbing to complete. There are five worlds, and each one must be unlocked by finding five cards from the previous world, excluding the first. Each world is divided into five stages, with each stage divided into four levels. The general goal of each level is to collect a certain amount of gold to activate a portal that allows the player to continue. As the player progresses, each world adds new interactive objects and tools, as well as new obstacles.
Plot.
Set after Jake Peril's adventures, he has been living an relatively peaceful life in his home planet with his wife Jane Peril until The Mad Monk Emperor of Planet Pandora has finally revealed himself, the Emperor has stolen all the gold resources of the planet earth so its up again for Jake Peril defeat the Mad Monks and finally their Leader once and for all.
Reception.
The game received average to positive reviews. IGN gave it a 7 out of 10 praising it for taking the original concept and putting it into a new format that enhances the experience. GameSpot noted that the game was slower and harder than previous entries in the franchise.


List of video game console palettes

This is a full list of color palettes for notable video game console hardware.
For each unique palette, an image color test chart and sample image (original True color version follows) rendered with that palette (without dithering unless otherwise noted) are given. The test chart shows the full 8-bit, 256 levels of the red, green and blue (RGB) primary colors and cyan, magenta and yellow complementary colors, along with a full 8-bit, 256 levels grayscale. Gradients of intermediate colors (orange, yellow-green, green-cyan, blue-cyan, violet and red-magenta), and a full hue spectrum are also present. Color charts are not gamma corrected.
Atari.
Atari 2600.
The Atari 2600 used different YIQ color palettes dependent on the television signal format used.
NTSC.
With the NTSC format, a 128-color palette was available, built based on eight luminance values and 15 combinations of I and Q chroma signals (plus I = Q = 0 for a pure grayscale):
The above image assumes there is no limit on the number of colors per scan line. With the system's actual color restrictions (and proper change in aspect ratio), the same image would look very different:
PAL.
With the PAL format, a 104-color palette was available. 128-color entries could still be selected, but due to the different color encoding scheme, 32 color entries results in the same eight shades of gray:
The above image assumes there is no limit on the number of colors per scanline. With the system's actual color restrictions (and proper change in aspect ratio), the same image would look very different:
SECAM.
The SECAM palette was reduced to a simple 3-bit RGB, containing only 8 colors (black, blue, red, magenta, green, cyan, yellow and white) by mapping the hue to luminance and ignoring the hue setting:
Lynx.
The Lynx used a 4096-color palette.
Nintendo.
NES.
The Picture Processing Unit (PPU) was used in the Nintendo Entertainment System and generates composite NTSC video instead of RGB. The 56-color palette is built based on four luminance values and twelve combinations of I and Q chroma signals (plus two series of I = Q = 0 for several pure grays). There are two identical whites, one of the blacks has less-than-zero brightness, and one of the lighter grays is within 2% of another, so sometimes the palette has been reported to have 52 to 55 colors.
In addition to this, it had 3 color emphasis bits which can be used to dim the entire palette by any combination of red, green and blue. This extends the total available colors to 448, but inconveniently divided into 8 variations of the base 56. Because it affects the whole palette at once it may be considered more of a filter effect applied to the image, rather than an increased palette range.
The PPU produces colors outside of the RGB color gamut, resulting in some colors being presented differently on different screens.
The NES could select 4 palettes each containing four of these colors (however, color 0 of each palette has to be the same, so technically, 13 different colors are available at a time) to be applied to the background. A background palette is applied to a 16x16 pixel area, however through a special video mode of the MMC5 mapper it is possible for every 8x8 pixel tile to have its individual palette. As for sprites, 4 different palettes can be used at a time (with color 0 being transparent in each) and every 8x8 or 8x16 pixels can have their own palette, allowing for a total of 12 different colors to use for sprites at any given time.
Because of the constraints mentioned above, converting a photograph often results in attribute clash. Conversions with and without dithering follow, using the hex palette codice_1:
Game Boy.
The original Game Boy uses a monochrome 4-shade palette. Because the non-backlit LCD display background is greenish, this results in a "greenscale" graphic display, as it is shown in the simulated image (at Game Boy display resolution), below. The Game Boy Pocket uses a monochrome 4-shade palette using actual gray.
Super NES.
The Picture Processing Unit (PPU) used in the Super NES has a 15-bit RGB (32,768 color) palette, with up to 256 simultaneous colors at once.
However, while the hardware palette can only contain 256 entries, in most display modes the graphics are arranged into between 2 and 4 layers, and these layers can be combined using additive or subtractive color blending.
Because these blended colors are calculated by the hardware itself, and do not have to be represented by any of the existing palette entries, the actual number of visible colors onscreen at any one time can be much higher.
The exact number depends on the number of layers, and the combination of colors used by these layers, as well as what blending mode and graphical effects are in use. In theory it can show the entire 32,768 colors, but in practice this is rarely the case for reasons such as memory use. Most games use 256-color mode, with 15-color palettes assigned to 8x8 pixel areas of the background.
Game Boy Color.
The Game Boy Color systems use a 15-bit RGB (32,768 colors) palette.
The specific Game Boy Color (Type 3) game cartridges presents up to 56 colors without the use of special programming techniques from the full 32,768. From these, 32 are for a background palette, plus 8 hardware sprite palettes, with 3 colors plus transparent each. Typically sprite palettes share some colors (black, white or others), so the total colors displayed may be less than 56.
Though there is a 56 color limit, this in of itself is a palette storage limit and not an actual hardware limitation. As such, the programmer can swap out the palettes on a per-scanline basis. Because of this ability to swap out the palettes each scanline, over eight thousand colors can actually appear on screen per frame when programmed on a per-scanline basis.
When an older monochrome original Game Boy game cartridge (Type 1) is plugged-in, if certain combinations of the controls are held during startup (or if the game is recognized from a hard-coded list in the device's ROM), the games are colorized with one of the factory 12 false color palettes. In this mode, games can have from 4 to 10 colors, due 4 are for the background plane palette and there are two more hardware sprite planes palettes, with 3 colors plus transparent each.
The following shows these startup palettes (background plus both sprite planes) and the combination of controls used (the names are taken from the Game Boy user's manual; the colors are simulated):
Game Boy Advance.
The Game Boy Advance/SP/Micro systems also uses a 15-bit RGB palette, and along with the original and Color modes, they have also a specific Highcolor 32,768 colors mode. The LCD displays of the Micro and some models of the SP are backlit, giving brighter images.
DS.
The DS has an 18-bit RGB color palette, making a total of 262,144 possible colors; of these, 32,767 simultaneous colors can be displayed at once.
3DS.
The 3DS has a 24-bit RGB color palette (16 million colors).
Sega.
Master System.
The Master System had a 6-bit RGB palette (64 colors), with 31 colors on-screen at once. It is possible to display all 64 colors at once using raster effects (line interrupts).
There are only 512 different 8x8 tile patterns to cover the screen though, when 768 would be required for a complete 256x192 screen. This means that at least 1/3 of the tiles will have to be repeated. To help maximize tile reuse, they can be flipped either vertically or horizontally. The 64 sprites of 8x16 pixels can also be used to help to cover the screen (max 8 per scanline).
Because of the constraints mentioned above, there are no current accurate simulated screen images available for the Sega Master System.
Mega Drive/Genesis.
The Mega Drive/Genesis used a 9-bit RGB palette (512 colors, up to approximately 1500 including shadow and highlight mode) with up to 61 colors on-screen at once without raster effects (4 palette lines of 16 colors each, palette indices $x0 are definable but considered as transparent, and can only be used as the background color).
Game Gear.
The Game Gear had a 12-bit RGB palette (4096 colors), with 32 colors on-screen at once.
32X.
The Sega 32X had a 15-bit RGB palette (32768 colors), with all colors available for display.
NEC.
TurboGrafx-16.
The TurboGrafx-16 used a 9-bit RGB palette consisting of 512 colors with 482 colors on-screen at once (16 background palettes of 16 colors each, with at least 1 common color among all background palettes, and 16 sprite palettes of 15 colors each, plus transparent which is visible as the overscan area).


List of Intel Pentium Pro microprocessors

The Pentium Pro from Intel is the first of their sixth-generation CPUs targeted at the consumer and server markets. The processor was relatively unusual in that the Pentium Pro used a unique "on-package cache" arrangement; the processor and the cache were on separate dies in the same package and were connected closely by a full-speed bus. The dies had to be bonded together early in the production process, before testing was possible. This meant that a single, tiny flaw in either die made it necessary to discard the entire assembly, which was one of the reasons for the Pentium Pro's relatively low production yield and high cost.


MiniMAX


Nokia N80

The Nokia N80 is a 3G smartphone from Nokia announced on November 2, 2005, part of the multimedia Nseries line. It runs on Symbian OS v9.1 and the S60 3rd Edition interface. It was first released in June 2006.
It has support for high-speed UMTS/WCDMA connections. Features include a 3.1-megapixel camera (interpolated from 2.0-megapixels) with built-in flash, a front camera for videoconferencing, Wi-Fi (802.11g), Universal Plug and Play (UPnP), FM radio, Bluetooth 1.2, MiniSD memory card slot, and support for 3D Java games. Its 2.1-inch display has a pixel density of 259 ppi due to the 352x416 resolution on a 2.1" displaymaking it one of Nokia's sharpest displays of 2005 and 2006.
The N80 was the world's first UPnP-compatible phone, allowing the transfer of media files to compatible devices over Wi-Fi. The N80 was officially described as a "multimedia computer" by Nokia, like its successor Nokia N95.
Versions.
Bluetooth.
Nokia originally announced the N80 as supporting Bluetooth 2.0, however it was released with Bluetooth 1.2. Therefore, the N80 does not currently support stereo playback over Bluetooth.
Internet Edition.
The Nokia N80 Internet Edition was a second version of this handset with the same hardware as the normal N80. It has been released in Q4 of 2006 and is available in Patina Bronze or Pearl Black, and has the following additional software included. As of January 2007, the Pearl Black model was available for sale in the US for $499.
Nokia have now announced that the new Internet Edition firmware is available for the 'classic' N80 by using Nokia Official Software Updater, downloadable from Nokia.com.
Before the Internet Edition firmware was made available on the Nokia Software Updater, end users could update the N80 to the same specification as an N80 Internet Edition by flashing the N80 with the firmware from the N80 Internet Edition. This required the use of several hacked Nokia servicing software applications, including the Phoenix Service Software (or Nokia Software Update with Nemesis (by changing product code)). This method is of questionable legality in some jurisdictions, and may violate the terms of the phone's warranty. There are reports of the occasional failure of this method due to user error or for other unknown reasons, leaving the phone in an unusable state from which only a properly-equipped service center could recover it.


Xito

Xito is a Java based portable desktop environment. It claims to be committed to creating and developing an open-source desktop that will "introduce a new level of functionality and usability to internet based software applications." Since Java has large performance and space requirements the Xito desktop environment is currently trying to address these problems.
Xito también es un nombre griego que entre otras cosas significa: virtud, lealtad, belleza extrema, heroísmo, liderismo, otra vez belleza extrema, inteligencia infinita, nobleza y pureza.


List of best-selling Sega Genesis games

This is a list of Sega Genesis/Mega Drive video games that have sold or shipped at least one million copies, sorted in order of copies sold. The best-selling title is "Sonic the Hedgehog", first released in North America on June 23, 1991. Due to being bundled with the console, it sold 15 million copies. The second best-selling game is its sequel, 1992's "Sonic the Hedgehog 2", with 6 million copies sold.


Multi-booting

Multi-booting is the act of installing multiple operating systems on a single computer, and being able to choose which one to boot. The term dual-booting refers to the common configuration of specifically two operating systems. Multi-booting may require a custom boot loader.
Usage.
Multi-booting allows more than one operating system to reside on one computer; for example, if you have a primary operating system and an alternate system that you use less frequently. Another reason for multi-booting can be to investigate or test a new operating system without switching completely. Multi-booting allows a new operating system to configure all applications needed and migrate data before removing the old operating system, if desired. A possible alternative to multi-booting is virtualization, where a hypervisor is used to host one or more virtual machines running guest operating systems. Multi-booting is also useful in situations where different software require different operating systems. A multi-boot configuration allows a user to use all of this software on one computer. This is often accomplished by using a boot loader such as NTLDR, LILO, or GRUB which can boot more than one operating system. Multi-booting is also used by software developers when multiple operating systems are required for development or testing purposes. Having these systems on one machine is a way to reduce hardware costs.
Technical issues.
Number of operating systems per volume (logical drive).
In an OS/2 dual boot configuration, the C drive can contain both DOS and OS/2. The user issues the BOOT command from the DOS or OS/2 command line to do the necessary copy, move and rename operations and then reboot to the specified system on C:. Other systems provide similar mechanisms for alternate systems on the same logical drive.
Number of operating systems per storage device.
In a multi-boot computer each of the multiple operating systems can reside on its own storage device, or some storage devices might contain more than one operating system in different partitions. The boot loader in or loaded by the MBR displays a menu of logical drives and loads the selected boot loader from the PBR of that drive.
An example of a computer with one operating system per storage device is a dual-booting computer that stores Windows on one disk drive and Linux on another disk drive. In this case a multi-booting boot loader is not strictly necessary because the user can choose to enter BIOS configuration immediately after power-up and make the desired drive first in the boot-order list. However, it is more convenient to have a multi-booting boot loader on one of the drives, set BIOS once to always start booting from (i.e. load the boot loader from) that drive, and then allow the user to choose an operating system from that boot loader's menu. No special disk partitioning is necessary when each operating system has its own dedicated disk drive.
An example of a computer with multiple operating systems per storage device is a dual-booting computer that stores both Windows and Linux on the same disk drive but where the bios in the system does not let the user boot individual drives and partitions. In this case a multi-booting boot loader "is" necessary. Also, the disk must be partitioned to give each operating system its own partition on the disk drive. This is necessary because each system has its own set of files and operating instructions. Also, when a completely separate operating system is used partitions may need to be formatted to a different format. For example, if you intend to install Windows and Linux, the Windows partition will be most likely formatted in the NTFS format and Linux Partition will most likely be formatted in the ext4 file format as Windows can't run off of ext4 and Linux can't run on NTFS. However, for example if a user intends to dual boot two versions of Windows (i.e. Windows 7 and Windows Vista) or two versions of Linux (i.e. Linux Mint and Ubuntu Linux), the same file system (e.g. NTFS or ext4) can be used across both drives and partitions.
Partitioning.
The basic concept involves partitioning a disk to accommodate each planned installation, usually including separate partitions for boot, root, data storage and backups.
Windows XP and 2000.
Windows Vista's partitioners may not be compatible with XP and 2000 (see Logical disk manager#Compatibility problems). If you use Windows 2000 and XP, probably the safest approach (for disks under 2 TiB) is to use a CHS partition table alignment that is chosen by Windows XP/2000 (not Vista or Windows 7). If starting with a disk with nothing important on it, delete all partitions, unplug the disk or reboot, create at least one partition with Windows XP/2000 Disk Management or the XP/2000 installer, and format all FAT partitions. The alignment can be checked with Ranish Partition Manager: All partitions (including Extended Boot Record [EBR] extended partitions—type 05) should start at the beginning of a head, and end at the end of a cylinder. If nothing is shown in red (with error messages when you highlight them) you probably have a disk with a standard CHS partition table alignment. If you wish to edit the partition table with Linux, first run sfdisk with "--show-geometry" and "--show-pt-geometry". If these return the same geometry, it should be safe to use GParted, so long as it is set to round to cylinders, and you only add partitions to the end of the partition table. If you add a partition to the middle of the extended partition table, GParted will not put them in the order they are on the disk (so that hda7 will follow hda9 instead of hda6). The order can be fixed with a Linux fdisk advanced function. Most Linux partitioners that don't use parted, may not end EBR extended partitions (type 05) on the same sector as their logical drives. When GParted or parted edit these "nonstandard" partition tables, they will "fix" all these EBRs, so that the extended partitions end on the same sector as their logical drives. The partitioner then may show these partitions as having no "errors". This can also be checked using (for example) sfdisk -l -x -us /dev/hda.
MBR loader.
An MBR loader, such as Air-Boot, replaces the standard boot code in track 0 with code that displays a selection menu and loads the selected system. Some, e.g., Air-Boot, can be configured either automatically or by the user at boot time, rather than requiring an external configuration menu.
Linux boot loaders.
Linux loaders such as GRUB and LILO, can reside in the MBR or in a PBR. They use configuration files in /boot to control their selection menus,
OS/2 Boot Manager.
The OS/2 Boot Manager must be installed in a primary partition. Tho OS/2 partitioning utilities can configure up to four systems in the menu, each of which can be either in a primary partition or in a logical volume within the extended logical partition. Newer loaders such as Air-Boot, GRUB and LILO offer more flexibility.
Windows and Linux.
One popular multi-boot configuration is to dual-boot Linux and Windows operating systems, each contained within its own partition. Windows does not facilitate or support multi-boot systems, other than allowing for partition-specific installations, and no choice of boot loader is offered. However, most current Linux installers accommodate dual-booting (although some knowledge of partitions is desirable). Commonly installations proceed without incident but upon restart, the boot loader will recognize only one of the two operating systems.
There are some advantages to installing a Linux boot manager/loader (usually GRUB) as the primary bootloader pointed to by the master boot record. Windows operating systems will be found by properly installed Linux bootloaders, but Windows boot managers do not recognize Linux installations (nor does Windows deal natively with Linux file systems). The MBR boot code can be backed up and restored with dd, available on System Rescue CD.
It is often recommended that Windows be installed to the first primary partition. The boot loaders of both Windows and Linux identify partitions with a number derived by counting the partitions. (Note, both Windows and Linux count the partitions according to the ordering of the partitions "in the partition table", which may be different from the order of the partitions on the disk.) Adding or deleting a partition at the end of a hard drive will have no effect on any partitions prior to it. However, if a partition is added or deleted at the beginning or middle of a hard drive, the numbering of subsequent partitions may change. If the number of the system partition changes, it requires boot loader reconfiguration in order for an operating system to boot and function properly.
Windows must be installed into a primary partition (and in older systems this must be the first partition). Linux can be installed into a partition in any position on the hard drive and can also be installed into logical partitions (within the extended partition). If Linux is installed into a logical partition within the extended partition, it is unaffected by changes in the primary partitions.
Neutral MBR.
An alternative to storing GRUB in the MBR is keeping Windows' or other generic PC boot code in the MBR, and installing GRUB or another bootloader into a primary partition other than that of Windows, thus keeping the MBR neutral. Operating system selection at boot time consequently depends on the bootloader configured within the primary partition that has the boot or "active" flag set on its partition table entry, which could be a bootloader of DOS, OS/2, eComStation, ArcaOS or BSD, in addition to Linux or Windows.
With the boot flag set on the Windows primary, the Windows Boot Manager can be used to chainload another installed bootloader by employing usage of a program like EasyBCD. This means the active partition's boot manager will first prompt the user for selection what OS to boot, then load another if necessary, such as GRUB, even a bootloader installed to a logical partition, and then GRUB will load the Linux kernel as it normally would were GRUB installed to the MBR.
The active partition could also be one that exists for no purpose other than choosing an operating system to boot, such as the Boot Manager that shipped with IBM's OS/2 Warp and its derivatives.
Apple Boot Camp.
Boot Camp allows owners of Intel-based Apple Macintosh computers to install Windows XP, Vista, 7, 8, and 10 on their Macs. The software comes bundled with Mac OS X since version 10.5 (Leopard). Previously the application was available in beta version as a download from Apple's website.
Boot Camp allows non-destructive disk partitioning and resizing of HFS+ filesystems, boot menu options, and an option to burn a CD with necessary device drivers. Since Windows XP is incompatible with Extensible Firmware Interface (the successor to legacy BIOS), the firmware on early Intel Macs needs to be updated to support BIOS emulation first. BIOS emulation is achieved with a compatibility support module (CSM). Apple does not support non-Windows partition formats or drivers so therefore configuring other operating systems is not directly possible through Boot Camp itself. However, any operating system which can utilize the BIOS emulation of Intel Macintosh can be made to work, including non-XP versions of Windows. The Ubuntu Linux distribution is particularly popular for this purpose because they provide an option to use proprietary device drivers along with open source drivers.


Athlon II

Athlon II is a family of AMD multi-core 45 nm central processing units, which is aimed at the budget to mid-range market and is a complementary product lineup to the Phenom II.
Features.
The Athlon II series is based on the AMD K10 architecture and derived from the Phenom II series. However, unlike its Phenom siblings, it does not contain any L3 Cache. There are two principal Athlon II dies: the dual-core Regor die with 1 MB L2 Cache per core and the four-core Propus with 512 KB per core. Regor is a native dual-core design with lower TDP and additional L2 to offset the removal of L3 cache. The Athlon II x2 200e-220 chips have less L2 cache than the rest of the Regor line. The triple-core "Rana" is derived from the Propus quad-core design, with one core disabled. In some cases, the Phenom II Deneb die is used with disabled L3 cache and cores in the case.
Includes: AMD Direct Connect Architecture
AMD Wide Floating Point Accelerator
AMD Digital Media XPress 2.0 Technology
AMD PowerNow! Technology (Cool’n’Quiet Technology)
HyperTransport Technology (not the same as Intel Hyper-Threading Technology)
Processors with an "e" following the model number (e.g., 245e) are low-power models, typically 45W for Athlons, 65W for Phenoms. Processors with a "u" following the model number (e.g., 250u) are ultra-low voltage models.


OpenVME


Kurumin

Kurumin Linux was a Live CD operating system based on Debian. Its main features are the advanced hardware auto-detection (inherited from Knoppix) and a Portuguese user interface, and its main goal is ease of use. As of release 7.0, the size of the disk image is approximately 603 MB.
Version NG 8.06, based on Ubuntu 8.04, was released June 24, 2008, and was discontinued on January 29, 2009.
Name origin and history.
The name comes from the Tupi word "curumim", which means boy. The usage of the letter K, instead of the usual Portuguese spelling ("curumi" or "curumim"), brings it in line with KDE (Kurumin's default desktop environment), as well as with Knoppix.
In late 2007, Morimoto said, that the project would be halted or have its scope reduced. In November 2008, the project was officially discontinued.
Features.
The distribution sports an open-source control center named "ClicaAki" (roughly: "ClickHere"). It features a series of shell scripts, Kommander-based panels, and "magic icons" that install software not included on the live CD, and with which icons one can configure a wide range of networking options. The control center also provides access to the Synaptic package manager.
The ClicaAki control panel has shortcuts to scripts that also perform tasks like downloading and installing free games, with apps divided into categories and a short description of how they work and their differences.
Hardware support.
The control panel also includes scripts for downloading and automatically configuring drivers for 3D video cards (ATI and Nvidia), a difficult task for novice users.
Another feature of the distro is, that it has support for many "winmodems", including some that have no official packages or drivers in the Debian repository, and also with scripts that automate the tasks of compiling and configuring the necessary modules.
With these features, Kurumin has spread the GNU/Linux operating system in Brazil in a level never seen before.