Nobody in our groups has yet requested the ability to run on the computation servers some program that is only available in a form for running on another operating system, e.g. ms-windows or hp-ux or solaris-sparc.
A few examples of situations where other platforms have been used/required.
In one case, a program ported from hp-ux to linux-on-intel has had trouble
with convergence in a particular extreme case, probably due to the higher
default precision of the new platform (see loweset links of
the floating-point calculations section); since it
is proprietary, we can't do an awful lot to investigate this.
In another, some libraries required by some existing fortran routines
are available more cheaply in an ms-windows
compiler, making this the quickest, cheapest option.
Others from other groups sometimes use proprietary ms-windows only programs
in their work, but haven't yet expressed any need of using simulation servers.
There's not much to be done about hp-ux or solaris-sparc things: we're running on an incompatible CPU architecture, we haven't an emulator for it, and that would presumably be slow anyway. Fortunately, these programs tend to be ported to linux-on-intel anyway.
For ms-windows programs, there are more options.
VMware (VM="virtual machine") is a (proprietary) set of programs for providing a `virtual' intel-like computer within the running operating system, allowing installation and running of any other operating system that runs on that type of CPU. One or more instances of ms-windows or other x86 or amd64 systems such as the BSDs, Solaris or other Linuxes, can therefore be run. VMware requires kernel modules and some parts that run as root, so it can't be installed by normal users: users must be given access to a ready-installed vmware.
We have VMware-server running now on diagsim (since this has plenty of memory and CPUs). This is a freely available program, allowing multiple users to run multiple virtual machines at the same time (but the users must be added by the administrator to a list of approved VMware users). The server itself runs as a service. With version 1.x, the program 'vmware-server-console' is used to log in to the server and start and stop virtual machines; the console program can be run from the same computer as a graphical user application, or from other computers on our network. Version 1.x of vmware-server has the disadvantage of a 3.6GB memory limitation per virtual machine, which for 64bit systems and programs is a potentially important limitation. Version 2.0 (beta) is currently in use instead, with an 8GB memory limit, but the access is then done through a webbrowser applet or by VNC to a virtual machine, which is not as neat as the old way.
A separate, fast disk, mounted on /vmware, is used to hold the files that vmware uses as the disks for the virtual machines. The virtual machines can be given access to users' home directories or to the local disks for storage. It is advised to keep important data in the network home directory rather than in the virtual machine.
vmware-server-console provides essentially the same functionality as the better known vmware-workstation (single user, paid licence!). Virtual machines may be made with choice of 1 or 2 CPUs, varied memory size, 'NAT' or private networking, and CDROM drives that are disk image files or the CDROM drives of the host (diagsim) or client (your own) computers. A new system can be set up in a virtual machine by providing an installation disk image as the new virtual machine's CDROM. Often, a better way to install virtual machines is just to copy the files of an existing one.
A virtual machine can be suspended, with its memory saved to disk. For ones with several gigabytes of memory, it's usually quicker just to turn them off rather than waiting to save and retrieve all this data to/from disk. Running many virtual machines would waste a lot of memory on the extra operating systems. Doing heavy disk-access from several would, in the current configuration, slow them down a lot due to the single shared disk. But, for reasonable simulation use, where each virtual machine has enough memory available for running without swapping, and where the work is mainly CPU-limited after startup, it should be possible to have two or three concurrent virtual machine sessions, each with two CPUs working, without significant reduction in performance of any virtual machine or the host system.
Wine is a Free implementation of the libraries (programming functions) that programs expect to be able to call on an ms-windows system. Running ms-windows programs under Wine allows them to run on any Unix that runs on the Intel hardware. Extra DLLs can be added to Wine's collection for running programs with special needs.
The catch is that not all programs will work, or at least, not always immediately. This is mainly caused by programs requiring other components such as iexplore or an installer program, or being funny about graphics acceleration and fonts. Whether a big GUI program will install and run is best determined by trying: many do, particularly the popular things like some games, adobe photoshop and so on -- obscure technical programs are less likely to have had their peculiar requirements considered.
The best case is a command-line executable, reading and writing command and data files, particularly if it can be staticly linked so as not to depend on local libraries. This would allow all the usual scripting and automated execution, simply calling the command with `wine' before it.
Wine can be configured for each user by `winecfg'. Programs are installed by, for example `wine setup.exe'. A directory somewhere in the user's home-directory (by default ~/.wine/drive_c) contains the pretend `C-drive', including the installed files, which themselves can be run as (e.g.) `wine .../path/to/C/Program\ Files/Name/Exe.exe'.
Users of ms-windows desktop computers (now that Apple uses a unix variant) may wish to have some familiar scripting environment, or glue-language, for things like automating file-management tasks (backup, renaming, data-handling) and running other command-based programs in loops with control of parameters, output and input files, etc.
The languages Python and Perl, described and linked in the page on scripting are available for all at all widely used platforms. They offer a good way to be largely independent of the underlying system in things like file access (but it's still possible to write things in a way that will not work on different systems). Both are known as glue languages (for tying other languages together). The interpreters and libraries can be installed from links on the languages' sites.
The GNU command-line utilities have in many cases been ported to ms-windows as native commands (not requiring further emulation layers). This allows them to be called as commands from a DOS-prompt. Lack of support for certain filesystem features may change their behaviour from the normal, in some cases. See unxutils: GNU utilities for Win32 for more details and downloads. The GNU shell (bash) has also been ported natively, and can be found on the web in various (often old) forms, e.g. winbash.
Cygwin provides an emulation layer to allow programs written for unix (posix) systems to be compiled and find the required libraries on ms-windows systems. The installer allows not only the basic emulation but also lots of common commands and programs to be installed, including an Xserver. This dispenses with any need for the above native utilities (or even Perl or Python) if one instead runs all of these programs in their unix versions, in this compatibility layer. The main use, of course, is if for some reason you are forced to run one system on your computer but you want to use another system...
In the above, the idea of using the traditional DOS-like shell has hardly
even been considered. It's assumed that the user wants something better
or is at least familiar with other things. One recent development is that
microsoft has begun to realise that doing everything with GUIs is not only
very inefficient in some cases, but that it actually puts off some customers
if no reliable means of scripting system maintenance and configuration
exists! A probably more useful shell-type program has emerged recently,
called
monad or power-shell(!). A reading of the manual and marketing
suggests that for system administration this should be a significant
advance -- not before time. Basics from the widespread unix shells
are included, such as pipelining, redirection, flow control, autocompletion,
aliasing, and making one's own commands in this scripting language.
System administration programs communicating in pipelines pass `objects' to
each other rather than using plain text: this presumably simplifies some
`edge cases' of strange data when using just system administration programs.
Users of `genuine' software
can download this shell. I recommend Perl or Python as much more suited to
technical (batching jobs, simulation, etc.) tasks rather than system
administration ones, and as being also more portable and mature.
Page started: 2007-11-xx
Last change: 2008-06-03