| The EmulateMe page: how to
"execute" "alien" programs. |
| Paragraphs in this page are: Case Solution(s) Projects Other Ways Notes on Wine Cygwin coLinux Dosbox ScummVM and VirtualBox The real thing - screenshots here! |
Solution(s): To run an application designed for a different platform there are two ways in general:
In the first case, the processor runs everything "native" and the needed services are supplied by the different OS as an Api (Application Program Interface) layer. In the second case, an entire platform, Hardware AND/OR Operating System is virtually constructed. Virtualization offers slices of the present hardware, while emulation is more relevant to entirely different virtual platforms to the real one. As obvious, the first case produces very fast results because only APIs need to bring up while the machine we see is still the real one. The second one can support totally alien OSes or platforms, but can be rather slow compared to a real machine. But in some cases there are mechanisms that permit the virtual code to run natively in the real processor, hence gaining speed in the virtual machine environment. Projects: Wine (Wine Is Not An Emulator) belongs to the first case and can support MS Windows programs and even some Dos ones, without absolute need of an MS Windows Installation. I have personally tested the following at home or in the offices I support:
Wine is Free (and Open). However, 2 products that are based on Wine are not: Cedega, former WineX, based on the Wine source code is exceptional for games. I haven't tested it personally, but a simple visit to relevant sites will inform us about games like "Medal Of Honor: Allied Assault" working perfectly! WineX is commercial, but can be freely obtained and compiled through CVS! Crossover Office, based on the Wine source code too, excels in running MS Office applications. I am certain that MS Office 2000 is fully functional. For the XP version, I can't be sure at this moment. Cygwin (GNU + Cygnus + Windows) is Wine's counterpart! It provides a POSIX environment and tools on Windows, through Api Implementation. The environment uses the well known Unix ® functionality that we know! Mounts point to Windows drives, permissions are respected both ways! Most of the everyday terminal applications are present, as well as Xwindow, Window Managers and Desktops! Cooperative Linux (or coLinux) is a port of the Linux kernel that can run alongside another operating system without the need of a Virtual Machine. When the kernel starts, a terminal window allows interaction. Therefore an image file of a complete distro is also required and an XServer must run on Windows in order to run a GUI. Cygwin and Windows XServers (Xming, XManager) fullfill this need. VNC can also fullfill this task! ReactOS is a complete GPLed Microsoft Windows compatible software. Based only on GPL code, it provides api implementation of a Microsoft Windows® XP OS from the ground up. ReactOS works very closely with Wine (and actually uses parts of Wine) but instead of running the Wine API on top of a Wine Server (as it would work in Linux, *Bsd etc.) the team follows a different path. Some drivers for Microsoft Windows actually work on ReactOS. Respecting the teams wish, I do not describe this project as a Windows Clone. VMWare is a cross platform virtual machine that can emulate Windows in Linux or the opposite (and many more variations) and is definetly worth checking. This is a commercial product. QEmu, like VMWare, but Free-Open virtual machine solution. If a PC is emulated on a PC, QEmu includes a proprietary module that allows the emulated code to be executed directly on the host (real) processor, therefore achieving near-native performance. VirtualBox is Sun Microsystem's Virtual Machine solution. The Corporate Edition allows virtual machine creation and implements direct USB connection between the virtual OS and real devices. There is also an Open Source Edition which lacks some of the Corporate version's features. Bochs emulates an IA32 (x86) computer, with instructions varying from 386 to AMD64 optionally supporting MMX, SSE (1&2) and 3DNow!. The OSes that positively run on top of this virtual hardware are: Linux, DOS, Windows® 95/98 and Windows® NT/2000. Xen is another virtual machine for x86 compatible computers, capable of running multiple virtual machines with close - to - native performance. Officially Xen supports Linux and NetBSD virtual machines only, because porting to Xen is required for optimal performance. Currently, ports exist for Linux kernels 2.4 - 2.6 and NetBSD. Stonx, one of many Atari ST emulators for GNU/Linux can easily support games and applications for the ST platform. I used it once to help a friend to export music work of his as midi files, running his oldest Cubase Desktop Midi Recording System for Atari ST in a Linux box. Beware, this is an emulator and needs a TOS image to virtually boot. The Tramiel Operating System is not free, but can easily (and legally) extracted from your Atari ST rom to a floppy disk with the help of a native Atari ST utility. Stonx can emulate digital sound, but midi emulation may not have been achieved yet. DosBox, a Dos emulator, can run games and applications, now including many that run in protected mode, including the good old Norton Commander and games like Legend Of Kyrandia, Quest For Glory (I-IV) , Monkey Island (I,II), UFO Enemy Unknown and many more. DosEmu, a rather old project, but worth checking. Can boot from proprietary Microsoft Dos boot as well as Open Dos projects. ScummVm, a 3rd party portable generic Lucasarts SCUMM compatible gaming engine. If you have missed Guybrush Threepwood these days that you use your Linux box, you can meet him again in Monkey Island I II & III. This engine is generic, meaning that it can play many games, so the designers gave it a menu & configuration as well as a very good list of command line options. Mame, the famous arcade game emulator exists for Linux and *Bsds. |
Other ways: 1) Ports: There is another way for playing games from different platforms. Instead of emulating, a game executable that uses the rest of the game data can be created to run natively in the present platform. This task may be done from individuals or companies. www.lokigames.com offers game editions specifically modified for use in Linux (and other OSes). 2) User Mode Linux: It is often needed to run an entire virtual Unix-like environment for hosting services (like shell). This solution is chosen either: for not "wasting" a complete hardware platform or for security and limitation reasons. Because in reality User Mode Linux is running a kernel over a kernel, the second kernel runs in user space entirely. Note: This appears similar to coLinux which works side by side with Windows. 3) Flash Java and .Net. Flash Java and .Net are virtual environments too, in the sense that they provide an "abstract" platform, which means that Instead of being hardware, they live inside an Operating System as software "packages". In this way they can be incorporated into totally different environments. Programming in these environments doesn't require to look "lower", deep in the OS-platform mechanism. Java, former "Oak", originally developed as a language for appliances and simple devices to interconnect and communicate (eg refrigerators etc.), soon evolved to a virtual machine to serve as a programming environment. It is widely used in the Internet and can succesfully implement complicated programs when portability is first priority. Many cellular phones operate solely on Java. But the fact that a virtual environment is much slower than a real one applies to Java also. Java goes along with Javascript, which is a scripting language interpreted from - instead of compiled for - the Java virtual machine and then executed. Adobe (but originally Macromedia) Flash is more oriented to graphics and when we refer to it, we either mean Flash (the programming environment) or Flash Player (the actual player of a flash program). It is object-oriented, supports Vector (think lines circles etc.) and Raster (think pixels) imaging (and video) and incorporates a scripting language. Flash is ideal for comic animation but it is also capable of producing games and even simulating the quality of the old coin op consoles and simple electronic handheld games. .Net is Microsoft's "abstract" platform. Its functionality is implemented into its IDE (intergraded development environment) suite "Visual Studio": VisualBasic, C++, C#, in Professional as well as "Express" (student oriented) editions. 4) Silverlight, Moonlight and Mono. Silverlight is Microsoft's answer to Flash. Moonlight is the open source implementation of Silverlight. Mono is the open source implementation of .Net! The last two are Miguel De Icaza's inspiration. Who is he? The creator of GIMP, GNOME, GNumeric and Midnight Commander of course!
|
Notes on Wine Cygwin coLinux Dosbox ScummVM and VirtualBox Wine: 1) Devices are now soft links instead of configuration file entries and are usually located in the $HOME/.wine/dosdevices directory for each user. Here you will find drive letters and com ports. There are plenty of them and in reality not that many are needed. Only C: (Windows root) and Z: (Unix root "/") are necessary aside from the cd-dvd mounts, but I would suggest also a d: drive for a second partition, or a K: drive for a Local Area Network mount or even an X: drive for a loop ISO image file mount. Taste varies in these cases :) 2) Wine will read the configuration file in order to use either Alsa, Arts or OSS for sound emulation. Most games would not tell the difference, however applications like Sibelius would. For any applications I use a conf file that specifies Alsa, so that the program running can find Midi ports as well as digital sound devices - and even soft synths if attached to the Alsa module. For games in the other hand, I use Arts in order to intergrade the application into the KDE sound environment. 3) Wine can run run in an existing full Windows root directory or in a stripped - only for Linux/Wine - one. I usually don't want two roosters in one hen-house and I would also advise you not to. Better have a Windows dir only for Windows operation and just have it mounted for disk access when operating in GNU/Linux. There is one exception though. If there is a case Windows is inoperable, you can instruct Wine to operate on the native Windows dir and run the Wine registry editor to clean the reg keys that hurt Windows. 4) DLLs can be serviced in Wine as built-in or native. Native means that wine will use the existing ones in the specified windows root. This can be twicked very thoroughly in the Wine configuration file. 5) There can be program "exceptions". Wine has a section in the conf file to give specific instructions for programs that run, including visual and library issues. Using this, we may spare ourselves the different conf files that might be needed to make programs operational. 6) The Wine Prefix environment variable enables Wine to work in separate directories and configurations. With this method, programs can not interact with each other, so different versions of aplications can coexist in our Linux installation, like Internet Explorer 5,6,7 and so on. It's like "bottles of wine", a name adopted by Codeweavers for their commercial product. Cygwin: 1) The installer can add - remove - update packages. The whole environment is installed to a single directory and runs from a single batch file! Cygwin can be installed for all users.It detects the user first-time running it and adds user and home. Everything is transferable-editable from Windows! 2) For projects to run on Cygwin, they must be compiled for it. X and also Windows Managers and Desktops are included! Cygwin projects are compiled as exe and dll files. So, they are also runnable independently, (i.e. directly from Windows) if the environment permits such an action! So, the easiest apps we can run from the Command prompt are terminal applications like pico, nano, tar or mc! 3) Cygwin is ideal for keeping our custom scripts alive in Windows! Although there are countless applications to ease our work in any Wintel platform, we can still take advantage of our personal scripting - and even programming - experience in order to extend our working environment the Linux way!!! coLinux: 1) coLinux is superfast! It's a kernel without a virtual machine. Any operation is nearly at real speed! It can start as a service as well as an application. As a service, it will be up without a terminal attached. The provided terminals can connect later to the service when needed. 2) It has an impressive variety of mount options. Any mount point can be an image file, a local drive:\directory, a network share and also a real disk partition! So coLinux is ideal for accessing linux partitions without having to boot to Linux to do so. The Windows kernel gives disk access down to the device level! Even a e2fsck (think chkdsk) Linux partition health check can be performed! 3) It provides a horde of options to interconnect with the local system, the local area network and the internet. Easy methods include ttyS (virtual serial device) and SliRP (firewalled PPP/SLIP emulation). 4) More complicated methods include TAP-Win32 (virtual network card with every functionality provided by Windows like bridging and Internet Connection Sharing) ndis (coLinux kernel bridged ethernet capturing a real Windows driver) and WinPcap (packet capture driver/library acting as a software bridge)! 5) coLinux is based on a .bat style script and a text-based configuration file. The rest is done by the root partition's configuration files (whatever the root aprtition we choose. The text-based configuration has options to run host applications post-booting. We may configure to run an XServer or a VNC client etc., which will close when we shut down the coLinux instance. BEWARE: coLinux is not an API like Cygwin. If it's closed via the window, it will leave the partitions "dirty". The clean method is to issue a clean shutdown/reboot command as we would do in any real GNU/Linux environment or virtualization solution. 6) Xclients (think programs needing Graphics User Interface) need an XServer to run in Windows (Cygwin Xwindow, Xming, Xmanager) but this is not the only solution. We can also run a VNC server at the coLinux side and a vnc client in the windows side. Xvnc on coLinux and TightVNC on Windows can do the job! The VNC server can spawn as many times as needed, to run VNC instances for any user that wants to connect! 7) Sound is also an issue in coLinux. The solution is to use a cross-platform network-transparent sound server such as Pulseaudio. We can configure the Pulseaudio server in our coLinux box to "connect" to our Windows machine's Pulseaudio server (the one that actually "sees" a sound card). Dosbox: 1) Dosbox can run in full screen - window on demand or preconfigured to do so. Different configuration files can be assigned upon command. Just use the -conf /path/conffile switch to instruct dosbox to run alternate conf files. These conf files have an Autoexec section in order to use batch commands, therefore mount options, loadhigh (memory) commands and programs-to-run can be easily set. 2) Mounting a cd in dosbox is a lot easier than in Dos itself. Back then we had to preconfigure two files, boot in order to activate the cdrom and reboot to make changes to the devices and/or drive letters. Now all these mounts can be unmounted and new ones can be set to operate on without restarting the emulator. 3) Mouse support , CDROM mount support and other functions (XMS, EMS, DPMI, DOS/4GW 32bit memory extender) are implemented into the "box". Hence, precious base and upper memory is not occupied by additional drivers, therefore most of base memory is free for use. 4) Dosbox can throttle the virtual CPU simulating various machines, 386, 486, Pentium etc. It can do this realtime as well as look it up in the configuration file entry. Throttle can be set to static or dynamic adjusting on the parogram's needs! Combine this with the alternate configuration file ability and you can have a very diversive use of Dosbox. ScummVM 1) ScummVM can nowdays play a horde of old games, not only Lucasarts ones. The games themselves do not have to be installed. As the executable is ScummVM itself, it only needs to find the resource (data) directory in a cd/dvd or local directory. It then makes a menu of the games and can save/load gamestates. All of this is usually located in the $HOME/.scummvm directory. Because of this, if a game can be played in Dosbox and ScummVM, I would suggest the latter. 2) ScummVM has a global setting as well as game-specific settings to play around. You can put the menu in window mode and the games in full screen etc. There are other options as well, like aspect ratio correction and sound - volume options. VirtualBox Oracle's (although initially Sun Microsystem's) virtual machine offers a great deal of features in both the Corporate and the Open Source Edition, although some features are not present in OSE. In the Corporate Edition we can: 1) Create and manage virtual Disks, mount cdroms and floppies (or images), configure and boot a virtual machine, install an Operating System. 2) Attach virtual graphics network and sound devices and use different resolutions in window or full screen mode. 3) Configure base and video memory, add a bunch of features, like ACPI, IO APIC and more. 4) Take advantage of CPU technologies to optimize virtual code execution on the real machine. 5) Utilize the power of symmetric multiprocessing on our machine. By the time this line was written, 16 processors was the max number. 6) Filter USB ATA and Serial devices from the real machine to the virtual one. USB can be filtered remotely from another machine! 7) Power on, power off, pause, close, resume state and take snapshots of the virtual hosts. 8) Share folders between the virtual host and the server, allow remote display to the virtual host. 9) Work in Seamless Mode" (Guest OS taskbar only without desktop, with apps in their own window running on the real os's desktop). There is a catch in the device share though, instructions for this issue will be presented very soon. |
The Real Thing - screenshots here! When talking about virtualization solutions is not enough, examples can fill the gaps Whether these solutions are practical or not, depends on your needs. In my opinion any virtualization/implementation method described in this page is impressive at least. Some examples were easy, others were not. Some take time to work, others are just running after a quick install. Please take a look at my screenshots page. |