CoLinux is short for Cooperative Linux, a port of LinuxOperatingSystem, which needs a Windows partition to run on. *one of several different ways of creating a VirtualComputer *Cooperates with windows. ''i.e.'' a Linux kernel runs inside MicrosoftWindows, with all the files in the Windows partition. *is ''not'' like VmWare, VirtualNetworkComputing(VNC), FreeNx, although the last two can be used to connect a CoLinux instance back to the host computer system. *is fast. somewhat of an emulator, but more of a kernel, since it is a dedicated Linux on windows - ''unlike'' generic emulators: Bochs. *installs an actually linux distro onto windows *the distro is part of one giant file. The giant file is the partition, which holds the distro and all the files on the partition. *Does not rely on cygwin. It is a stand alone solution. However, to get an x-window system working one might have to use cygwin or other x-11 servers on windows. *Using VirtualNetworkComputing (VNC) it is possible to see both Windows apps and an X window at the same time and transfer edit information. *CoLinux provides the base code for AndLinux which integrates Ubuntu Linux into Windows. * http://www.colinux.org/ * http://linux.sys-con.com/read/44466_p.htm ---- It's like UserModeLinux where the host OS is Windows. If all you want is just to run Linux and Windows at the same time, this one seems like a good candidate over Bochs (in term of ease of getting up and running) or VMWare (in term of price). ''Can anyone tell me what are the key features that make these UML and CoLinux possible? I mean what characteristic in Linux kernel made it possible to make this. Call me ignorant but I haven't found any UserModeBSD, CoBSD or any other of these in other OS?'' This is answered in the overview on the front page of http://www.colinux.org/, and in more detail than I would have expected from a front page overview, but the fact that it's a pretty complete answer may not be obvious to non-kernel programmers. CoLinux is just a Windows process, running in privileged mode so that it is allowed to muck with the MMU and such. It uses a specially crafted Windows device driver to assist it in sharing the machine with Windows. This technique doesn't rely on any special features of Linux, potentially one might be able to run any operating system under Windows in the same way. However, as a matter of practicality, it certainly helps that Linux is open source, obviously, and that it has been ported to dozens of different systems/cpus and has been previously hacked to run as a user mode process under Linux, etc etc. All of those past changes have polished off various rough edges that would otherwise make it more of a pain to do what CoLinux is doing. Or maybe the intended question was simpler, e.g. why isn't there a user mode BSD? No particular reason. One could be created. No one has bothered to. I could hack up BSD to get it running in user mode; it's just a Simple Matter Of Programming. The devil is in the details with this sort of thing; whether it would be fairly simple or a big pain depends on the degree to which each of the kernel subsystems has previously been virtualized. If one of them, like memory management, has not been virtualized, then each port to a new environment typically requires conditional compilation of special purpose code (e.g. to deal with the unique characteristics of one particular CPU's MMU). If it has been virtualized, on the other hand, then all of the logic that is common to all MMUs has been separated out into a high level layer, and only a tiny amount of device-specific code needs to be written for each new port, and that low level device specific code uses the same API, and things have been set up to make it trivially easy to switch from one to another. All of that sort of thing has long since been done, improved, redone over several design generations in Linux, so it's gotten to the point where most things are nicely virtual and it's easy to port it to a radically different environment, like user mode. I haven't been tracking the BSDs much so I can't comment on how much easier or harder it would be to do with those kernels. One of the cool things about Linux is that so many projects like this happen to have already been done, in no small part because of the mind share Linux has. -- DougMerritt ---- Bear in mind that coLinux has to share the memory of the computer with Windows, so that neither coLinux nor Windows has as much memory as when they have the computer to themselves. For example, if not enough memory is assigned to coLinux, operations such as compilation can get very slow as the swap file gets used instead of memory. coLinux gets a fixed memory allocation when it starts up. -- JohnFletcher ''I find that Samba greatly adds to the slowness when used in combination with a compiler on CoLinux. Compiling is not so great to do over a network, but in my case I like to have the files on a Windows machine and see them from the CoLinux machine (while also having vice versa setup, to make it easy to see and transfer files on both Windows and CoLinux). I may have even created a recursive loop, but it works.. it is just slow at times. Upgrading my memory and bumping up the CoLinux memory really helped, but I still get this severe slowness at times (it is not consistent, it varies how slow it is even if I have free memory, must be a funny Samba issue over TCP/IP re-initiating the connection).'' ---- See also: VirtualBox, BochsEmulator, VmWare, KernelBasedVirtualMachine, AndLinux (which uses CoLinux) ---- CategoryLinux CategoryVirtualComputer