%bochsdefs; ]> KevinLawton BryceDenney MichaelCalabrese Vasudeva N. DavidGuarneri ChristopheBothamy

Bochs is a program that simulates a complete Intel x86 computer. It can be configured to act like a 286, 386, 486, Pentium, or Pentium Pro. Bochs interprets every instruction from power-up to reboot, and has device models for all of the standard PC peripherals: keyboard, mouse, VGA card/monitor, disks, timer chips, network card, etc. Because Bochs simulates the whole PC environment, the software running in the simulation "believes" it is running on a real machine. This approach allows Bochs to run a wide variety of software with no modification, include most popular x86 operating systems: Windows 95/98/NT, all Linux flavors, all BSD flavors, and more. Bochs is written in the C++ programming language, and is designed to run on many different host platforms Since Bochs can run on one kind of machine and simulate another machine, we have to be clear in our terminology to avoid confusion. The host platform is the machine that runs the Bochs software. The guest platform is the operating system and applications that Bochs is simulating. , including x86, PPC, Alpha, Sun, and MIPS. No matter what the host platform is, Bochs still simulates x86 software. In other words, it does not depend on the native instructions of the host machine at all. This is both a strength and a weakness, and it's the major difference between Bochs and many other x86 emulation software such as plex86, VMware, etc. Because Bochs uses software simulation for every single x86 instruction, it can simulate a Windows application on an Alpha or Sun workstation. However, the downside of Bochs's approach is simulation performance. To model the processor accurately, Bochs must run many instructions for every simulated x86 instruction, and this makes the simulated machine many times slower than the physical machine. Commercial PC emulators (VMware, Connectix, etc.) can achieve much high emulation speed using a technique called virtualization Virtualization takes advantage of simulating x86 instructions on an x86 machine, allowing large portions of the simulation to take place at native hardware speed. Whenever the simulated machine talks to the hardware or enters certain privileged modes (such as in kernel code), the simulator typically takes control and simulates that code in software at much slower speed, just like Bochs does. , but they are neither portable to non-x86 platforms nor open source. Plex86, Kevin Lawton's current project, is working toward an open-source x86 simulator with virtualization. To do anything interesting in the simulated machine, Bochs needs to interact with the operating system on the host platform (the host OS). When you press a key in the Bochs display window, a key event goes into the device model for the keyboard. When the simulated machine needs to read from the simulated hard disk, Bochs reads from a disk image file on the host machine. When the simulated machine sends a network packet to the local network, Bochs uses the host platform's network card to send the packet out into the real world. These interactions between Bochs and the host operating system can be complicated, and in some cases they are host platform specific. Sending a network packet in FreeBSD requires different code than sending the packet in Windows 95, for example. For this reason, certain features are supported on some host platforms and not others. On Linux, Bochs can simulate a network card that communicates with the world, but on BeOS the simulated network card may not work because the communication code between the device model and the BeOS operating system has not been written. Bochs was written by Kevin Lawton starting in 1994. It began as a commercial product, which you could buy with source code for $25... &NEEDHELP; We need a Bochs historian to help out here. For background, it would be interesting to know how much Bochs used to cost and what it was used for. I thought I saw an interview out there somewhere where Kevin says why he started it and some more background information. Finally, in March 2000, Mandrakesoft bought Bochs and made it open source under the GNU LGPL. In March 2001, Kevin helped a few developers to move all Bochs activities from bochs.com to a new site at bochs.sourceforge.net. Since then the Bochs Project has settled into its new home, and around release times has even hit #1 most active project of the week at Source Forge.

It is hard to estimate how many people have tried Bochs or use it on a regular basis, but a few statistics give an indication. The bochs-developers mailing list, which is the primary source of news on bugs and releases, has over 400 subscribers. The latest version has been downloaded over 50,000 times from SourceForge, not counting any mirror website or CVS users. Bochs has many possible uses, and different people use it for different things. Many people use it to run applications in a second operating system without needing two different computers or dual-booting. Running Windows software on a non-x86 workstation or on an x86 UNIX box are common uses. Also, because every hardware instruction and every line of simulator code is accessible, Bochs is used extensively for debugging new operating systems. If you were writing boot code for your home-brewed x86 operating system and it didn't work right, booting it in Bochs could give you great visibility into what is really going on. The Bochs debugger lets you simulate quickly or slowly, pausing whenever you want to look at the contents of memory or the CPU registers. Or, if you wanted to study which parts of a program take the most time, you could use Bochs to measure how often certain pieces of the code were executed. Bochs has been used as a teaching tool in Operating Systems classes, in which students used and modified it to learn how the PC hardware works. As a final project the students had to add a new peripheral device, so they had to learn all about I/O ports, interrupts, and device drivers. In industry, it is used to support legacy applications on modern hardware, and as a reference model when testing new x86-compatible hardware. There may be as many uses of Bochs as there are users. Do you want to run your old DOS games? Or learn how to program under Linux, without leaving your Windows desktop? Or reverse engineer your printer driver? You decide.

Bochs is very useful for some applications, and not well suited to others. This section tries to answer the question, "Is Bochs right for me?" Bochs may or may not be right for you, depending on what it is you want to do. Perhaps all you want to do is run one or two applications native to Microsoft Windows on Linux, or vice-versa. Perhaps your biggest concern is speed and performance. Maybe you don't mind tweaking a few files here and there when you want another application to work in that setting. In cases where the objective is to simulate x86 hardware on an x86, Plex86, Wine, and VMware might be your best options. On the other hand, perhaps you have a vital application running on an older operating system that only runs well on old hardware. You are concerned that the life cycle of this hardware is coming to an end, and your backup and restoration hardware and tools no longer suffice for the amount of data that you have. You need to transfer backup disk images over a network, and want to use modern procedures for hardware maintenance. Perhaps the application is important enough to run on a larger computer, such as a 64-bit machine, or even a mainframe. Bochs would be an excellent option in such a scenario. Perhaps your objective is to debug software or hardware drivers. Bochs offers a controlled environment that can better assist you in determining cause and effect relationships. You can take snapshots that show you what is going on behind the scenes. You can isolate the line that caused that crash. You can have multiple images and compare them under a microscope. In these situation, Bochs could save you time and resources. Information Technology changes faster than any other field. It is very easy to forget transitional software that came and went. But history is important to all fields, and to build on the future, it is important to understand the past. Computer programmers, however, do not have the same advantage as an architect, who can, for example, take a trip to Greece and touch a pillar. Much of the history of Computer Science is left on corroding floppies and malfunctioning hardware. Bochs gives you the benefit of having one or more complete environments where you can understand firsthand the behavior of operating systems and programs. This cannot be achieved with an "emulator" such as Wine.

Whether Bochs works for you depends on your host hardware, host operating system, guest operating system, guest software, and your ability to work in a command-line environment using documentation. There is no gui or wizard to help you through the setup process. You do not get a recovery or installation disk to assist you in the process of installing a guest operating system. Bochs only provides you with the "virtual hardware", and it is up to you to do the rest. Bochs will run on Windows, Linux, FreeBSD, OpenBSD, or BeOS. If you are running on x86 hardware, you have a range of choices. Check the installation section for your host platform to see what options Bochs supports on your platform. If the most important factor is speed, you may want to try a virtualization product instead of Bochs (VMware, plex86). If you are using a non-x86 machine, then Bochs is one of the few choices for running x86 software. Bochs has been known to work on Solaris (Sparc), Linux (PowerPC/Alpha), MacOS (PowerPC), IRIX (MIPS), BeOS (PowerPC), Digital UNIX (Alpha), and AIX (PowerPC). You can also find more detailed testing information on the testing status page on the &bochswebsite;.

Bochs is copyrighted by MandrakeSoft S.A. MandrakeSoft has web sites at http://mandrakesoft.com and http://www.linux-mandrake.com. and distributed under the GNU Lesser General Public License Complete text of the GNU LGPL is included with the source code in a file called COPYING, and is also here. . The following text appears at the top of every source code file in the Bochs distribution: This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

Before you install or use any Operating System, BIOS, or other software package within the Bochs PC emulation environment, make sure you are and will be in compliance with all the software licenses pertaining to the software you wish to install. It is completely your responsibility to provide licenses and records on all software that you install and/or use. It is also completely your responsibility to maintain total compliance with all Software Licenses involved. In the process of installing Software within the Bochs PC emulation environment, it may be helpful or necessary to copy or convert files from the original distribution format to a second format to facilitate the installation. You should delete the intermediate files after installation, making certain that only the original distribution files remain.

The following table shows the features of Bochs and which platforms they currently work with. Feature Supported? Description configure script Yes Bochs uses GNU autoconf to configure Makefiles and headers. Autoconf helps Bochs to compile on a wide variety of platforms. 386,486,Pentium Emulation Yes Bochs can be configured to emulate on of several families of Intel hardware. Some Pentium features are supported, such as the Time Stamp Counter. Pentium Pro Emulation Incomplete A few Pentium Pro features are supported, such as an on-chip APIC for SMP simulation. Cmd Line Debugger Yes Powerful command line debugger (optional) that lets you stop execution and examine registers and memory, set breakpoints, etc. Floating Point Yes Uses software floating point routines written by Bill Metzenthen Enhanced BIOS Yes Implements specifications ElTorito, EDD v3.0, PCI32 directory service VGA Yes VGA color graphics emulation in a window Floppy disk Yes Supports floppy disk images on all platforms: 1.44M 3.5", 1.2M 5.25", and 720K 3.5". On Unix and Windows NT/2000, Bochs can access the physical floppy drive. Multiple ATA channels Yes Emulates up to 4 (four) ATA channels. Up to 8 (height)ATA/ATAPI emulated devices can be attached, two per ATA channel. So you can have eight hard disks or seven hard disks and a cdrom or four hard disks and four cdroms, or one hard disk and seven cdroms, etc... Hard disk Yes Emulates ATA-2/IDE hard drives via image files. Physical hard disk access is supported on some architecture, but NOT recommended, primarily for safety reasons. Hard disk up to 32GB are supported, on any platform that support large files access. CDROM Yes Emulates ATAPI-4/IDE CDROM. The CDROMs can read from an ISO disk image on any platform. On Windows (95/98/NT/2000), Linux, SunOS, FreeBSD, NetBSD, Amiga/MorphOS, and BeOS, Bochs can read from the physical cdrom. Starting with version 1.4, Bochs is even able to boot from a bootable cd or bootable iso image. Keyboard Yes Emulates a PS/2 keyboard with North American key mappings. Optional keyboard layout remapping files are provided to support localized keyboard in X11 (german, french, italian, spanish, danish, swedish) Mouse Yes Emulates a PS/2 mouse with 3 buttons. Network card Yes Emulates an NE2000 compatible network card. On Windows NT/2000, Linux, FreeBSD, and NetBSD, Bochs will forward packets to and from the operating system so that the guest OS can talk on the physical network. Unfortunately, with the current implementation (except linux), the guest OS can talk to any machine on the network BUT NOT the host machine. On linux, with the tuntap interface, there is no such limitations, and the host machine may even be configured as a router so the guest os has access to the internet (see for configuration instructions). Parallel Port Yes Parallel port emulation was added by Volker Ruppert for Bochs 1.3. Data that is sent to the parallel port by the guest OS can be saved into a file or sent directly into the parallel port device (Unix only). Serial Port Not quite The serial port (single 8259 UART emulation) is not really usable yet. The interface to the emulated CPU is mostly working, but it needs some work before it can talk to a raw serial port or to a pseudo terminal. PCI incomplete The Host-to-PCI bridge, and Primary Memory Controller are available. However, PCI-to-IDE, PCI-to-USB, or other PCI cards are not implemented yet. 16/32 bit addressing Yes 16 or 32 bit operand sizes, stack size, and addressing v8086/paging Yes Virtual-8086 mode and paging PIC Yes Master and slave programmable interrupt controller. CMOS functions Yes CMOS functions Dynamic Translation/Virtualization No Because Bochs is designed to be portable, it does not attempt to do any dynamic code translation or virtualization. See What is Bochs? for details. Simulate a Multiprocessor Yes Bochs can be configured to simulate up to 15 processors. This feature is still experimental, but it can boot Linux 2.2 kernels with SMP support. Please note that this does NOT mean that bochs can run faster on a physical SMP machine. Take advantage of your SMP box No At present, Bochs does not use threads or parallel processing, so it will not run any faster on multiprocessor hardware. Copy and Paste Yes Text-mode screen text can be exported to the clipboard. Text in the clipboard can also be pasted, through Bochs, to the guest OS, as simulated keystrokes.

&FIXME; should add a column with supported display library (X11, SDL, wx, etc...) Unix/X11 X windows has always been well supported because it was Kevin's Lawton's main development platform. Bryce Denney maintains the Unix/X11 platform now. Most features and fixes (not all) are tried first in Unix and then ported to the others. Win32 This port was done by David Ross and is now maintained by Don Becker. You can compile with MS Visual C++ 5.0 or 6.0, or Cygwin Cygwin is a free Unix-like environment for Windows written by Steve Chamberlain and now maintained by RedHat. Download it from--you guessed it--www.cygwin.com . See for compile instructions. BeOS Kevin Lawton did this port, originally to R3/PPC using CodeWarrior. It now works on R4/x86 with egcs. Simon Huet picked up maintaining/reworking the BeOS GUI port. In September 2001, Bernd Korz of Yellow Tab, Inc. (www.yellowtab.com), took over the BeOS/Zeta port. Use the same compile and install process as Unix. MacOS X Emmanuel Mailliard ported the Macintosh code to MacOS X with Carbon API. He has been too busy to maintain it, so if you are interested in working on it, contact the &devlist;. Macintosh David Batterham drbatter@socs.uts.edu.au or drbatter@yahoo.com ported bochs to the Mac. He compiled with CodeWarrior Pro R1 (CW12). To compile, you have to build headers and Makefiles on a Unix machine using "configure --with-macos". Check out David's MacBochs website. David has not had time to maintain the page or the Mac port since early 2000. If you have Mac development tools and want to contribute, contact the &devlist;. Amiga MorphOS This port is written and maintained by Nicholai Benalal. OS/2 Nick Behnken used PE2LX to translate David Ross's Win32 port to an OS/2 program. This hasn't been updated in more than a year, and Nick Behnken's page seems to be inactive. Also, Craig Ballantyne ported bochs to OS/2, but his web page has disappeared and his port has not been updated since March 2000. His latest sources are at http://www.os2world.com/emulator/computer.html. If you want to bring the OS/2 port up to date, contact the &devlist;.

Is Bochs Open Source? Yes! Bochs is released under the GNU LGPL, much thanks to MandrakeSoft, makers of the Linux-Mandrake distribution. How do you pronounce "bochs"? Phonetically the same as the English word "box". It's just a play on the word "box", since techies like to call their machines a "Linux box", "Windows box", ... Bochs emulates a box inside a box. Who is the author of bochs? Kevin Lawton is the primary author of bochs. There have been bug fixes, enhancements, and code contributions from some few hundred people, so it is not possible to list them all. Kevin is presently working on a PC virtualization project called plex86 and no longer maintain bochs. Who maintains bochs now? With Kevin's help, in April 2001, the members of the bochs-developers mailing list set up a new official bochs site hosted by Source Forge. The current admins on this project are Bryce Denney, Greg Alexander, and Don Becker. Tell me about performance when running bochs? Because Bochs emulates every x86 instruction and all the devices in a PC system, it does not reach high emulation speeds. Kevin reported approximately 1.5MIPS using bochs on a 400Mhz PII Linux machine. Users who have an x86 processor and want the highest emulation speeds may want to consider PC virtualization software such as plex86 (free) or VMware (commercial). Does bochs use a disk partition to install the OS? No. You use a disk image file, which is simply a large file, like any other file, on your platform's disk. Why can't I use Bochs with my current Win95 installation? Think about this. If you had two different PC's, they would require different hardware drivers. So you may not be able to safely move a disk drive with Win95 on it, from one to the other. Bochs is no different. It emulates a certain set of hardware devices, and requires each OS be configured for those devices. Is there a developer's email list for bochs? Yes. For instructions on joining, refer to Is there an irc channel for bochs? Yes. You will usually find Bochs developers and users on irc at irc.openprojects.net:6667, channel #bochs Do you know of any snapshots of Bochs running Win95? Yes! Look for "screen shots" on the Bochs home page or on other Bochs sites. Does bochs support a CDROM? Yes, a CDROM is supported in Linux, Windows, and OpenBSD. The CDROM drivers for bochs allow the guest operating system to access the host operating system's CDROM data directly. Does bochs support a sound device? Yes, there is Sound Blaster emulation support for Windows and Linux. Does bochs support a network card? Supposedly yes. There is emulation for an NE2000 NIC in the current releases, though I have not heard whether it works or not. If you try it, please fill out a testing form or bug report. What applications are known to run inside of bochs? Well, lot's of different OS's run inside of bochs, so thousands. I'm assuming your asking about Windows programs. To give you a few, the following ones from the Winstone'98 tests worked: Access 97 CorelDRAW! 7 Excel 97 Lotus 1-2-3 97 Word 97 PowerPoint 97 Quattro Pro 7 WordPerfect 7 Also, I've compiled an entire OS kernel inside bochs before. Not to mention, running DOOM, though at then-pathetic speeds.

Version 1.4 Change Log Version 1.3 Change Log Version 1.2.1 Change Log Version 1.2 Change Log Version 1.2.pre1 Change Log Version 1.1.2 Change Log Version 1.1.1 Change Log Version 1.1 Change Log

You can download Bochs from our web site at &bochs-sf-net;. First, you need to choose what version to get: a recent release or a development version. If you trying to get things working for the first time, a release version is recommended since it has been tested the most. The development versions (sometimes called snapshots) may have some newer bug fixes and new features, but have not been tested as much as the releases. Second, you can choose to compile Bochs from source code or install a binary (if one is available for your platform). Binary packages will be quicker to install, and most include a small demo of a guest operating system called DLX Linux to get you started. However, some features can only be enabled if you compile Bochs yourself, for example the Bochs debugger. For multiuser systems, you will probably need system administrator privileges (root) to install a binary package. If you decide to get a binary, download it to your hard disk, uncompress it, then go to the section called Installing a Binary for more information. If you are going to compile Bochs yourself, you need the gzipped tarball containing the source code, called bochs-version.tar.gz. For Windows and Mac, the prebuilt Makefiles are separate, so also get the Makefiles for your platform. To unpack a compressed TAR file A TAR file is a single file that contains many files packed inside. Bochs TAR files are compressed with a program called gzip, and another program called gunzip is used to uncompress them. on a Unix machine On Windows, look for software called WinZip to unpack the TAR. , type gunzip -c bochs-version.tar.gz | tar -xvf - This creates a directory called bochs-version full of files. This directory will be referred to as &bochsdir;. Go into &bochsdir; and you are ready to compile. Instructions for compiling Bochs are in the section, Compiling Bochs. Alternatively, you can also obtain the sources for any Bochs version using CVS. See the CVS instructions for details.

CVS, or Concurrent Version System, is a software development tool that helps to keep track of the different revisions of each file. It is used by many open source (and commercial) projects to allow multiple developers to share their changes to the source code. The Bochs source code and documentation are available using CVS You can download CVS software and documentation from www.cvshome.org. .

When you have CVS installed, the first step is to do a login and checkout. The initial checkout command is long and ugly, but usually you only have to do it once. The example below shows the CVS checkout process in UNIX. On the Windows platform, you can download a CVS client from cvshome.com, or use CVS within Cygwin Cygwin is an open source UNIX-like environment for Windows platforms, available at www.cygwin.com. .

user$ cvs -d:pserver:anonymous@cvs.bochs.sourceforge.net:/cvsroot/bochs login (Logging in to anonymous@cvs.bochs.sourceforge.net) CVS password: (there is no password, just press Enter) user$ cvs -z3 -d:pserver:anonymous@cvs.bochs.sourceforge.net:/cvsroot/bochs checkout bochs cvs server: Updating bochs U bochs/.bochsrc U bochs/.conf.AIX.4.3.1 U bochs/.conf.beos-x86-R4 U bochs/.conf.macos . . (This might take a few minutes, depending on your network connection.) . U bochs/patches/patch.seg-limit-real user$ cd bochs user$ ls Bochs.proj.hqx bxversion.h fpu/ osdep.cc CHANGES config.h.in gui/ osdep.h COPYING configure* install-x11-fonts* patches/ CVS/ configure.in instrument/ pc_system.cc Makefile.in cpu/ iodev/ pc_system.h README debug/ load32bitOShack.cc state_file.cc TESTFORM.txt disasm/ logio.cc state_file.h bios/ doc/ macintosh.txt win32.txt bochs.h docs-html/ main.cc bochs.rsrc.hqx dynamic/ memory/ build/ font/ misc/ user$ _

If you have write access to the Bochs CVS tree, the checkout command is different for you. See the Developers Guide &FIXME; not written yet. For now, look at http://sourceforge.net/cvs/?group_id=12580 for instructions. See "Developer CVS access using SSH." for details. If you use remote CVS for other projects, you might have already set the environment variable CVS_RSH in your configuration files. For the CVS checkout to work as shown above, the CVS_RSH variable should either be empty or set to rsh. The CVS checkout process (above) gives you a directory called bochs that contains the very latest source code. I will refer to this directory as &bochsdir;. In each subdirectory directory there's also a directory called "CVS" which tells the cvs software where the code was checked out, what version you have, and where to go for future updates.

Most developers use CVS to always give them the latest source code. The minute that any developer checks in a change, they are available to everyone else through CVS. You just have to type cvs update -d -A in the &bochsdir; directory, and CVS will retrieve any files and directories that have been changed since you did a checkout. If you update regularly, each update takes a short time because it downloads only the files that changed. The -d option tells cvs to download new directories that have been checked in, not just files. The -A option means to get the most recent version of each file, as opposed to a release version. See Getting a release version Both -d and -A can be omitted in many cases, once you are familiar with the process. The cvs update -A -d command tells you if any new files have been downloaded from the server, and it also tells you if you have modified any of the CVS-controlled files. As it checks through the source directories, it will list files that have changed, with a single letter before the name that tells the status of that file. The most common status letters are listed below. Letter Meaning Description ? unknown This file is in your bochs directory, but CVS does not know anything about it. For example, when you compile Bochs, any files created during the build process appear as ?. U update cvs downloaded a new version of this file because it changed on the server, usually because someone else did a checkin. P - P is the same as U, as far as I can tell M modified You have changed this file on your disk, so it no longer matches the version on the server. This is not a problem; it's just for your information. If you want, you can discard your changes and get a fresh copy by deleting the file and running cvs update again. C conflict You have changed this file on your disk, but this change conflicts with a change that was checked in. Conflicts occur when two people change the same line of code in different ways. You need to edit the conflicting file(s) and clean it up by hand. Or, sometimes it's easiest to discard your own edits and download a fresh copy, by deleting the conflicting file and running cvs update again. If you have been using cvs update with "sticky tags" to retrieve other versions, as described later, cvs will remember which version you were looking at. In this case, a cvs update will keep your sources consistent with that version. If you want to get back to looking at the latest code again, be sure to use the -A option to clears the sticky tags.

Once you have a CVS checkout, you can also use the update command to get the Bochs source code for any release since March 2000. The command is cvs update -d -r tagname. The tag tells which release you want, and it can be one of the following: Bochs version Release tag for CVS 1.4.1 (bugfix1) REL_1_4_1_FINAL 1.4 REL_1_4_FINAL 1.3 REL_1_3_FINAL 1.2.1 (bugfix1) REL_1_2_1_FINAL 1.2 REL_1_2_FINAL 1.1 (bugfix1) REL_1_1_BASE 1.1.2 (bugfix3) REL_1_1_2_BASE 1.1.1 (bugfix2) REL_1_1_1_BASE 1.1 (bugfix1) REL_1_1_BASE March 25, 2000 REL-bochs-2000-03-25 To get a complete list of allowed tags, type cvs stat -v README. Many of the tags are not generally useful. Once you have done an update with -r tagname, you have made a "sticky tag." The stickiness refers to the fact that CVS remembers which tag you have used most recently. The tag is stored in the CVS subdirectory, so it stays around even if you log off and return later. After creating a sticky tag, any future cvs updates will try to keep your directory in sync with the version you chose. In other words, when developers check in changes you will not see them because your directory is "stuck" looking at an old version. To clear the sticky tag, use cvs update -A. A variation on the sticky tag concept is a sticky date According to some sources, this is when you eat dinner with someone, and accidentally spill a drink on him/her. . If some feature was working at some time in the past, but is no longer working, you can ask CVS to give you the sources from any date. cvs update -D 2001-06-14 will download the Bochs source as they were on June 14, 2001. Again, use -A to clear the sticky date and track the current sources.

Entire books have been written on CVS, so there's no sense in duplicating it all here in the Bochs documentation. Some sources of additional information are listed below. The cvshome.com site has tons of CVS FAQs and documentation, including the official CVS manual by Per Cederqvist. Another CVS FAQ is available at University of Utah.

This section is divided up by platform, since installing a binary package is different on different platforms.

unzip into some directory. Look for DOC-win32.html for more instructions. Quick start: find dlxlinux/start.bat and double click &FIXME; Someone needs to write this.

RPM stands for "RedHat Package Manager." An RPM is a compressed file containing files to be installed on your system. Many Linux distributions, not just RedHat ones, can install files from an RPM. Debian packages are available for Bochs as well, but this section talks deals with RPMs. First, download the Bochs RPM for your architecture to your computer. For example, if you have an Intel-compatible computer, be sure to get the RPM that says "for Linux x86 distributions." Once you have the package on your local disk, you should be able to install it as follows Many distributions have their own RPM installer program, often graphical, and they should work as well. It is helpful to be able to see the text output from RPM, so if you use a fancy RPM installer, be sure to find the text output and check that it looks correct. :

user$ su Password: root# ls -l bochs-1.2.1.i386.rpm -rw-rw-r-- 1 user user 1877515 Sep 14 09:02 bochs-1.2.1.i386.rpm root# rpm -i bochs-1.2.1.i386.rpm Looking for fonts to install... /usr/local/bochs/latest/ Looking for X11 Font Path... /usr/lib/X11/fonts Installing vga.pcf... ok (it was already there) Running mkfontdir... Done installing Bochs fonts for X11. root# exit user$ _

All RPM installations are done as the root user because they require permission to update system files and directories. If you do not have root access you need to compile Bochs in your home directory. If RPM installation fails, try running rpm -e bochs first to erase any old bochs RPMs. VGA Font failure? For now, look at old bochs docs for now for instructions on installing the VGA font by hand. &FIXME; Missing RPM dependencies? Try --nodeps option. The Bochs RPM installs three new commands and associated manual pages: bochs, bochs-dlx, and bximage. First, let's try out the DLX Linux demo by typing bochs-dlx. This command is installed into /usr/local/bin, so you might need to add that directory to your PATH variable. user$ bochs-dlx Checking for bochs binary...ok Checking for DLX linux directory...ok Entering /usr/local/bochs/dlxlinux Running bochs ======================================================================== Bochs x86 Emulator 1.2.1 June 12, 2001 ======================================================================== 00000000000 [ ] looking for configuration in .bochsrc 00000000000 [ ] looking for configuration in bochsrc 00000000000 [ ] looking for configuration in bochsrc.txt 00000000000 [ ] reading configuration from bochsrc.txt 00000000000 [ ] using log file bochsout.txt Then you get a new X11 window containing the VGA display of the simulated machine. First you see the VGA BIOS screen, then Linux uncompresses and boots, and you get a login prompt. Type "root" and ENTER to log in to DLX linux.

If you get the DLX Linux screen, your Bochs installation is working correctly. This documentation will assume that everything is working as expected, then there are some tips at the end in case any step goes wrong. &FIXME; Point to all the files that get installed with the RPM: binaries, BIOSes, DLX linux, HTML docs and man pages, etc.

Bochs is written in C++, so you need a C++ compiler on your system. Most platforms have been tested with GNU gcc/g++, but other compilers are known to work too. By now, you should have unpacked your source TAR file or checked out Bochs from CVS. If not, you can return to Downloading Bochs for details. The top level directory of the source code will be referred to as &bochsdir;. (&bochsdir; contains the files bochs.h and main.cc and subdirectories cpu and bios.) The standard compile process has three basic steps: configure, make, and make install. Each step is described in a separate section below. The standard compile process is used on all Unix machines, MacOS X, BeOS, and Cygwin (win32). There are separate instructions for compiling for Win32 with Microsoft VC++.

There is a script called configure which tests your machine, C/C++ compiler and libraries to discover what settings should work on your system. If you run configure with no arguments after it, defaults will be used for all settings. To change the settings, you can run configure with options that override the defaults. You can get a list of valid configure options by typing configure --help. One useful configure option is --prefix=directory, which sets the directory in which Bochs will be installed. All the possible configure options are documented in a later section. Among other things, the configure script tries to detect your platform and which compile options to use. If you want to control this, set these environment variables before running configure: CC, CXX, CFLAGS, CXXFLAGS. Here is an example that sets the environment variables, using bash/ksh The syntax for bash and ksh is given. In csh and variants, use the syntax setenv VARIABLE value to change environment variables. Do not use an equal sign for csh! syntax: export CC=egcs export CXX="$CC" export CFLAGS="-Wall -O2 -m486 -fomit-frame-pointer -pipe" export CXXFLAGS="$CFLAGS" Once the configure script knows what options are selected, it creates a Makefile in every source code directory, and creates $BOCHS/config.h with all the option values written as preprocessor #defines. Now the sources are ready to compile.

In the Bochs source directory, you will see a series of scripts called .conf.platform. These scripts run the configure script for you, with a set of options that are appropriate for that platform. It is not necessary to use the shortcut scripts; they are simply there to show you an example that the developers have used. If a shortcut script is "almost right" for you, just edit it and then run it! If you run a shortcut script, you don't need to run configure manually. Run a shortcut script using Bourne shell, like this: sh .conf.win32-vcpp These .conf.platform have been tested in recent Bochs versions: .conf.linux .conf.sparc .conf.macosx .conf.win32-vcpp .conf.win32-cygwin .conf.AIX.4.3.1 .conf.beos-x86-R4

The make command compiles Bochs. Make is a program used by many software projects that reads the &Makefile; in each source directory and follows the instructions that it finds there. A &Makefile; tells which files depend on which other files, what commands to use to compile and link the code, and more. After you have finished the configure step, just type make to build the source code. The reason that make is so popular is that it is smart about when to compile and when not to compile. If you run make once, it compiles every file. But when you run it again, it checks to see if any source files have been modified; if not, there's nothing to do! For example, the &Makefile; says that main.o depends on main.cc. Knowing this, it will only compile main.cc if it is newer than main.o. Of course, make can only do the right thing if the &Makefile; lists all the dependencies correctly, so human error can sometimes lead make astray. If make refuses to build something that you think it should, or you are getting strange compile errors, try doing make all-clean and then make again. All-clean means to clean up the compiled files in every subdirectory, while make clean means to clean up just the current directory This is different from the terminology of some other projects, and it may cause confusion. Sometimes "clean" implies that all subdirectories are affected. . However, it's important to note that make all-clean leaves the configuration intact. You do not have to run configure again. If you're really in the mood for cleaning, make dist-clean erases all the configuration information too. In theory, after a dist-clean your directory should look much like when you first untarred it or checked it out. There's usually some extra stuff lying around, but the &Makefile; tries at least to erase any files that it created.

Once the program has been built, the next step is typically to run make install to copy the executables, documentation, and other required files into a public place so that all users can use it. &FIXME; We should mention what gets installed, and where. /usr/local/bochs/$VERSION/* /usr/local/bin/bochs (and bximage) /usr/man/man1/bochs*.1 (and bximage.1) make install_dlx option

user$ ls -l bochs-1.2.1.tar.gz -rw-rw-r-- 1 user user 887993 Sep 15 23:24 bochs-1.2.1.tar.gz user$ gunzip -c bochs-1.2.1.tar.gz | tar -xvf - bochs-1.2.1/ bochs-1.2.1/bios/ bochs-1.2.1/bios/BIOS-bochs-2-processors bochs-1.2.1/bios/Makefile.in . . . bochs-1.2.1/patches/NOTES bochs-1.2.1/patches/patch.4meg-pages bochs-1.2.1/patches/patch.goswin-changes user$ cd bochs-1.2.1 user$ ./configure --enable-cdrom creating cache ./config.cache checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes . . . creating misc/Makefile creating dynamic/Makefile creating fpu/Makefile creating config.h user$ make cd iodev && \ make CC="gcc" CXX="c++" CFLAGS="-g -O2 " CXXFLAGS="-g -O2 " LDFLAGS="" LIBS="" X_LIBS="-L/usr/X11R6/lib" X_PRE_LIBS="-lSM -lICE" prefix="/usr/local" exec_prefix="/usr/local" bindir="/usr/local/bin" infodir="" libiodev.a make[1]: Entering directory `/tmp/bochs-1.2.1/iodev' c++ -c -g -O2 -I.. -I../instrument/stubs devices.cc -o devices.o c++ -c -g -O2 -I.. -I../instrument/stubs pic.cc -o pic.o c++ -c -g -O2 -I.. -I../instrument/stubs pit.cc -o pit.o c++ -c -g -O2 -I.. -I../instrument/stubs unmapped.cc -o unmapped.o c++ -c -g -O2 -I.. -I../instrument/stubs cmos.cc -o cmos.o . . . echo done done c++ -o bochs -g -O2 main.o load32bitOShack.o state_file.o pc_system.o osdep.o \ iodev/libiodev.a \ cpu/libcpu.a memory/libmemory.a gui/libgui.a \ fpu/libfpu.a \ -L/usr/X11R6/lib -lSM -lICE -lX11 gcc -c -g -O2 -I. -Iinstrument/stubs misc/bximage.c -o misc/bximage.o c++ -o bximage -g -O2 misc/bximage.o user$ su root# make install cd iodev && \ make CC="gcc" CXX="c++" CFLAGS="-g -O2 " CXXFLAGS="-g -O2 " LDFLAGS="" LIBS="" X_LIBS="-L/usr/X11R6/lib" X_PRE_LIBS="-lSM -lICE" prefix="/usr/local" exec_prefix="/usr/local" bindir="/usr/local/bin" infodir="" libiodev.a make[1]: Entering directory `/tmp/bochs-1.2.1/iodev' . . . /usr/local/bochs/1.2.1/install-x11-fonts Looking for fonts to install... font/ Looking for X11 Font Path... /usr/lib/X11/fonts Installing vga.pcf... ok (it was already there) Running mkfontdir... Done installing Bochs fonts for X11. root# exit user$ _

The standard compile uses the configure script, but the Windows platform cannot run the configure script natively. The current solution to this problem is that the Bochs configure script must be run on a different platform that does support shell scripts, with options that cause it to configure for a Win32 platform instead of the native one. Many people have access to a UNIX machine that could run the configure script, or you can use Cygwin to run the configure script Because Bochs depends so much on the configure script, if you are doing much win32 Bochs development, you should consider downloading Cygwin so that you can run the configure step natively. . Download the Bochs sources on a machine that can run shell scripts. Edit the configure shortcut script .conf.win32-vcpp if you want to adjust configure options. Then type these commands in the Bochs source directory: sh .conf.win32-vcpp make win32_snap These commands will run the configure step, produce VC++ makefiles and workspace files, and pack it all into a .zip file in the directory above the source directory If the source directory is /home/joe/bochs-win32, the resulting .zip file is in /home/joe/bochs-win32.zip. . The .zip file is all ready to transfer to the target Windows machine to be unzipped and compiled. Or, if you run the sh/make steps in Cygwin, you are already on the target machine so you don't need the .zip file. The following options are known to work in VC++, so they are enabled in the configure shortcut file: --enable-cdrom --enable-sb16=win --enable-ne2000 --enable-vbe When you have the Win32 sources transferred to a Windows machine with VC++, find the workspace file called bochs.dsw and load it in VC++. Choose Project:Set Active Project and be sure that "bochs" is selected. Then choose Build:Build bochs.exe. This will build all the required libraries (iodev, cpu, etc.) and the auxiliary programs bximage.exe and niclist.exe. Using workspaces is easy and intuitive, but there is one caveat. The workspaces come directly out of a ZIP file in build/win32/workspace.zip, and they are not integrated with configure. Some configure options such as --enable-debugger need additional source files to be compiled, and for now you must add them to the VC++ workspace by hand. If you add configure options and have compile problems, try the nmake method (below) instead. These problems may be fixed in future versions. To compile with the debugger enabled, add "--enable-debugger" to the configure line in .conf.win32-vcpp before running it. Then when you have loaded the workspace file, you must add the debug and disasm libraries to the project dependency list. Choose Project:Dependencies and make sure that debug and disasm are checked. Then build as usual. An alternative way to compile is to run nmake.exe in an MS-DOS window. Instead of using the workspace files, nmake uses the Bochs makefiles that are generated by configure. The workspace file is new in version 1.3; before that, nmake was the only way to compile Bochs in VC++. If you are having trouble with the workspace, try the nmake compile instead. The make install for Win32 is presently broken. In the future, a make install that runs in Cygwin may be provided.

Cygwin is a free Unix-like environment for Windows written by Steve Chamberlain and now maintained by RedHat, Inc. You can download it from www.cygwin.com. Because Cygwin supports the configure script and uses GNU gcc/g++, you can use the standard compile process. The configure script should automatically detect Cygwin and add "-mno-cygwin -DWIN32" to the compiler options. You should get a working Bochs if you just type: configure make Optionally, you can use the configure shortcut script for Cygwin, .conf.win32-cygwin, instead of running configure directly. If this script is close to what you need, just edit the script and then run it. To use the configure shortcut script and compile in Cygwin, the commands are sh .conf.win32-cygwin make These options are known to work in Cygwin, so they are enabled in the configure shortcut file: --enable-cdrom --enable-sb16=win --enable-ne2000 --enable-vbe

It is possible that this hasn't been tried since 1999. In theory, you run sh .conf.macos on a Unix box to build the makefiles and headers, copy the whole thing over to a Mac, and then use CodeWarrior to compile. Since it hasn't been tested in so long, it is quite likely that some work is needed to bring the Mac port up to date. If you are interested and have the required MacOS development tools, please let use know. Someone requests a MacOS port almost once a month, but none of the developers know how to help them.

The port to MacOS X with Carbon API by Emmanuel Mailliard is quite new, and the configure and makefile support was added by Bryce Denney. You will need the compiler and libraries from the development tools CD. Bochs should configure and compile with the Carbon GUI if you simply type: configure make Optionally, you can use the configure shortcut script for MacOS X, .conf.macosx, instead of running configure directly. If this script is close to what you need, just edit the script and then run it. To use the configure shortcut script and compile, the commands are sh .conf.macosx make MacOS X has a special format for an application bundle, which looks like a directory that contains the required resource files and binaries. The Makefile currently creates this application bundle "by hand" using mkdir and copy, which is surely the wrong way to do it. Bryce doesn't know the official way to create an application from a Makefile, so this hack will remain until a real Mac developer helps to clean it up. On MacOS X the default GUI is the Carbon interface, but you can also try other Bochs GUIs. Use --enable-x11 for X windows, --enable-rfb for VNC/RFB, or --enable-sdl for SDL.

Kevin Lawton ported Bochs to BeOS. Bernd Korz has taken over the port, and is working on raw cdrom and raw floppy support. As of Bochs 1.4, it should compile if you just type "configure && make", because configure will detect the BeOS platform and assume you want the BeOS GUI. Optionally, you can use the configure shortcut script for BeOS, .conf.beos-x86-R4.

Nicholai Benalal created this port to MorphOS running on Amiga. It should compile with configure && make If the platform is not detected properly, you might need to use --enable-amigaos as a configure option. Optionally, you can use the configure shortcut script, .conf.amigaos.

Don Becker's RFB interface allows you to view the Bochs display with the AT&T's VNC Viewer. The protocol used between a VNC server and a VNC viewer is called RFB. Because the RFB code in Bochs is written with portable network socket and POSIX thread code, it can be compiled on many platforms. No additional libraries are required. To try it, type: configure --with-rfb make

Dave Poirier has written an SDL interface for Bochs. Simple DirectMedia Layer, or SDL, is a cross-platform multimedia library distributed from libsdl.org. SDL supports Win32, Linux, IRIX, MacOS, MacOS X, BeOS, and AmigaOS. To compile Bochs with the SDL interface you need to download the SDL development library. Either get the development library for your platform, or download the sources and compile it yourself. Then, go into the Bochs directory and type: configure --with-sdl make This has only been tested on Linux at the time this documentation was written. To compile in Microsoft VC++, you have to configure on a different system. Here's the procedure: - On a machine that can run shell scripts, such as Cygwin, run configure --target=pentium-windows --with-sdl make win32_snap - Copy the resulting ZIP file to your Windows box and unzip it. - Load up workspace called bochs.dsw in VC++ 6.0 - Double click "gui files" - Remove gui/win32.cpp from the project, and add gui/sdl.cpp instead. - Edit the settings of "gui files". Under C/C++ tab, category=preprocessor, additional include directories, add the directory where SDL/SDL.h can be found. - Edit the settings of the "bochs files" project. Under the Link tab, category=General, add SDL.lib to object/library modules list. Then in category=Input, add the path of SDL.lib to additional library path. Click ok. - Select Build:Build Bochs.exe

RPM stands for "RedHat Package Manager." An RPM is a compressed file containing files to be installed on your system. Bochs has a special shell script called make-rpm that helps to build an RPM of Bochs. Start with a clean source directory. Edit .conf.linux first if you want to adjust the configure options. Then, type: su root Password: type root password ./build/redhat/make-rpm When this command completes, you will have a source RPM and a binary RPM of Bochs, probably under /usr/src/redhat/RPMS. The output of the make rpm will tell you the exact location of these new files. Instructions for installing an RPM are here.

This section describes the configure options for Bochs. Perhaps the most important option is --help, since it gives you a list of all the other options. The configure script will detect your platform and choose the default GUI for your platform. If the default choice is not what you want, use a --with-* option to override the default. The options in the first table tell which GUI library is the default for each platform. The concept of platform detection and default GUIs was added in Bochs 1.4. In Bochs 1.3 and before, the X11 gui was always the default. Platform Default GUI Extra compile flags win32 or Cygwin --with-win32 If using nmake method, compile using cl /nologo /G6 /MT /W3 /GX /DNDEBUG /DWIN32 /D_WINDOWS /O2. If using Visual C++ workspace, see the workspace file for compile settings. See Compiling on Win32 with Microsoft VC++ for instructions. MacOS X or Darwin --with-carbon -fpascal-strings -fno-common -arch ppc -Wno-four-char-constants -Wno-unknown-pragmas -Dmacintosh MacOS 9 or before --with-macos none BeOS --with-beos none AmigaOS --with-amigaos none any other platform --with-x11 none Option Comments --with-x11 Use X windows user interface. On many operating systems, Bochs will use X windows by default. --with-win32-vcpp Use Win32 GUI/Visual C++ environment. This is for running configure on a platform which supports running configure, so that you may then transfer the configured code over to an MS Win32/Visual C++ environment. See for details. --with-win32 Use Win32 GUI, but compile with a Win32/gcc environment such as Cygwin. For Cygwin, see .conf.win32-cygwin for the correct compile options. --with-carbon Compile for MacOS X with the Carbon GUI. See the .conf.macosx file for the correct MacOS X compile options. --with-amigaos Compile for Amiga MorphOS. This code is written by Nicholai Benalal. --with-rfb Use RFB protocol to talk to AT&T's VNC Viewer. The RFB code was written by Don Becker x-odus@iname.com, who has a Bochs-RFB web page on his site, http://www.psyon.org/bochs-rfb. RFB mode has been tested in Linux and Win32. --with-sdl This option enables Dave Poirier's SDL gui interface. To compile with SDL, you must first install the SDL library from libsdl.org. You can either get the source code and compile it yourself, or install the development libraries for your platform (already compiled). SDL is available for many platforms including Win32, Linux, IRIX, MacOS, MacOS X, and BeOS. --with-beos Use BeOS GUI. The configure script will run natively on BeOS; use this option when doing so. --with-term Use text-only gui with curses library. Almost certainly won't work right with the debugger or the control panel. --with-macos Use Macintosh/CodeWarrior environment. This is for running configure on a platform which supports running configure, so that you may then transfer the configured code over to the real compile environment. (Hasn't been tested in a long time.) --with-nogui No native GUI; just use blank stubs. This is if you don't care about having video output, but are just running tests. The remaining options can generally be used with any GUI. For each option such as --enable-cdrom, you can also write --disable-cdrom to explicitly turn it off. Option Default Comments --enable-cpu-level={3,4,5,6} 5 Select which CPU level to emulate. Choices are 3,4,5,6 which mean to target 386, 486, Pentium, or Pentium Pro emulation. Pentium Pro support is quite incomplete, so level 5 is the best choice for now. --enable-cdrom no Enable use of a real CDROM. The cdrom emulation is always present, and emulates a drive without media by default. You can use this option to compile in support for accessing the media in your workstation's cdrom drive. The supported platforms are Linux, Solaris, OpenBSD, and Windows. For other platforms, a small amount of code specific to your platform must be written. The module iodev/cdrom.cc is the place to add more support. For the most part, you need to figure out the right set of ioctl() calls. --enable-sb16={dummy, win, linux} no Enable Sound Blaster emulation. SB16 output is only supported for Windows or Linux. The dummy option means to support an SB16, but don't use an output device. So for example, you might use --enable-sb16=linux. Check out &FIXME; sound.html for more info. --enable-control-panel yes Enables text-mode configuration menus when you first start Bochs. The menus let you read in a bochsrc file, edit some options, and save the new bochsrc before starting the simulation. Also enables a runtime menu (controlled by a Config button on the Bochs display) which lets you change certain settings during simulation. The control panel was added by Bryce Denney. --enable-new-pit yes Enables Greg Alexander's PIT model, written during Summer 2001. This model was written from scratch to be much more complete than the old Bochs PIT model, which was missing many registers and features. If you disable this option, the old PIT model will be used instead. --enable-slowdown no Enables Greg Alexander's experimental "slowdown timer" which tries to keep the Bochs simulation time in sync with real time. When Bochs is executing many instructions, the slowdown timer will have no effect. When Bochs is idle, or just waiting around for an interrupt, the slowdown timer kicks in to prevent Bochs time from speeding ahead. This should solve problems like, "Why does my screen saver turn on after 30 seconds?" --enable-idle-hack no Enables Roland Mainz's experimental idle code, which is intended to keep Bochs from always using 100% of CPU time. When Bochs is waiting around for an interrupt, the idle code uses a select() loop and some X11 tricks to wait until user input arrives. This is designed to keep Bochs responsive while still yielding to other processes when Bochs is idle. --enable-ne2000 no Enable NE2000 network card support. This requires a low-level component to be written for each OS. The NE2000 option is only supported on FreeBSD, OpenBSD, Linux, and Windows 95/98/NT/2K. When enabled and configured, the NE2000 device model can talk to any computer on the network EXCEPT FOR the local host. Exception: Under most circumstances, Bochs can talk to the local host on Windows, and in the ethertap interface for Linux. --enable-vga yes Use VGA emulation. VGA is the only supported option and since it's the default, you don't need to include this option. --enable-vbe yes Use VGA BIOS Extensions (VBE) by Jeroen Janssen. To take advantage of the VBE, you must tell Bochs to use the LGPL VGA BIOS version 0.3a or higher in the vgaromimage line of your bochsrc file. --enable-fpu yes If you want to compile bochs to make use of the FPU emulator written by Bill Metzenthen (the one used by the Linux kernel), use this option. --enable-split-hd yes When enabled, this allows a series of partial hard disk image files to be treated as if it was one large file. The .bochsrc specifies the first partial HD image (example win95-1) and then bochs searches for the other partial images in as a sequence (win95-2, win95-3, etc.) and opens them all. Then, it treats the series as if there was a single large file created by "cat win95-1 win95-2 win95-3". This trick works for both diskc and diskd. All files must be a multiple of 512 bytes. --enable-debugger no Compile in support for Bochs internal command-line debugger. This has nothing to do with x86 hardware debug support. It is a more powerful and non-intrusive native debugger. Enabling this will of course slow down the emulation. You only need this option if you know you need it. After you have run ./configure, you may want to edit 'config.h' to customize the debugger further. Look at the section entitled 'OPTIONAL DEBUGGER SECTION'. &FIXME; add cross references --enable-disasm no Compile in support for built-in disassembler. Bochs has a built-in disassembler, which is useful if you either run the built-in debugger (--enable-debugger), or want disassembly of the current instruction when there is a panic in bochs. You don't need this option. --enable-cpp no Use .cpp as C++ suffix. Renames all the .cc files to .cpp for use with compilers which want that, like MS C++ compilers. Don't use this option unless you know you need it. The configure shortcut script for Win32 uses this option. Option Default Comments --enable-iodebug yes if debugger is on Dave Poirier has written an experimental interface to the debugger using I/O ports, so that software running in the guest OS can access features of the debugger. You only want this option if you are developing guest OS code for use in Bochs. In other words, most people don't. Also, it should only be used with --enable-debugger. See section &FIXME; in the Developer's Guide for details. --enable-x86-debugger no X86 debugger support. If the software you run in bochs needs to use the x86 hardware debugging facilities such as DR0..DR8, instruction and data breakpoints etc., then you should use this option. Otherwise don't use it, as it will slow down the emulation. --enable-pci no Enable limited i440FX PCI support. This is not complete. Don't use this option. --enable-port-e9-hack no Writes to port e9 go to console. Unless you know you want this option, you don't. --enable-processors={1,2,3,...,15} 1 By changing to more than 1 processor, you enable SMP simulation. This allows you to boot Linux and maybe other OSes in SMP mode, and bochs will simulate all the different CPUs and communication between them. Do not expect this option to speed up your simulation! On the contrary, it has to spend extra time simulating the different CPUs (even if they're mostly idle) and the communication between them. Use it to try out an SMP OS if you don't have an SMP machine, or to debug SMP OS drivers. Click here for more details on SMP in Bochs. --enable-apic no In an SMP machine, there is an APIC (Advanced Programmable Interrupt Controller) built into each processor and a separate I/O APIC. The APICs are used for inter-processor communication, so they must be enabled for SMP to work. The default is "no" when there is one processor and "yes" when there is more than one processor. Normally, the default is correct and you would never need to type this option. --enable-instrumentation=directory no Compile in support for instrumentation. This allows you to collect instrumentation data from bochs as it executes code. You have to create your own instrumentation library and define the instrumentation macros (hooks in bochs) to either call your library functions or not, depending upon whether you want to collect each piece of data. [Kevin wrote: I broke some of the hooks when I recoded the fetch/decode loop.] --enable-simid={0, 1} 0 CPU simulator ID. You likely don't need this option. If you are using bochs to cosimulate, that is to run multiple simulators in parallel so that you can compare results and check for divergence, each simulator needs an ID. When you only have one CPU simulator (as usual) the default of 0 is fine. [Kevin wrote: I use this option occasionally to run 2 versions of bochs against each other and check for divergence, to find bugs etc. This option gets broken more than not due to architectural changes, and I usually end of fixing it each time I use it.] --enable-num-sim={1, 2} 1 Number of CPU simulators. The default of 1 is likely what you want, so don't use this option. It is for assigning an ID to the simulator, for cosimulation described above. --enable-time0=n no Start CMOS clock at at time0 of n instead of using time(). You likely don't want this option. When debugging, it is very helpful to have deterministic execution, and the clock is something that can skew determinism. If you supply this option, pass it a value returned by the time(NULL) call, relating to the time you want bochs to start the CMOS clock from. For instance, '--enable-time0=917385580'. If you use this option but don't provide a value, configure uses a default value. Note that the time0 option in .bochsrc will override this value. Without this option, the CMOS clock uses a time0 based on the value of time(NULL), which is probably what you want. --enable-hga-dumps=Nmicroseconds no Copy memory to HGA video buffer every N useconds. A deprecated option, don't use.

&FIXME; what if configure fails? - tar up config.* and send to bochs-testing@tlw.com - report the problem with a source forge bug report. what if make fails? - try make dist-clean, and run configure and make again - use configure options to disable options. For example, if errors in fpu/fpu_system.h, you could try --disable-fpu. - search for the error on the Bochs website (bug reports, patches) - if familiar with C++, many minor problems can be corrected - move to more stable code. if it's CVS, see if a release version will compile. Report problem to bochs-developers. - report the problem with a source forge bug report.

&FIXME; - bochsrc, BIOS, VGABIOS, VGA font, disk images. - (DONE) table of bochsrc options and what they do - BIOS/VGABIOS, what do they do? - VGA font, how to install it - disk images - where to find one pre-made - make a blank one with bximage - grab one from a real hard disk

Bochs uses a configuration file called a bochsrc to know where to look for disk images, how the Bochs emulation layer should work, etc. When you first start up Bochs, it looks around for its configuration file, and parses it. Here are a few lines from a sample file: diskc: file="30M.sample", cyl=615, heads=6, spt=17 boot: c The format is very strict, so be sure to put the right number of spaces and use lowercase letters. As you can see, most lines have a keyword telling what is being configured, followed by a colon, followed by a few variable=value pairs, separated by commas. For very simple options, sometimes just a single value is needed. The source and binary distributions come with a sample bochsrc, so you can just copy the sample file and edit the settings you need to change. The section below lists all the supported bochsrc options.

Examples: romimage: file=bios/BIOS-bochs-latest, address=0xf0000 You need to load a ROM BIOS into addresses 0xf0000-0xfffff. The BIOS controls what the PC does when it first powers on. Normally, you can use a precompiled BIOS in the source or binary distribution called BIOS-bochs-latest.

Examples: megs: 32 megs: 128 Set this to the default number of megabytes of memory you want to emulate. The default is 32, since most operating systems won't need more than that.

Example: optromimage1: file=optionalrom.bin, address=0xd0000 This enables Bochs to load up to 4 optional ROM images. Be sure to use a read-only area, typically between C8000 and EFFFF. These optional ROM images should not overwrite the rombios (located at F0000-FFFFF) and the videobios (located at C0000-C7FFF). Those ROM images will be initialized by the bios if they contain the right signature (0x55AA). It can also be a convenient way to upload some arbitary code/data in the simulation, that can be retrieved by the boot loader

Examples: vgaromimage: bios/VGABIOS-elpin-2.40 vgaromimage: bios/VGABIOS-lgpl-latest You also need to load a VGA ROM BIOS at 0xC0000. A VGA BIOS file from Elpin Systems, Inc. is provided in the source and binary distributions. A free LGPL'd VGA BIOS is also provided in the source and binary distributions.

Examples: 2.88M 3.5" Floppy: floppya: 2_88=a:, status=inserted 1.44M 3.5" Floppy: floppya: 1_44=floppya.img, status=inserted 1.2M 5.25" Floppy: floppyb: 1_2=/dev/fd0, status=inserted 720K 3.5" Floppy: floppya: 720k=/usr/local/bochs/images/win95.img, status=inserted Floppya is the first drive, and floppyb is the second drive. If you're booting from a floppy, floppya should point to a bootable disk. To read from a disk image, write the name of the image file. In many operating systems Bochs can read directly from a raw floppy drive. For raw disk access, use the device name (Unix systems) or the drive letter and a colon (Windows systems). You can set the initial status of the media to ejected or inserted. Usually you will want to use inserted. In fact Bryce can't think of any reason to ever write ejected in your bochsrc.

Examples: ata0: enabled=1, ioaddr1=0x1f0, ioaddr2=0x3f0, irq=14 ata1: enabled=1, ioaddr1=0x170, ioaddr2=0x370, irq=15 ata2: enabled=1, ioaddr1=0x1e8, ioaddr2=0x3e8, irq=11 ata3: enabled=1, ioaddr1=0x168, ioaddr2=0x368, irq=9 These options enables up to 4 ata channels. For each channel the two base io addresses and the irq must be specified. ata0 is enabled by default, with ioaddr1=0x1f0, ioaddr2=0x3f0, irq=14

Examples: ata0-master: type=disk, path=10M.img, cylinders=306, heads=4, spt=17, translation=none ata1-master: type=disk, path=2GB.img, cylinders=5242, heads=16, spt=50, translation=echs ata1-slave: type=disk, path=3GB.img, cylinders=6541, heads=16, spt=63, translation=auto ata2-master: type=disk, path=7GB.img, cylinders=14563, heads=16, spt=63, translation=lba ata2-slave: type=cdrom, path=iso.sample, status=inserted This defines the type and characteristics of all attached ata devices: Option Comments Possible values type type of attached device [disk|cdrom] path path of the image cylinders only valid for disks heads only valid for disks spt only valid for disks status only valid for cdroms [inserted|ejected] biosdetect type of biosdetection [none|auto], only for disks on ata0 [cmos] translation type of translation done by the bios (legacy int13), only for disks [none|lba|large|rechs|auto] model string returned by identify device command You have to tell the type of the attached device. For Bochs version2.0, it can by disk or cdrom You have to point the "path" at a hard disk image file, cdrom iso file, or physical cdrom device. To create a hard disk image, try running bximage. It will help you choose the size and then suggest a line that works with it. In UNIX it is possible to use a raw device as a Bochs hard disk, but WE DON'T RECOMMEND IT for safety reasons. The path, cylinders, heads, and spt are mandatory for type=disk The path is mandatory for type=cdrom The disk translation scheme (implemented in legacy int13 bios functions, and used by older operating systems like MS-DOS), can be defined as: none : no translation, for disks up to 528MB (1032192 sectors) large : a standard bitshift algorithm, for disks up to 4.2GB (8257536 sectors) rechs : a revised bitshift algorithm, using a 15 heads fake physical geometry, for disks up to 7.9GB (15482880 sectors). (don't use this unless you understand what you're doing) lba : a standard lba-assisted algorithm, for disks up to 8.4GB (16450560 sectors) auto : autoselection of best translation scheme. (it should be changed if system does not boot)

The diskc and diskd options are deprecated. Use "ataX-*: type=disk,..." options instead. Examples: diskc: file=10M.img, cyl=306, heads=4, spt=17 diskc: file=112M.img, cyl=900, heads=15, spt=17 diskd: file=483.img, cyl=1024, heads=15, spt=63 The diskc/diskd lines tell Bochs what disk image file to use as the constants of the emulated hard drive, and what geometry it should have. Diskc is the first hard drive, and diskd is the second hard drive. Using a raw hard drive is possible under on unix but WE DON'T RECOMMEND IT for safety reasons. The file should be a disk image file, which must be exactly 512*cyl*heads*spt bytes long. The geometry settings are cylinder (cyl), heads, and sectors per track (spt). If you use bximage to create the image, it will give you the required cyl, head, and spt information. You cannot use both diskd and cdromd together.

The cdromd option is deprecated. Use "ataX-*: type=cdrom,..." option instead. Examples: cdromd: dev=/dev/cdrom, status=inserted (Unix only) cdromd: dev=e:, status=inserted (Windows only) cdromd: dev=cdromimage.iso, status=inserted The cdromd line tells Bochs to emulate a CD-ROM device. You cannot have both a diskd and a cdromd, and there is no cdromc option. You cannot use both diskd and cdromd together.

Examples: newharddrivesupport: enabled=1 This setting enables support for large hard disks, better CD recognition, and various other useful functions. You can set it to "enabled=1" (on) or "enabled=0" (off). It is recommended that this setting is left on unless you are having trouble with it.

Examples: boot: floppy boot: disk boot: cdrom This defines your boot drive. You can either boot from 'floppy', 'disk' or 'cdrom'. 'c' and 'a' are also accepted for historical reasons.

Example: floppy_bootsig_check: disabled=1 This disables the 0xaa55 signature check on boot floppies The check is enabled by default.

Examples: log: bochs.out log: /dev/tty (unix only) log: /dev/null (unix only) Give the path of the log file you'd like Bochs debug and misc. verbage to be written to. If you really don't want it, make it /dev/null.

Examples: logprefix: %t-%e-@%i-%d logprefix: %i%e%d This handles the format of the string prepended to each log line. You may use those special tokens : %t : 11 decimal digits timer tick %i : 8 hexadecimal digits of cpu0 current eip %e : 1 character event type ('i'nfo, 'd'ebug, 'p'anic, 'e'rror) %d : 5 characters string of the device, between brackets Default is %t%e%d

Examples: debug: action=ignore info: action=report error: action=report panic: action=ask During simulation, Bochs encounters certain events that the user might want to know about. These events are divided into four levels of importance: debug, info, error, and panic. Debug messages are usually only useful when writing Bochs code or when trying to locate a problem. There may be thousands of debug messages per second, so be careful before turning them on. Info messages tell about interesting events that don't happen that frequently. Bochs produces an "error" message when it finds a condition that really shouldn't happen, but doesn't endanger the simulation. An example of an error might be if the emulated software produces an illegal disk command. Panic messages mean that Bochs cannot simulate correctly and should probably shut down. A panic can be a configuration problem (like a misspelled bochsrc line) or an emulation problem (like an unsupported video mode). The debug, info, error, and panic lines in the bochsrc control what Bochs will do when it encounters each type of event. The allowed actions are: fatal (terminate bochs), ask (ask the user what to do), report (print information to the console or log file), or ignore (do nothing). The recommended settings are listed in the sample above. The safest action for panics is "fatal" or "ask". If you are getting lots of panics and get tired of telling it to continue each time, you can try action=report instead. If you allow Bochs to continue after a panic, don't be surprised if you get strange behavior or crashes after a panic occurs. Please report panic messages to the bochs-developers mailing list unless it is just a configuration problem like "could not find hard drive image."

Specifies the device to use as com1. This can be a real serial line, or a pty. To use a pty (under X/Unix), create two windows (xterms, usually). One of them will run bochs, and the other will act as com1. Find out the tty the com1 window using the `tty' command, and use that as the `dev' parameter. Then do `sleep 1000000' in the com1 window to keep the shell from messing with things, and run bochs in the other window. Serial I/O to com1 (port 0x3f8) will all go to the other window. Examples: com1: dev=/dev/ttyp9 com1: dev=/dev/cua0

This defines a parallel (printer) port. When turned on and an output file is defined emulated printer port sends characters printed by the guest OS into the output file. On some platforms a device filename can be used to send the data to the real parallel port (e.g. "/dev/lp0" on Linux, "lpt1" on win32 platforms). Examples: parport1: enabled=1, file="parport.out" parport1: enabled=1, file="/dev/lp0" parport1: enabled=0

Examples: sb16: midimode=1, midi=/dev/midi00, wavemode=1, wave=/dev/dsp, loglevel=2, log=sb16.log, dmatimer=600000 The example is wrapped onto several lines for formatting reasons, but it should all be on one line in the actual bochsrc file. The sb16 line defines Sound Blaster 16 emulation. It can have several of the following properties. All properties are in the usual "property=value" format. midi: The filename is where the midi data is sent. This can be a device or just a file if you want to record the midi data. midimode: 0 = No data should be output. 1 = output to device (system dependent - midi denotes the device driver). 2 = SMF file output, including headers. 3 = Output the midi data stream to the file (no midi headers and no delta times, just command and data bytes). wave: This is the device/file where wave output is stored. wavemode: 0 = no data 1 = output to device (system dependent - wave denotes the device driver). 2 = VOC file output, including headers. 3 = Output the raw wave stream to the file. log: The file to write the sb16 emulator messages to. loglevel: 0 = No log. 1 = Only midi program and bank changes. 2 = Severe errors. 3 = All errors. 4 = All errors plus all port accesses. 5 = All errors and port accesses plus a lot of extra information. dmatimer: Microseconds per second for a DMA cycle. Make it smaller to fix non-continuous sound. 750000 is usually a good value. This needs a reasonably correct setting for IPS (see below).

Examples: vga_update_interval: 250000 Video memory is scanned for updates and screen updated every so many virtual seconds. The default is 300000, about 3Hz. This is generally plenty. Keep in mind that you must tweak the 'ips:' directive to be as close to the number of emulated instructions-per-second your workstation can do, for this to be accurate.

Example: keyboard_serial_delay: 200 Approximate time in microseconds that it takes one character to be transfered from the keyboard to controller over the serial path.

Approximate time in microseconds between attempts to paste characters to the keyboard controller. This leaves time for the guest os to deal with the flow of characters. The ideal setting depends on how your operating system processes characters. The default of 100000 usec (.1 seconds) was chosen because it works consistently in Windows. Example: keyboard_paste_delay: 100000

Examples: floppy_command_delay: 50000 Time in microseconds to wait before completing some floppy commands such as read, write, seek, etc., which normally have a delay associated. This was once hardwired to 50000 but now you can adjust it.

Examples: ips: 1000000 Emulated Instructions Per Second. This is the number of IPS that bochs is capable of running on your machine. You can recompile Bochs, using instructions included in config.h (in the source code), to find your workstation's capability. IPS is used to calibrate many time-dependent events within the bochs simulation. For example, changing IPS affects the frequency of VGA updates, the duration of time before a key starts to autorepeat, and the measurement of BogoMips and other benchmarks. The table below lists some typical IPS settings for different machinesIPS measurements depend on OS and compiler configuration in addition to processor clock speed.. Speed Machine Typical IPS 650MhzAthlon K-7 with Linux 2.4.x 2 to 2.5400MhzPentium II with Linux 2.0.x 1 to 1.8166Mhz64bit Sparc with Solaris 2.x 0.75200MhzPentium with Linux 2.x 0.5

Examples: mouse: enabled=1 mouse: enabled=0 This option prevents Bochs from creating mouse "events" unless a mouse is enabled. The hardware emulation itself is not disabled by this. You can turn the mouse on by setting enabled to 1, or turn it off by setting enabled to 0. Unless you have a particular reason for enabling the mouse by default, it is recommended that you leave it off. You can also toggle the mouse usage at runtime (middle mouse button on X11 and SDL, F12 on Win32).

Examples: private_colormap: enabled=1 Requests that the GUI create and use its own non-shared colormap. This colormap will be used when in the bochs window. If not enabled, a shared colormap scheme may be used. Once again, enabled=1 turns on this feature and 0 turns it off.

The ne2k line configures an emulated NE2000-compatible Ethernet adapter, which allows the guest machine to communicate on the network. To disable the NE2000 just comment out the ne2k line. Examples: ne2k: ioaddr=0x280, irq=9, mac=b0:c4:20:00:00:00, ethmod=fbsd, ethdev=xl0 ne2k: ioaddr=0x280, irq=9, mac=b0:c4:20:00:00:00, ethmod=linux, ethdev=eth0 ne2k: ioaddr=0x280, irq=9, mac=b0:c4:20:00:00:01, ethmod=win32, ethdev=MYCARD ne2k: ioaddr=0x280, irq=9, mac=fe:fd:00:00:00:01, ethmod=tap, ethdev=tap0 ne2k: ioaddr=0x280, irq=9, mac=fe:fd:00:00:00:01, ethmod=tuntap, ethdev=tun0, script=./tunconfig ioaddr, irc: You probably won't need to change ioaddr and irq, unless there are IRQ conflicts. mac: The MAC address MUST NOT match the address of any machine on the net. Also, the first byte must be an even number (bit 0 set means a multicast address), and you cannot use ff:ff:ff:ff:ff:ff because that's the broadcast address. For the ethertap module, you must use fe:fd:00:00:00:01. There may be other restrictions too. To be safe, just use the b0:c4... address. ethmod: The ethmod value defines which low level OS specific module to be used to access pysical ethernet interface. Current implemented values include : - fbsd : ethernet on freebsd and openbsd - linux : ethernet on linux - win32 : ethernet on win32 - tap : ethernet through a linux tap interface - tuntap : ethernet through a linux tuntap interface ethdev: The ethdev value is the name of the network interface on your host platform. On UNIX machines, you can get the name by running ifconfig. On Windows machines, you must run niclist to get the name of the ethdev. Niclist source code is in misc/niclist.c and it is included in Windows binary releases. script: The script value is optionnal, and is the name of a script that is executed after bochs initialize the network interface. You can use this script to configure this network interface, or enable masquerading. This is mainly useful for the tun/tap devices that only exist during Bochs execution. The network interface name is supplied to the script as first parameter

Examples: keyboard_mapping: enabled=0, map= keyboard_mapping: enabled=1, map=gui/keymaps/x11-pc-de.map This enables a remap of a physical localized keyboard to a virtualized U.S. keyboard, as the PC architecture expects. If enabled, the keymap file must be specified.

Examples: keyboard_type: xt keyboard_type: at keyboard_type: mf Type of keyboard returned by a "identify keyboard" command to the keyboard controller. It must be one of "xt", "at" or "mf". Defaults to "mf". It should be ok for almost everybody. A known exception is French macs, that do have a "at"-like keyboard.

Examples: user_shortcut: keys=ctrlaltdel user_shortcut: keys=ctrlaltesc This defines the keyboard shortcut to be sent when you press the "user" button in the headerbar. These shortcuts are currently recognized: ctrlaltdel, ctrlaltesc, ctrlaltf1, alttab

Christophe Bothamy wrote the keymapping code for Bochs, and provided this documentation for how to create new keymaps. Keymapping is currently implemented for X windows only, so there are many references to X-specific values in this section. The standard US Keyboard looks like this: ------------------------------------------- Top row Esc F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12 ------------------------------------------- 2nd row ` 1 2 3 4 5 6 7 8 9 0 - = \ Back ------------------------------------------- 3rd row Tab Q W E R T Y U I O P [ ] Enter ------------------------------------------- 4rd row Caps A S D F G H J K L ; ' ------------------------------------------- 5rd row lShift l\ Z X C V B N M , . / rShift ------------------------------------------- 6rd row lCtrl lAlt Space rAlt rCtrl ------------------------------------------- Each key of the US keyboard maps to a Bochs constant named BX_KEY_symbol. You can find the current list of BX_KEY_symbol in the BX_KEY table, below. Please note that there is only one BX_KEY_symbol for each physical key. Now, for each key of the US keyboard, look at which symbols you can type on your real keyboard. Each symbol maps to a X-windows XK_symbol constant. In X11/keysymdef.h, you will find the list of all possible XK_symbol on your system. Alternatively, you can use a small utility called "xev" that prints out the symbol names of a pressed key. Note that the symbol name given by xev does not contain the XK_ prefix. Don't forget to add a line for every symbol you can type on each key. For the key BX_KEY_A, you can type both lowercase 'a' and uppercase 'A', so you would need two different entries. You can then create your own map file. Keymap files are found in the "gui/keymaps" directory in the source code, or in the "keymaps" directory in binary releases. Look at the existing keymap file as an example, and create a file containing one line for each symbol. The first column tells what key or combination of keys can be used to produce a given symbol. The second column is the ASCII equivalent for that symbol, or a special keyword (none, space, return, tab, backslash, or apostrophe). The third column is the X windows keysym for that symbol. For example : BX_KEY_0 '0' XK_0 BX_KEY_1 '1' XK_1 BX_KEY_2 '2' XK_2 BX_KEY_0+BX_KEY_SHIFT_L ')' XK_parenright BX_KEY_1+BX_KEY_SHIFT_L '!' XK_exclam BX_KEY_2+BX_KEY_SHIFT_L '@' XK_at BX_KEY_A 'a' XK_a BX_KEY_B 'b' XK_b BX_KEY_A+BX_KEY_SHIFT_L 'A' XK_A BX_KEY_B+BX_KEY_SHIFT_L 'B' XK_B BX_KEY_TAB tab XK_Tab BX_KEY_ENTER return XK_Return BX_KEY_F1 none XK_F1 BX_KEY_F2 none XK_F2 BX_KEY_F3 none XK_F3 Now that there are several keymap files in the Bochs distribution, it is easiest to copy an existing keymap and follow the examples you see. When it works, be sure to send it to the mailing list or post it on Source Forge so that we can include it in the next release. You may need to look up some of your country specific X11 symbols in X11/keysymdef.h. BX_KEY constant Keyboard Symbol BX_KEY_CTRL_L left Ctrl BX_KEY_SHIFT_L left Shift BX_KEY_F1 F1 BX_KEY_F2 F2 BX_KEY_F3 F3 BX_KEY_F4 F4 BX_KEY_F5 F5 BX_KEY_F6 F6 BX_KEY_F7 F7 BX_KEY_F8 F8 BX_KEY_F9 F9 BX_KEY_F10 F10 BX_KEY_F11 F11 BX_KEY_F12 F12 BX_KEY_CTRL_R right Ctrl BX_KEY_SHIFT_R right Shift BX_KEY_CAPS_LOCK CapsLock BX_KEY_NUM_LOCK NumLock BX_KEY_ALT_L left Alt BX_KEY_ALT_R right Alt BX_KEY_A A BX_KEY_B B BX_KEY_C C BX_KEY_D D BX_KEY_E E BX_KEY_F F BX_KEY_G G BX_KEY_H H BX_KEY_I I BX_KEY_J J BX_KEY_K K BX_KEY_L L BX_KEY_M M BX_KEY_N N BX_KEY_O O BX_KEY_P P BX_KEY_Q Q BX_KEY_R R BX_KEY_S S BX_KEY_T T BX_KEY_U U BX_KEY_V V BX_KEY_W W BX_KEY_X X BX_KEY_Y Y BX_KEY_Z Z BX_KEY_0 0 BX_KEY_1 1 BX_KEY_2 2 BX_KEY_3 3 BX_KEY_4 4 BX_KEY_5 5 BX_KEY_6 6 BX_KEY_7 7 BX_KEY_8 8 BX_KEY_9 9 BX_KEY_ESC Esc BX_KEY_SPACE SpaceBar BX_KEY_SINGLE_QUOTE ' BX_KEY_COMMA , BX_KEY_PERIOD . BX_KEY_SLASH / BX_KEY_SEMICOLON ; BX_KEY_EQUALS = BX_KEY_LEFT_BRACKET [ BX_KEY_BACKSLASH \ BX_KEY_RIGHT_BRACKET ] BX_KEY_MINUS - BX_KEY_GRAVE ` BX_KEY_BACKSPACE BackSpace BX_KEY_ENTER Enter BX_KEY_TAB Tab BX_KEY_LEFT_BACKSLASH left \ BX_KEY_PRINT PrintScreen BX_KEY_SCRL_LOCK ScrollLock BX_KEY_PAUSE Pause BX_KEY_INSERT Ins BX_KEY_DELETE Del BX_KEY_HOME Home BX_KEY_END End BX_KEY_PAGE_UP PageUo BX_KEY_PAGE_DOWN PageDown BX_KEY_KP_ADD Numeric Keypad + BX_KEY_KP_SUBTRACT Numeric Keypad - BX_KEY_KP_END Numeric Keypad 1 BX_KEY_KP_DOWN Numeric Keypad 2 BX_KEY_KP_PAGE_DOWN Numeric Keypad 3 BX_KEY_KP_LEFT Numeric Keypad 4 BX_KEY_KP_5 Numeric Keypad 5 BX_KEY_KP_RIGHT Numeric Keypad 6 BX_KEY_KP_HOME Numeric Keypad 7 BX_KEY_KP_UP Numeric Keypad 8 BX_KEY_KP_PAGE_UP Numeric Keypad 9 BX_KEY_KP_INSERT Numeric Keypad 0 BX_KEY_KP_DELETE Numeric Keypad . BX_KEY_KP_ENTER Numeric Keypad Enter BX_KEY_KP_MULTIPLY Numeric Keypad * BX_KEY_KP_DIVIDE Numeric Keypad / BX_KEY_UP UpArrow BX_KEY_DOWN DownArrow BX_KEY_LEFT LeftArrow BX_KEY_RIGHT RightArrow BX_KEY_WIN_L Left Windows BX_KEY_WIN_R Right Windows BX_KEY_MENU Menu BX_KEY_ALT_SYSREQ Alt-Sysreq BX_KEY_CTRL_BREAK Ctrl-Break BX_KEY_INT_BACK Internet - back BX_KEY_INT_FORWARD Internet - forward BX_KEY_INT_STOP Internet - stop BX_KEY_INT_MAIL Internet - mail BX_KEY_INT_SEARCH Internet - search BX_KEY_INT_FAV Internet - fovorites BX_KEY_INT_HOME Internet - home BX_KEY_POWER_MYCOMP Powerkeys - my computer BX_KEY_POWER_CALC Powerkeys - calculator BX_KEY_POWER_SLEEP Powerkeys - sleep BX_KEY_POWER_POWER Powerkeys - power BX_KEY_POWER_WAKE Powerkeys - wake

- using the control panel - the graphical elements in bochs window - using plugins ? - rules to find the bochsrc file - Resources for users testing status page: tells what has been tried and who got it working search on bochs web site SourceForge look for bug reports how to report problems, make feature requests What's a panic? How to report it to bug tracker, how to make it non-fatal. Mouse behavior, enabling and disabling Keyboard mapping problems [...] The Bochs community uses three mailing lists to communicate, called bochs-developers, bochs-cvs and bochs-announce.

Bochs-developers is the forum for all Bochs discussions and questions. On average, subscribers get between five and ten messages per day. There are about 350 subscribers. If this sounds like too much email, maybe the bochs-announce list is more appropriate for you. Anyone may join the list, unless they abuse it of course. To subscribe, go to the Bochs-Developers Info Page and type your email address and a password into the web form and click Subscribe. In a few minutes you will get a confirmation email. Follow the directions in the email to complete the subscription process. To unsubscribe, go to the same page and type your email address in the blank at the bottom and click on Edit Options. Then type your password and click Unsubscribe. Once you have subscribed, you can write to bochs-developers@lists.sourceforge.net to send a message to everyone on the list. While it's possible to post without being a subscriber, it's not recommended. If you aren't a subscriber, you might miss the response to your question. Archive of bochs-developers messages

Bochs-announce is a moderated, low-traffic list which carries only periodic announcements of Bochs releases and important events. If you have a very important and truly relevant Bochs announcement, you can try posting it to bochs-announce, but the moderator will have to approve it before it will go out. On average, bochs-announce subscribers get one or two messages per month. There are about 75 subscribers. Anyone may join the list. To subscribe, go to the Bochs-Announce Info Page and type your email address and a password into the web form and click Subscribe. In a few minutes you will get a confirmation email. Follow the directions in the email to complete the subscription process. To unsubscribe, go to the same page and type your email address in the blank at the bottom and click on Edit Options. Then type your password and click Unsubscribe. There is no need to subscribe to both lists, because all bochs-announce messages are forwarded to the developers list. If you subscribe to both, you will get 2 copies of every announcement. Archive of bochs-announce messages

This is the cvs commit mailinglist (a unified diff email will be sent whenever someone does a checkin in the bochs cvs repository). Archive of bochs-cvs messages

Here are a few guidelines for use of the Bochs mailing lists: Please check the documentation before asking questions, but on this list you are very UNLIKELY to get flamed and insulted for being a Bochs beginner. Sending commercial promotions to the list probably will get you some angry responses though. Also, keep in mind that messages are limited to 40K, so if you want to share a large screen shot or disk image, put it on a web or FTP site and tell people how to find it. Patches are usually small enough that they aren't a problem, especially if compressed. Distribution of copyrighted material, or even offers to distribute copyrighted material WILL NOT be tolerated. The Bochs Project does not distribute any software (disk images) in violation of the license agreement, and users who do so will be warned first and then blocked from the list if it happens again. As an open source project, we rely on donated services from Source Forge and other groups, and we can't afford to put them or ourselves at risk of legal action. It is possible to subscribe and unsubscribe by email. If you do this, you must write to bochs-announce-request or bochs-developers-request. Don't forget the "-request" part or your subscribe message will go to 300+ people.

This was contributed by Greg Alexander in October 2001. What you need: An executable version of bochs. See Downloading Bochs and Compiling Bochs. The bximage program, included with bochs A FreeDOS boot disk, or a boot disk from another OS capable of producing DOS partitions (i.e. a linux install disk.) (optional) mtools, a program for manipulating DOS disks/images. Run `bximage` to create a disk image file. You will be greeted with the following prompt: ======================================================================== bximage Disk Image Creation Tool for Bochs ======================================================================== Do you want to create a floppy disk image or a hard disk image? Please type hd or fd. [hd] Since we are creating a hard disk image, accept the default of hd by pressing Enter or typing 'hd' and pressing Enter. Next, bximage will ask for the size of the disk image you want to create, in Megabytes: Enter the hard disk size in megabytes, between 1 and 32255 [10] Enter the size of the hard disk you want to create, and press Enter. Bochs will give you some information about the image it is creating, and ask you for a filename to use for the file it is creating. I told it to use the default of 10 megabytes, and was given the following information along with the prompt for a filename: [10] 10 I will create a hard disk image with cyl=20 heads=16 sectors per track=63 total sectors=20160 total size=9.84 megabytes What should I name the image? [c.img] At this point, type in the filename you want to use for the image. The default of "c.img" is appropriate if this will be your only hard disk image. After you have typed in the name of the filename you want to use, press Enter. Bximage will tell you it is writing the disk and will display a status bar as you wait. When it is finished, it will give you a final status report and tell you a line that should be added to your .bochsrc file when you want to use this disk image. I named my 10 Megabyte image "teaching.img" and the output of bximage looked like this: [c.img] teaching.img Writing: [..........] Done. I wrote 10321920 bytes to teaching.img. The following line should appear in your bochsrc: diskc: file="teaching.img", cyl=20, heads=16, spt=63 At this point, a file called "teaching.img" was created in my current directory and is ready to be used as an image file for a bochs session. 2.) Partition and format your image file. Option 1: Using FreeDOS (Advantages: Creates a MBR on the partition.) First, you need to edit the .bochsrc file that bochs uses for configuration information. Open the file .bochsrc with a text editor. Remove any lines in the file beginning with "diskc:". Add the "diskc:" line that was displayed when you ran bximage to the .bochsrc file in the same place that you removed the old "diskc:" lines from. Also, you need to download or create a FreeDOS (or DOS, or Windows, or linux) disk image. Modify the "floppya:" line in your .bochsrc file to point at the downloaded FreeDOS image and change its status to "status=inserted". Save and close your .bochsrc. Now run bochs. (see: "Running bochs from the command line.") Use the standard FreeDOS commands fdisk and format to format your hard drive image. You must make the image bootable to be able to boot without a hard drive. However, creating a bootable disk image is best done with a boot disk from the OS you intend to install on the image. Option 2: Using mtools (Disadvantages: cannot create bootable images without a MBR image) Use a text editor to add the following line to the file ~/.mtoolsrc: drive c: file="path/filename.img" partition=1 Save and close .mtoolsrc. Next, execute the following commands to create a partition table for the drive image: mpartition -I -s spt -t cyl -h heads c: mpartition -cpv -s spt -t cyl -h heads c: For example, for my 10 meg drive, I used: mpartition -I -s 63 -t 20 -h 16 c: mpartition -cpv -s 63 -t 20 -h 16 c: Next, format the partition you just created using the mformat command: mformat c: And you now have a formatted disk image containing a single DOS partition.

Mtools is a set of programs that can read, write, and format DOS disk images. There are links to the Mtools main page and a Win32 port of Mtools on the Bochs Links page, under Resources. The mtools web site has a detailed manual. If anyone wants to write instructions specific to Bochs, we can add it right here.

Someone on the bochs-developers list mentioned that they use a program called WinImage, from www.winimage.com to read and write disk images (floppy and hard disk). Winimage is a commercial product with a 30-day trial. If anyone wants to write a tutorial, send mail to &devlist; and volunteer.

This section was contributed by Volker Ruppert. It describes how to access a floppy or hard disk image within Linux using the loop device. Why would you want to do this? Let's say you have made a small Linux disk image for Bochs, and you want to install some more software on it. You have already downloaded the software onto your real system, so now you want to transfer it to the Bochs disk image. A fast way to transfer the files is to mount the disk image using the loop device. Here is what Volker writes: Today I have made some tests with the loop device, because I want to exchange files with the bochs disk images. This is what I found out: 1. Using Floppy images is easy, because there is no partition table: losetup /dev/loop0 /usr/local/bochs/dlxlinux/floppya.img Now you can use the image like a real floppy: - format : mkfs.minix /dev/loop0 - filesystem check : fsck.minix /dev/loop0 - mount : mount /dev/loop0 -o loop /mnt/floppy Before you want to restart bochs you must do this: losetup -d /dev/loop0 Don't forget to umount before. 2. If you want access to a hard disk image, you have to calculate the size of the first cylinder. This value is the offset argument for losetup. offset = bytes per sector * sectors per cylinder The command for dlxlinux image looks like this: losetup /dev/loop0 /usr/local/bochs/dlxlinux/hd10meg.img -o 8704 For images created by bximage you must use the value 32256. 3. The hard disk image access doesn't work if the image contains more than one partition. 4. I have made this tests with linux and I don't know how this could be done with other operating systems.

Bochs can now simulate an SMP machine when you use "--enable-processors=N" in the configure command. SMP support was added by Bryce Denney, who was very interested in watching a multiprocessor operating system work at a low level. It should also be helpful to operating system developers who are writing SMP drivers, or just for users who want to test drive an SMP machine to see what it looks like. It is important to understand that configuring bochs for 4 processors will NOT make your single-threaded applications run faster in general! On the contrary, it has to spend time simulating idle processors as well as the ones doing your task. The point is to simulate an SMP system, not to speed up a uniprocessor application. What was required to make SMP work in Bochs? (Note that only Linux 2.2 has been tested so far.) local APIC on each processor with timer one I/O APIC model implement RDTSC feature (read time stamp counter) modifications to rombios.c to add a data structure called the Intel Multiprocessor Configuration. An SMP-aware operating system probes BIOS memory to find the structure, which contains information about how many processors, their IDs, interrupt sources, etc. What needs to be done to improve SMP support? still needs work on rombios.c to allow you to configure the number of processors in the .bochsrc. Presently you have to choose the number of processors at compile time. debugger support is still limited. For example, you can set breakpoints, but you can't specify which processor you want to set the breakpoint for. test on SMP systems other than linux 2.2.14 several parts of the APIC model which weren't needed for linux 2.2.14 are not implemented yet and cause a panic. If you boot linux 2.4.3 for example, it says "panic: cluster model addressing not implemented". See bug report #421938 for tips on getting linux 2.4 to boot. (The apic is not the only problem!) A number of people have suggested using threads to simulate each CPU in a different thread. Then on a real SMP machine, the threads can execute in parallel. This is a great idea, but it's not done at present.

All Bochs binaries come with a working version of DLX Linux. This section describes how to configure networking in Bochs and enable it within DLX Linux. First you must add a ne2k line in your bochsrc file. Then, when you boot the DLX Linux image, you need to type some Linux commands to set up an IP address, a network route, and a name server. When you have an ne2k line in your bochsrc file, Bochs will emulate a network card called an NE2000. Below are some examples of valid ne2k lines for various operating systems. Choose the one that's closest to what you need, add it to your bochsrc file, and edit the values if necessary. # sample for FreeBSD ne2k: ioaddr=0x280, irq=9, mac=b0:c4:20:00:00:00, ethmod=fbsd, ethdev=xl0 # sample for Linux ne2k: ioaddr=0x280, irq=9, mac=b0:c4:20:00:00:00, ethmod=linux, ethdev=eth0 # sample for Windows ne2k: ioaddr=0x280, irq=9, mac=00:c4:3B:00:C3:00, ethmod=win32, ethdev=NE2000 You see the pattern. Usually you won't need to change the I/O address, IRQ number, or MAC address. The ethmod value depends on your host operating system, and it must be either null, fbsd (for FreeBSD or OpenBSD), linux, or win32. The ethdev setting is the name of the network interface on your system, and is also OS-dependent. On UNIX systems you can get the name of the network interface by running ifconfig. (Don't choose the loopback interface.) On Windows systems, the correct ethdev setting is not always obvious, so we provide a utility called niclist to list the names of network interfaces to use. When you run niclist, it will suggest an ne2k line which is a very good first try. Next, if you are on a UNIX machine you will need to become the root user. Since bochs is sending and receiving raw network packets, you need to be root to use the network device. To allow normal users to do this would be a security problem. Now run Bochs to boot DLX Linux. Press enter a few times to accept the default configuration choices. This tells Bochs read the configuration file and then begin. DLX Linux should boot in the Bochs window, and you should see that Linux detects the NE2000 card. Eventually it gets to a login prompt. ne.c:v1.10 9/23/94 Donald Becker (becker@cesdis.gsfc.nasa.gov) NE*000 ethercard probe at 0x280: b0 c4 20 00 00 00 eth0: NE2000 found at 0x280, using IRQ 9. At the login prompt, type "root" to log in as root. Then type the ifconfig and route commands to set up networking. The exact IP numbers in the example won't work for you; you must choose an IP configuration that is legal on your network. dlx login: root Linux 1.3.89. dlx:~# ifconfig eth0 192.168.0.99 # set bochs IP address dlx:~# route add -net 192.168.0.0 # first 3 numbers match IP dlx:~# route add default gw 192.168.0.1 # your gateway to the net dlx:~# _ The bochs IP address must be an unused IP address on your network. If you duplicate someone else's IP address, your network will become very confused. Finally, the network is ready and you can test it out with ping, telnet, or ftp to various machines by their numerical IP address. Keep in mind that for all UNIX host platforms, Bochs networking cannot talk to the host machine. That means the host machine can't be the gateway either. You need another physical machine on the network that bochs can talk to. On Win32 this restriction does not apply. When you have a working network configuration, you can make DLX Linux recreate the same settings the next time you boot. Just add the ifconfig and route commands to the end of /etc/rc.d/rc.inet1. I won't try to describe how to use the vi editor in this limited amount of space... To configure a name server, set up /etc/resolv.conf with the IP address of your name server as shown. dlx:~# echo 'nameserver 192.168.0.1' > /etc/resolv.conf

If you use linux (optionnaly FreeBSD and Solaris, not tested), you may want to access the network through a tuntap interface. The main advantage of this interface, is that the guest has access to the host. The guest can even have access to the whole network if the host routes or masquerades the guest requests. No extra IP address is needed, all can be done using private IP addresses. You'll find here instructions to set up Linux/Bochs to provide network access to the guest OS through a tuntap interface and private IP network. We're going to see howto : enable the tuntap interface in the Linux Kernel configure Bochs to use the tuntap interface set up the private network between the host and the guest set up the host to masquerade the guest network accesses

From the tuntap.txt file in the Linux kernel tree : TUN/TAP provides packet reception and transmission for user space programs. It can be viewed as a simple Point-to-Point or Ethernet device, which instead of receiving packets from a physical media, receives them from user space program and instead of sending packets via physical media writes them to the user space program. When a program opens /dev/net/tun, driver creates and registers corresponding net device tunX or tapX. After a program closed above devices, driver will automatically delete tunXX or tapXX device and all routes corresponding to it.

First make sure the tuntap module is included in the kernel : if you use a recent distribution, chances are that the needed modules are already build Make sure that "Kernel module loader" - module auto-loading support is enabled in your kernel. Add following line to the /etc/modules.conf: alias char-major-10-200 tun Run: depmod -a The driver will be automatically loaded when application access /dev/net/tun. Otherwise, recompile the kernel, including the configuration option CONFIG_TUN (Network device support -> Universal TUN/TAP device driver support) Make sure there is a /dev/net/tun device. (Can be created with 'mkdir /dev/net ; mknod /dev/net/tun c 10 200'). In the same way, to use masquerading, you need a kernel wth the following options : CONFIG_IP_NF_CONNTRACK (Connection tracking) CONFIG_IP_NF_IPTABLES (IP tables support) CONFIG_IP_NF_NAT (Full NAT) Some of the other options in this group is probably also needed, (but the default setting should be OK).

Make sure Bochs has ne2000 support. If you have to recompile Bochs, --enable-ne2000 when running ./configure (see ) edit your .bochsrc configuration file and add something like : ne2k: ioaddr=0x280, irq=9, mac=fe:fd:00:00:00:01, ethmod=tuntap, ethdev=tun0, script=/path/to/tunconfig Since the tuntap interface cannot be configured until a process opens it, Bochs may run a script file for you. In this case /path/to/tunconfig should be changed to match the actual place where you'll create this script.

We'll set up a private network between the host and the guest with the following parameters: Host IP : 192.168.1.1 Guest IP : 192.168.1.2 If your parameters are different, adapt the rest of the section to suit your needs. Create the /path/to/tunconfig script : #!/bin/bash /sbin/ifconfig $1 192.168.1.1 The script get the interface name as the first parameter. Linux will forward incoming packets between interfaces. Make it executable :chmod 755 /path/to/tunconfig Run Bochs, install the guest OS, and set the following network parameters : IP: 192.168.1.2 netmask: 255.255.255.0 gateway: 192.168.1.1 nameserver: whatever is used in linux Bochs must be started by root (at least for now - the script won't have root privileges otherwise). You may also have to edit /etc/hosts.allow and add : ALL: 192.168.1.2 Don't forget to set up the route on the guest. At this point, you should be able to ping/telnet/ftp/ssh the guest from the host and vice-versa.

We are going to set up standard masquerading configuration. Edit the /path/to/tunconfig script ans add : /sbin/iptables -D POSTROUTING -t nat -s 192.168.1.0/24 -d ! 192.168.1.0/24 -j MASQUERADE >& /dev/null /sbin/iptables -t nat -s 192.168.1.0/24 -d ! 192.168.1.0/24 -A POSTROUTING -j MASQUERADE echo 1 > /proc/sys/net/ipv4/ip_forward The configuration assumes the default policy is ACCEPT (can be examined by doing '/sbin/iptables -L'. The iptables package must be installed. And voila... The host should forward the packets of the guest to the rest of your network. You could even have acces to the internet... &FIXME; add nice screenshot You may need to load other modules if you want to use other fancy protocols (ftp,etc...)

Note, if you are looking for a graphical front-end for the bochs debugger, you may want to check out BFE.  This is a package written by a bochs user which can interface with the text based bochs debugger. No linking is necessary. It's not part of bochs, but you may find it useful. You can now conditionally compile in a GDB like command line debugger, that allows you to set breakpoints, step through instructions, and other useful functions. If there isn't a command for something you believe is generally useful for the debugger, let me know and I'll implement it if possible. To use the debugger, you must configure bochs with the '--enable-debugger' and '--enable-disasm' flags. For example: ./configure --enable-debugger --enable-disasm NOTE: You must use flex version 2.5.4 or greater. I have heard that version 2.5.2 will not work. When you first start up bochs, you will see the command line prompt bochs:1> From here, you may use the following commands:

c Continue executing stepi [count] execute count instructions, default is 1 si [count] execute count instructions, default is 1 step [count] execute count instructions, default is 1 s [count] execute count instructions, default is 1 Ctrl-C stop execution, and return to command line prompt Ctrl-D if at empty line on command line, exit quit quit debugger and execution q quit debugger and execution

NOTE: The format of 'seg', 'off', and 'addr' in these descriptions, are as follows. I don't have any way to set the current radix. hexidecimal: 0xcdef0123 decimal: 123456789 octal: 01234567 vbreak seg:off Set a virtual address instruction breakpoint vb seg:off lbreak addr Set a linear address instruction breakpoint lb addr pbreak [*] addr Set a physical address instruction breakpoint pb [*] addr (the '*' is optional for GDB compatibility) break [*] addr b [*] addr info break Display state of all current breakpoints delete n Delete a breakpoint del n d n

x /nuf addr Examine memory at linear address addr xp /nuf addr Examine memory at physical address addr n Count of how many units to display u Unit size; one of b Individual bytes h Halfwords (2 bytes) w Words (4 bytes) g Giant words (8 bytes) NOTE: these are *not* typical Intel nomenclature sizes, but they are consistent with GDB convention. f Printing format. one of x Print in hexadecimal d Print in decimal u Print in unsigned decimal o Print in octal t Print in binary n, f, and u are optional parameters. u and f default to the last values you used, or to w(words) and x(hex) if none have been supplied. n currently defaults to 1. If none of these optional parameters are used, no slash should be typed. addr is also optional. If you don't specify it, it will be the value the next address (as if you had specified n+1 in the last x command). setpmem addr datasize val Set physical memory location of size datasize to value val. crc addr1 addr2 Show CRC for physical memory range addr1..addr2 info dirty Show physical pages dirtied (written to) since last display Values displayed are the top 20 bits only (page addresses)

info program Execution status of the program info registers List of CPU integer registers and their contents info break Information about current breakpoint status

set $reg = val Change a CPU register to value val. Registers may be one of: eax, ecx, edx, ebx, esp, ebp, esi, edi. Currently, you may not change: eflags, cs, ss, ds, es, fs, gs. Examples: set $eax = 0x01234567 set $edx = 25 info registers See Info section dump_cpu Dump complete CPU state set_cpu Set complete CPU state Format of "dump_cpu" and "set_cpu": "eax:0x%x\n" "ebx:0x%x\n" "ecx:0x%x\n" "edx:0x%x\n" "ebp:0x%x\n" "esi:0x%x\n" "edi:0x%x\n" "esp:0x%x\n" "eflags:0x%x\n" "eip:0x%x\n" "cs:s=0x%x, dl=0x%x, dh=0x%x, valid=%u\n" "ss:s=0x%x, dl=0x%x, dh=0x%x, valid=%u\n" "ds:s=0x%x, dl=0x%x, dh=0x%x, valid=%u\n" "es:s=0x%x, dl=0x%x, dh=0x%x, valid=%u\n" "fs:s=0x%x, dl=0x%x, dh=0x%x, valid=%u\n" "gs:s=0x%x, dl=0x%x, dh=0x%x, valid=%u\n" "ldtr:s=0x%x, dl=0x%x, dh=0x%x, valid=%u\n" "tr:s=0x%x, dl=0x%x, dh=0x%x, valid=%u\n" "gdtr:base=0x%x, limit=0x%x\n" "idtr:base=0x%x, limit=0x%x\n" "dr0:0x%x\n" "dr1:0x%x\n" "dr2:0x%x\n" "dr3:0x%x\n" "dr4:0x%x\n" "dr5:0x%x\n" "dr6:0x%x\n" "dr7:0x%x\n" "tr3:0x%x\n" "tr4:0x%x\n" "tr5:0x%x\n" "tr6:0x%x\n" "tr7:0x%x\n" "cr0:0x%x\n" "cr1:0x%x\n" "cr2:0x%x\n" "cr3:0x%x\n" "cr4:0x%x\n" "inhibit_int:%u\n" "done\n" Notes: - s is the selector - dl is the shadow descriptor low dword (4 byte quantitiy) - dh is the shadow descriptor high dword (4 byte quantitiy) - valid denotes if the segment register holds a validated shadow descriptor - inhibit_int is set if the previous instruction was one which delays the acceptance of interrupts by one instruction (STI, MOV SS) - any errors encountered by the set_cpu command, are reported by "Error: ...". They may be reported after any of the input lines, or after the "done" line, during limit checks. - A successful set_cpu command ends with the separate line: "OK".

disassemble start end Disassemble instructions in given linear address range, inclusive of start, exclusive of end. Use "set $disassemble_size =" to tell debugger desired segment size. Use a value for end of less than start (or zero) if you only want the first instruction disassembled. set $disassemble_size = n Tell debugger what segment size to use when the "disassemble" command is used. Use values of 0, 16 or 32 for n. Value of 0 means "use segment size specified by current CS segment". Default is 0. set $auto_disassemble = n Cause debugger to disassemble current instruction every time execution stops if n=1. Default is 0. Segment size of current CPU context is used for disassembly, so variable "$disassemble_size" is ignored.

To use instrumentation features in bochs, you must compile in support for it. You should build a custom instrumentation library in a separate directory in the "instrument/" directory. To tell configure which instrumentation library you want to use, use the "--enable-instrumentation" option. The default library consists of a set of stubs, and the following are equivalent: ./configure [...] --enable-instrumentation ./configure [...] --enable-instrumentation="instrument/stubs" You could make a separate directory with your custom library, for example "instrument/myinstrument", copy the contents of the "instrument/stubs" directory to it, then customize it. Use: ./configure [...] --enable-instrumentation="instrument/myinstrument"

instrument start calls bx_instr_start() instrument stop calls bx_instr_stop() instrument reset calls bx_instr_reset() instrument print calls bx_instr_print()

trace-on Disassemble every executed instruction. Note that instructions that cause exceptions are not really executed, and therefore not traced. trace-off Disable tracing. ptime Print the current time (number of ticks since start of simulation (modulo 2^32)). sb delta Insert a time break point "delta" instructions into the future. sba time Insert a time break point at "time". record filename Record console input to file filename. The file consists of zero or more lines of the form "%s %d %x", where the first word is the event type, the second is a time stamp and the third is event specific data. playback filename Playback console input from file filename. Additional input can be given directly in the console window. Events in the file will be played back at times relative to the time when the playback command was executed. print-stack [num words] Print the num words top 16-bit words on the stack. Num words defaults to 16. Only works reliably in protected mode when the base address of the stack segment is zero. watch stop Stop the simulation (and return to prompt) when a watch point is encountered. watch continue Do not stop the simulation when watch points are encountered. They will still be logged. watch Print current watch point status. unwatch Remove all watch points. watch read address Insert a read watch point at physical address address. watch write address Insert a write watch point at physical address address. unwatch read address Remove read watch point from physical address address. unwatch write address Remove write watch point from physical address address. modebp [string] Toggles vm86 mode switch breakpoint. load-symbols [global] filename [offset] Load symbols from file filename. If the global keyword is added, then the the symbols will be visible in all contexts for which symbols have not been loaded. Offset (default is 0) is added to every symbol entry. The symbols are loaded in the current (executing) context. The symbol file consists of zero or more lines of the format "%x %s". show [string] Toggles show symbolic info (calls to begin with). show - shows current show mode show "mode" - show, when processor switch mode show "int" - show, when interrupt is happens show "call" - show, when call is happens show "ret" - show, when iret is happens show "off" - toggles off symbolic info show "dbg-all" - turn on all show flags show "none" - turn off all show flags

time0: time Specifies the start (boot) time of the virtual machine. Use a time value as returned by the time(2) system call. Time equal to 1 is a special case which starts the virtual machine at the current time of the simulator host. cdromd: dev=device, status=(inserted|ejected) LoseNT needs a CD in order to boot properly. Our simulated CD-ROM unit communicates directly with the CD-ROM driver in Linux. Device is a device special file to which the CD-ROM driver is connected (typically /dev/hdc). Device is ignored if status=ejected.

&FIXME; add links Cosimulation Instrumentation

This section covers how you can use Bochs with a remote GDB stub to debug your kernel.

The GDB stub is not active in standard Bochs binary package. So you must recompile Bochs. Download the Bochs source package, untar it and run the configure script with the `--enable-gdb-stub' argument. $ ./configure --enable-gdb-stub After that, just run make and you should have a Bochs binary that contain a GDB stub in your directory.

Just start Bochs as normal. Bochs will stop and wait for GDB to connect to the stub.

Bochs GDB stub waits for a connection on port 1234 on localhost (127.0.0.1). Just start GDB like this; $ gdb YOUR-KERNEL . . . (gdb) target remote localhost:1234 Remote debugging using localhost:1234 0x0000fff0 in ?? () (gdb) You are now connected to the remote GDB stub in Bochs. You are now able to set breakpoints. Use the continue (c) command to continue the simulation. Hitting ^C works. Example; Program received signal 0, Signal 0. syscall_testsuite_result (aux=0x1f11fe4) at ../rtmk/syscalls.c:33 33 { (gdb)

When failing to boot from CDROM, the bios outputs the reason of the failure as an error code, in the log file, and on the screen. Here are the meaning of the errors: Error code Reason 0x01 no atapi device found 0x02 no atapi cdrom found 0x03 can not read cd - BRVD 0x04 cd is not eltorito (BRVD) 0x05 cd is not eltorito (ISO TAG) 0x06 cd is not eltorito (ELTORITO TAG) 0x07 can not read cd - boot catalog 0x08 boot catalog : bad header 0x09 boot catalog : bad platform 0x0A boot catalog : bad signature 0x0B boot catalog : bootable flag not set 0x0C can not read cd - boot image

What disk images are available. Installing from scratch. What works Known problems

This has been contributed by Bruno Bonfils (asyd at debian-fr dot org)

Since I don't have enough computers to dedicate a box to the Hurd, I'm trying to do my own harddrive image disk. I thougt there was some documentation about how to do that. But since I didn't find anything and I decided to write a small doc. I hope this document will be useful for some people who wants to try the Hurd.

Debian (Sid) GNU/Linux 2.4.19 ii bochs 1.4.1.no.elpin IA-32 (x86) PC emulator ii bochs-x 1.4.1.no.elpin Bochs binary with X interface. ii grub 0.92+cvs200209 GRand Unified Bootloader ii gcc-i386-gnu 1.7-8 Cheap cross-compiler for GNU/Hurd. ii mig-i386-gnu 1.2-1 The GNU distribution of the Mach 3.0 interface If you don't have time and if you trust me, you can download here My own harddisk Image File (~20Mo) my own image file. (You don't need to run native-install)

In this example, I use a 112 MB image disk, but I think you can use any size without some problem. Use createdisk command like this : # createdisk hurd.img 112 Disk Geometry: C: 227 H: 16 S: 63 Total size: 117153792 bytes Note on a paper or on your memory the disk geometry. Then, use the losetup command to create a loopback on the whole disk. # losetup /dev/loop1 hurd.img Now, call fdisk on /dev/loop1. Go into expert mode, and modify the disk geometry using the c, h, s commands. Return in normal mode, and create an unique primary partition which uses the whole disk. Then, detach the /dev/loop1 using : # losetup -d /dev/loop1

Attach the partition First of all, you need to create a filesystem on the disk. Use the command losetup and -o <offset> option to attach /dev/loop1 on the first partition of an image disk. Offset is computed like this : offset = sector * block_size (512) # losetup -o 32256 /dev/loop1 hurd.img Preparing the filesystem According to The Hurd Installation Guide Hurd Installation guide , use mke2fs to create a filesystem. # mke2fs -o hurd /dev/loop1 Just mount /dev/loop1 like a typical dev. # mount /dev/loop1 /mnt/gnu Finish the installation Download a GNU/Hurd archive as indicated in the Hurd Installation Guide, and decompress it in /mnt/gnu. # cd /mnt/gnu # tar --same-owner -xvzpf ~/gnu-latest.tar.gz

Copy default configuration (/usr/share/doc/bochs/examples/bochsrc.gz on debian) on your home directory and edit it with your favorite editor (GNU Emacs, i hope ;). For my image file I have the following configuration : romimage: file=/usr/share/bochs/BIOS-bochs-latest, address=0xf0000 megs: 128 vgaromimage: /usr/share/vgabios/vgabios.bin floppya: 1_44=/dev/fd0, status=ejected diskc: file="/home/asyd/travail/hurd/hurd.img", cyl=227, heads=16, spt=63 # edit me cdromd: dev=/dev/cdrom, status=inserted boot: c log: /dev/stdout panic: action=ask error: action=report info: action=report debug: action=ignore vga_update_interval: 300000 keyboard_serial_delay: 250 keyboard_paste_delay: 100000 floppy_command_delay: 500 ips: 1000000 mouse: enabled=0 private_colormap: enabled=0 fullscreen: enabled=0 screenmode: name="sample" ne2k: ioaddr=0x280, irq=9, mac=fe:fd:00:00:00:01, ethmod=tap, ethdev=tap0 keyboard_mapping: enabled=0, map= keyboard_type: xt i440fxsupport: enabled=0 note most of them are actually in the default Debian example file. If you use these lines, don't forget to read the Networking section.

Remember that the Hurd is not an OS, it's just a collection of libraries and programs, so we can't actually boot the Hurd. We boot GNU Mach, and then launch the base servers. The default GNU Mach which is provided by the default GNU/Hurd archive contains some modules / drivers which are not needed in bochs environment. If you use it, you'll probably have some kernel panic while booting. Don't be afraid and just say alwayscont. in my archive, I use a recompiled GNU Mach which contains only the drivers which are needed (--enable-floppy --enable-ide --enable-kmsg --enable-ne2000). If you want more informations on how to compile your own GNU Mach, just send me a mail and I'll add the section in this document.

Create a grub floppy disk or use my floppy image Grub Floppy image : (coming soon) Adapt your bochsrc file according to your choice. If you want install Grub on the image disk, remember to copy stage1, stage2 Grub's files into /mnt/gnu/boot/grub. Launch bochs - as root if you want networking (using sudo for example). If you have stage1 and stage2 file, you can install Grub on the MBR. <grub> root (hd0,0) <grub> setup (hd0) Finally, booting GNU mach <grub> root (hd0,0) <grub> kernel /boot/gnumach.gz root=hd0s1 <grub> module /boot/serverboot.gz <grub> boot Now, you can read the official Hurd Installation Guide Hurd Installation guide .

You can try to test networking between the GNU/Linux (host OS) and the GNU/Hurd. First of all, please read new ethertap interface for linux, by Bryce Denney , I currently have the *same* problem. This can be solved by using the tuntap interface (see ) Verify your kernel configuration, you need to have : CONFIG_NETLINK_DEV=m CONFIG_ETHERTAP=m (or y instead or m). Check if /dev/tap0 file exist, else create it with # mknod /dev/tap0 c 36 16 and run this command on the guest os : # ifconfig tap0 192.168.100.1 netmask 255.255.255.0 Use ip 196.168.100.10 on the GNU/Hurd and you can ping 192.168.100.1

Mmenal #hurdfr, #hurd, #bochs channels (Freenode network) All people who help me everyday on IRC Copyright (c) Bruno Bonfils Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation.

To access your CDROM in DOS, you must download an IDE CDROM driver. Bochs emulates a very generic CDROM drive, and several drivers are known to work. Others don't. This section describes how to set up your config.sys and autoexec.bat to enable the CDROM. The drivers that have been reported to work are OAKCDROM.SYS that comes with several versions of Windows and SBIDE.SYS version 1.21 from Creative Labs To get it, go to Creative Labs web site, click on Support, then click Download Files. You get to a screen where you must select the operating system and the product for which you want the driver. Choose DOS as the operating system, and "CD-ROM: 4x and above" as the product. There are several choices, but you want sbide121.exe from April 15, 1997. Version 2.0 does not work. The download file is a self-extracting ZIP file, so you will need to run it in DOS or Windows. If you can copy it onto the DOS floppy disk image, you can even boot DOS inside Bochs and run sbide121.exe to extract it. The driver is called SBIDE.SYS. and OAKCDROM.SYS that comes with several versions of Windows. Copy the driver to your boot disk, and then set up the startup files as follows. config.sys: device=himem.sys device=oakcdrom.sys /D:CD001 -or- device=sbide.sys /D:CD001 /P:1f0,14,3f6 autoexec.bat: mscdex.exe /M:10 /D:CD001 If the files mentioned in config.sys and autoexec.bat are not in the root directory, give the full pathname, like c:\windows\himem.sys.

Using Windows95 for PCs without Windows, 1.44M floppy distribution Preparing for the install Copy the floppies to files on your workstation. Keep in mind, they are of 2 formats - 1.44M & 1.680M. The boot disk and disk#1 are 1.44M. The rest of them (disk#2..disk#13) are 1.680M format. You may need a Linux workstation to do this part, though it should be possible on others if the OS provides a way to specify alternate floppy media geometries. format tracks heads sectors/track 1.44M: 80 2 18 1.680M: 80 2 21 +- On linux, you achieve this, via the 'setfdprm' command, and | associated parameters in the '/etc/fdprm' file. Here's an | excerpt from that file: | | # /etc/fdprm - floppy disk parameter table | 1440/1440 2880 18 2 80 0 0x1B 0x00 0xCF 0x6C | 1680/1440 3360 21 2 80 0 0x0C 0x00 0xCF 0x6C # ????? | | To copy the floppies, you would do something like: | | linux-> cp /dev/fd0 win95_boot (after inserting the boot diskette) | linux-> cp /dev/fd0 win95_d1 (after inserting disk #1) | | Then switch to the alternate 1.680M geometry: | | linux-> setfdprm -p /dev/fd0 1680/1440 | linux-> cp /dev/fd0 win95_d2 (after inserting disk #2) | linux-> cp /dev/fd0 win95_d3 (after inserting disk #3) | ... | linux-> cp /dev/fd0 win95_d13 (after inserting disk #13) | | And revert back to the default 1.44M geometry if desired | +- linux-> setfdprm -p /dev/fd0 1440/1440 You should end up with something similar to the following listing: -rw-r--r-- 1 user group 1474560 Oct 31 12:04 win95_boot -rw-r--r-- 1 user group 1474560 Jul 15 1997 win95_d1 -rw-r--r-- 1 user group 1720320 Jul 15 1997 win95_d2 -rw-r--r-- 1 user group 1720320 Jul 15 1997 win95_d3 -rw-r--r-- 1 user group 1720320 Jul 15 1997 win95_d4 -rw-r--r-- 1 user group 1720320 Jul 15 1997 win95_d5 -rw-r--r-- 1 user group 1720320 Jul 15 1997 win95_d6 -rw-r--r-- 1 user group 1720320 Jul 15 1997 win95_d7 -rw-r--r-- 1 user group 1720320 Jul 15 1997 win95_d8 -rw-r--r-- 1 user group 1720320 Jul 15 1997 win95_d9 -rw-r--r-- 1 user group 1720320 Jul 15 1997 win95_d10 -rw-r--r-- 1 user group 1720320 Jul 15 1997 win95_d11 -rw-r--r-- 1 user group 1720320 Jul 15 1997 win95_d12 -rw-r--r-- 1 user group 1720320 Jul 15 1997 win95_d13 Create a hard disk image file. For example, for a 62M disk with the following settings in '.bochsrc': diskc: file=62M, cyl=940, heads=8, spt=17 use (940 * 8 * 17 * 512bytes-per-sector = 127840): unix-> dd if=/dev/zero of=62M bs=512 count=127840 Setup your '.bochsrc' file. For example: megs: 16 boot: c diskc: file=62M, cyl=940, heads=8, spt=17 floppya: 1_44=1.44, status=inserted vgaromimage: bios/VGABIOS-elpin-2.00A romimage: bios/BIOS-bochs-980118a (use newest one) log: ./bochs.out hga_update_interval: 300000 keyboard_serial_delay: 200 floppy_command_delay: 500 You'll also need a floppy image file, sort of a working file, which you copy the distribution files into, one by one, as they are needed. This is the file you point the 'floppya:' directive in the '.bochsrc' file to. Copy the Win'95 boot disk to your floppy working file ('1.44' in the '.bochsrc' example): unix-> /bin/cp -f win95_boot 1.44 Beginning the install Fire up bochs and boot the Win'95 boot diskette: unix-> bochs boot:a Microsoft Windows 95 Setup Quit Setup to DOS to use FDISK. '[F3]', '[F3]' FDISK C: to use the whole disk for the primary partition. A:\> fdisk '[Return]' '[Return]' '[Return]' Power down Bochs - click the mouse on the 'Power' button in the GUI toolbar. Fire up bochs again. unix-> bochs boot:a Microsoft Windows 95 Setup Quit Setup to DOS to use FORMAT. '[F3]', '[F3]' A:\> format /u c: (answer 'Y' and enter a volume label as desired) Click on the floppy A icon in the GUI toolbar. You should see an 'X' through it signifying it's logically ejected. Now we're ready for Disk1: unix-> /bin/cp -f win95_d1 1.44 Click on the floppy A icon again to logically insert disk1. The 'X' should go away. Now run SETUP.EXE which is on disk1. A:\> setup /C To continue ... '[Return]' Welcome to Windows 95 Setup!... '[Return]' (to select Continue button) Please insert "Disk2"... From now on, keep in mind that you must click the floppy A icon to tell bochs you're ejecting the floppy (in theory) BEFORE you copy over your floppy working file on your workstation, and click on it again AFTERWARDS, to insert it. This is most critical, if you transition from images of floppies with different format. (disk1=1.44M, disk2=1.680M) You're giving bochs a chance to look at the size of the image file, and switch to a different sectors-per-track. (Click the floppyA icon to eject) unix-> /bin/cp -f win95_d2 1.44 (Click the floppyA icon to insert) '[Return]' (select OK button) Software License Agreement '[Tab]' '[Return]' (select Yes button) Windows 95 Setup Wizard '[Return]' (select Next button) Choose Directory '[Return]' (select Next button) Setup Options '[Down-Arrow]', '[Down-Arrow]', '[Down-Arrow]' (selects custom) '[Return]' (select Next button) User Information Name: "Your name here" '[Tab]' Company: "Your company here" '[Return]' Key Identification Key: "123-4567890" (from your Certificate of Authenticity) '[Return]' (select Next button) Product Identification '[Return]' (select Next button) Analyzing Your Computer '[Down-Arrow]' (No, I want to modify the hardware list) '[Return]' (select Next button) Analyzing Your Computer Let me just note that you can get around in this screen, by the Down-Arrow key, Tab to move to a different area, and space to toggle selection. For some options, it's much easier to first unselect every device of that type, than select the one you want. The ultimate selection you're trying to achieve is: CD-ROM Drive (none) Display Default Standard VGA Display Adapter Floppy Disk Controllers Standard Floppy Controller Hard Disk Controllers Standard IDE/ESDI Hard Disk Controller Keyboard Keyboard Mouse (none) Network Adapter (none) PCMCIA Socket (none) Ports (none) SCSI Controllers (none) Sound, MIDI, or Video... (none) The exact sequence I used was: [Space] (unselect all CD-ROMs) [Down-Arrow] [Space] (unselect all Displays) [Tab] (move to Manufacturer and model section) 13 [Down-Arrows] (Default Standard VGA Display Adapter) [Space] (to select this adapter) 4 [Tabs] (get back to Hardware types section) 2 [Down-Arrows] (get to Hard Disk Controllers) [Space] (to unselect all Hard Disk Controllers) [Tab] (to get to Manufacturer and model section) 3 [Down-Arrows] (get to Standard IDE/...) [Space] (to select this device) 4 [Tabs] (get back to Hardware types section) 2 [Down-Arrows] (get to Mouse) [Space] (to unselect all Mouse types) [Down-Arrow] (get to Network Adapter) [Space] (to unselect all Network Adapters) [Down-Arrow] (get to PCMCIA Socket) [Space] (to unselect all PCMCIA Socket types) [Down-Arrow] (get to Ports) [Space] (to unselect all Ports) [Down-Arrow] (get to SCSI Controllers) [Space] (to unselect all SCSI Controllers) [Down-Arrow] (get to Sound, MIDI...) [Space] (to unselect all Sound, MIDI...) 3 [Tabs] (get to Next button) [Return] (select Next button) Analyzing Your Computer [Return] (select Next button) Get Connected [Return] (select Next button) Select Components Well, you have to decide this one. Remember, use [Down-Arrow], [Tab], and [Space]. [Tab] to the Next button when you're done and type [Return]. Network Configuration '[Return]' (to take default config, or change it as you want) Computer Settings '[Return]' (to take current settings) Startup Disk If you do NOT want to create a Startup Disk, you could type '[Down-Arrow]' (select No, I do not want a startup disk) '[Return]' (select Next button) If you DO want to create a Startup disk. '[Return]' (select Next button) It is possible to create a startup disk after the installation, so you may skip the creation of a startup disk if it becomes problematic. Either way, the following appears, Start Copying Files '[Return]' +- If you optioned to create a Startup Disk, the following appears: | | Label a disk "Windows 95 Startup Disk"... | | Click the floppyA icon to eject. Now copy any floppy image file | which has a 1.44M format on it, onto your floppy working file. | Win '95 will erase any files on it. Use the 'win95_boot' file, | since it's a 1.44M format. | | unix-> /bin/cp -f win95_boot 1.44 | | Click on floppyA to insert. | | '[Return]' | Setup has finished creating your startup disk... | '[Return]' (select OK button) | | Please insert the disk labeled 'Windows 95 Disk 2'... | | Click the floppyA icon to eject. | Copy the working floppy disk image file to something signifying | it's the startup disk. Then copy the disk#2 image file onto the | working file. | | unix-> cp 1.44 win95_startup | unix-> /bin/cp -f win95_d2 1.44 | | Click on floppyA to insert. | +- '[Return]' (select OK button) In any case (startup disk or not), the rest is very methodical. +-> Please insert the disk labeled 'Windows 95 Disk 3'... | | (Click the floppyA icon to eject.) | unix-> /bin/cp -f win95_d3 1.44 | (Click the floppyA icon to insert.) | | '[Return]' (select OK button) | | Just repeat this process, until SETUP has asked for all +- 13 floppies in the distribution. Of course, change 'win95_d3' to each number in the succession; win95_d4, win95_d4, ... , win95_d13. After asking for all the floppy disks in the distribution, Windows '95 will let you know it's going to restart your computer. Acknowledge this, and then bochs will bomb upon attempt to reboot. Fire up bochs again. The 'boot:c' is not necessary if you have the 'boot: c' directive in your '.bochsrc' file. unix-> bochs boot:c You'll get a screen full of garbage text for a while Win '95 updates your configuration files. I'm not handling that text screen mode correctly. Then the window switches to a blank graphics screen (say 2 to 5 minutes). Windows 95 is now setting up your hardware and any Plug and Play devices you may have. You'll see the magnifying glass circulating about the picture (icon) representing your computer for quite awhile. Windows is now setting up the following items... Setting up Control Panel Programs on the Start menu Windows Help MS-DOS program settings Time zone You can play with the Time Zone if you want. I just accept the one that comes up. I like being on Tijuana time anyhow! '[Return]' Set up printer Bochs printing support varies from host OS to host OS. Parallel port emulation was added in Bochs 1.3 for Unix platforms. Check to see if printing is supported for your host OS in or the forums. You can skip this part during installation and set up printing features later. Cancel print setup in this manner: '[Tab]' '[Return]' (select Cancel button) Windows 95 is now finalizing settings for your computer Windows '95 should now display the 'Welcome to Windows 95' screen, and give you one of it's helpful 'Did you know' tips. My suggestion, is for you to shutdown Win '95 at this point, and make a backup copy of your hard drive image file. Otherwise, you are done, though you may want to check out the section on getting rid of the 'splash' screen upon boot. In that case, shutdown is necessary also. '[Return]' (selects Close button) '[Ctrl]', '[Esc]', '[^Esc]', '[^Ctrl]' It's helpful to give slight intentional delays when typing multi-key sequences like the one above. The '^' means a release of that key. 'u' (shortcut for Shut Down) Shut down Windows... '[Return]' (select Yes button) Your window changes to a different size graphics mode. The message 'It is now safe to shutdown your computer' will be displayed briefly, but then the screen goes blank due to bochs not handling something in that graphics mode correctly. Power down by clicking on the 'Power' button in the bochs GUI toolbar. The bochs window disappears as bochs stops execution. Make a backup copy. unix-> cp 62M 62M.win95.installedOK Getting rid of Win '95 'splash' screen upon bootup. When Win '95 boots up, it typically displays the intro screen while it boots (splash screen). It uses a graphics mode I don't handle well, mostly because it's not important enough to spend the time on it. You can tell Win '95 not to display this screen anyways, which I prefer. Using the MTOOLS package, if you have a drive letter associated with your hard disk image file, for example: ~/.mtoolsrc: drive c: file="/path/62M" partition=1 You can look at and modify the contents of your drive image file, using commands on your workstation. WARNING: You MUST power down bochs if you are running any software that does any kind of disk caching!!! Yes, Windows '95 does disk caching. Look at the attributes associated with c:/MSDOS.SYS. unix-> mattrib c:/MSDOS.SYS Copy it to your workstation, with the text mode translation flag. unix-> mcopy -t c:/MSDOS.SYS . Edit the file, adding "Logo=0" under the Options section. Save the file. [Options] BootMulti=1 BootGUI=1 Network=0 Logo=0 <------- add this line Copy it back to your disk image. Restore proper attributes to what they were before. For example. unix-> mcopy -t MSDOS.SYS c:/ unix-> mattrib -a +s +h +r c:/MSDOS.SYS Finishing up after the install You should now delete any temporary copies of the floppy disk image files, used to facilitate installation. unix-> /bin/rm -i win95_boot win95_d* OK, you're done!!! Make sure you tell bochs to boot the hard drive either in '.bochsrc' or by the 'boot:c' option, and fire it up. unix-> bochs

It is possible to install a japanese version of Windows 95. However, a patch to the VGA card is needed (VGA Write Mode 2). &FIXME; we have to make sure that the patch is or not included in Bochs 2.0. The following has been contributed by dohzono at hf dot rim dot or dot jpa : Here is a tip for installing Japanese win95 (requires "VGA write mode 2" patch). * I made a boot floppy and installed the W95 disk image. I used "CD for new machines" (not an upgrade version). Host OS is FreeBSD-4.0R. It seems working. When you make a boot floppy with W95(J), there is a line containing DEVICE=JDISP.SYS /HS=LC in the config.sys (Highspeed Scroll?). jdisp.sys can have options: /HS=ON /HS=LC /HS=OFF and bochs runs with /HS=OFF option (I've heard that VMware requires /HS=LC option). # If you choose /HS=ON, you can read usual Japanese messages on the # screen, but it doesn't scroll (the cursor goes downward and out of # the screen). If you choose /HS=LC, you can see some images # (corrupted messages), and also it doesn't scroll. Here is my boot floppy's config.sys. I just changed the option like above (/HS=OFF), and added a line for the CD driver. DEVICE=BILING.SYS DEVICE=JFONT.SYS /MSG=OFF DEVICE=JDISP.SYS /HS=OFF DEVICE=JKEYB.SYS device=gscdrom.sys /d:mscd000 /v After installing to the HD image, I made a change to the line of c:/config.sys DEVICE=JDISP.SYS to DEVICE=JDISP.SYS /HS=OFF ^^^^^^^

+ &FIXME;

This has been contributed by Sancho Roberto : Date: Sun, 21 Oct 2001 02:24:22 -0700 (PDT) From: Sancho Roberto (rsanchov at yahoo dot com) To: bochs-developers@lists.sourceforge.net Subject: [Bochs-developers] WinMe install tips Parts/Attachments: 1) Install Win98 My Windows Me is an update version, that is, it upgrades over Win98. So the first think I have to do is to install on a HD image a Win98 It is not necessary to do the full install. What I've done is - Create a HD image (Win98.img) with 500MB - Format It, install MSDOS6 on it so I can boot from c - Make a W98 directory. - Copy using mtools the instalation directory from the original Win98 CD - Run bochs - run the setup program into the W98 directory - Select WIN98 as Windows directory. All other setup options are left by default. - I don't care about HW detection, etc. Just uncompressing the cab files to the WIN98 directory es enought for WinMe. (Note that Win98 is not functional and cannot boot) 2) Copy the WinMe install files to the HD In Win98.img, with mtools, I create a directory called WinMe. Again, I copy the contents of the Win9x directory from the original WinMe CD. Note that I copy the CD to my HD, and then with mtools from my HD to win98.img. I also delete then W98 directory. 3) Create WinMe.img Now, I created another blank HD called WinMe.img with 500MB. I format it and install MSDOS6 so I an boot using it. 4) Prepare the instalation Bochs I edit the bochsrc.txt file so - WinMe.img is diskc - Win98.img is diskd 5) Running setup I start bochs: the C: drive is empty (it only contains the MSDOS6 command.com, IO.SYS, etc). The D: drive has: D:\W98 - The "installed" Windows 98 D:\WINME - Windows Me setup files I go to the WINME directory and run: SETUP xxxx The description of the setup options can be found in the Microsoft Knowledge page as Q186111 - Description of the Windows 95, Windows 98, and Windows Me Setup Switches I've done a lot of trials with this setup options until I finally found a correct way to finnish the installation. These are the setup options I used. I've copied a brief description (from the KB) and added my comments. /m - bypass the playing of the Setup sound (.wav) files. Not necessary as my Bochs has no sound device activated /nf - Do not prompt to remove the floppy disk from the drive Maybe not necessary. Just in case /nh - This switch bypasses running the Hwinfo.exe program at 0 percent files and RunOnce. If not present, freezes on HW detection /ie - This switch bypasses the Windows 98 Startup Disk wizard screens. To speed things up - I allways can create a Statup disk latter /iv - This switch bypasses displaying the Setup screens during an upgrade within Windows. To speed things up /c - This switch bypasses running SMARTDrive. Maybe not necessary. Just in case /im - Causes setup to ignore the conventional memory check. Maybe not necessary. Just in case /is - This switch causes Setup not to run ScanDisk. Very important as SCANDISK freezed bochs /iq - If you use the /is switch to bypass ScanDisk or if ScanDisk does not complete successfully, Setup checks your drive for cross-linked files. The /iq switch prevents Setup from doing this. Very important. If not used, Setup stop the installation with a message "error found in C:, run scandisk and setup again" (or something like this). Of course, there is no errors in C: because is an empty, just formatted disk, but the WinMe setup thinks so. The only way to progress from this point is with this switch /it - This switch bypasses checking for the presence of "dirty" or "deadly" terminate-and-stay-resident programs (TSRs) that are known to cause problems with Windows Setup. Maybe not necessary. Just in case /p b;g=3 b: This switch enables Prompt Before mode. It prompts you before a detection module is called so that you can step through each detection module manually and decide if you want to skip it. Very important. See bellow g: This switch controls how verbose the built-in progress bar is There is another main issue that must be handled WinMe requires a 150Mhz computer as a minimum. If you try to run the WinMe setup, you will receive a message telling you so, and the installation will stop. The only way I found to solve this problem is to change the IPS value in bochsrc.txt. I raised the IPS value until setup stop complaining. In my machine (P3 @ 450MHz), I achieved this with ips: 500000000 This this IPS value, the keyboard and mouse are updated each 100 seconds. This makes very dificult to type the CD-KEY numbers, select type of instalation, etc. One way to solve this is to lower the vga_update_interval and the keyboard_serial_delay. I lower the value until - I have a minimum respons from keyboard and mouse (say 1 second delay between keypress/mousemove and the screen update) - I still pass the 150 Mhz check The values I used are vga_update_interval: 10000 keyboard_serial_delay: 200 They may be diferent for other computers. Note that bochs, on starting up complains about vga_update_interval with the message "bochsrc.txt: vga_update_interval not big enough!": ignore it. 6) Follow the Windows Me setup instruction ... Just a warning: it is very, very, very, *VERY* (very) slow ... Two days running non stop on my PC. Don't wait ... enjoy yourself during the process ... you that the time. 7) Hardware nightmare At a given moment, you are prompted to detect the hardware. There is a prompt for each type of device: Bus, keyboard, mouse, HD, CDROM, etc. Say NO to everything. If you say YES, sometimes setup will detect your HW, but normaly it will crash with GPF on COMMCTRL.DLL (setup crash, but bochs still alive. Nice!). If you sat CANCEL, setup will stay in this screen forever (ok, ok, I have just wait 10 hours). 8) Configuring Setup will configure you PC. You can set your timezone, etc. Then Setup will create the Statup menu icons. Here, time to time, you will get a GPF in PIFMGR.DLL. Just press Ok and continue. Again this procedure is very very very very very very slow. Worse of all, you cannot leave it running by night. You must press Ok a lot of times to clean the GPF. 9) Restart. At last, setup will restart the PC. Exit Bochs. I recomend to make a copy of WinMe.img just to save all your time. 10) Run bochs again Setup will do some stuff ... just wait After a while, the Start button appearch on the lower left corner of the screen! Just for safe, I executed within WinMe msconfig.exe, and in the advanced tab set the Disk Compatibility mode". Also, I've turned of the menu and windows animations, to speed thinks up a bit. Also it may be a good idea to turn off scandisk on setup. Do not forget to exit from Windows with the Shutdown menu ... 11) That's all Now you can comment out the diskd line in the bochsrc.txt. WinMe.img contains a working WinMe. NOTE: if you lower the IPS, WinMe will be unstable ... surelly a timing issue. But even if IPS is high, lowering vga_update_interval and keyboard_serial_delay will help on getting an acceptable usability. DO not forget to use your Pentium 10 at 500 GHz to get a good speed within Windows. Some bugs i've found - MSDOS Scandisk freeze - Hw detection is very problematic - If bochs is visible when it switchs from text mode to grafic mode, the size of the window is correct. But if Bochs is minimized when doing so, the size of the Bochs window is incorrect. It does not take into account the height of the top banner (the one with the disk icons, mouse, snapshot, etc), so the botton of the screen is clipped. - Dont expect to run WinMe at full speed unless you use your Pentium10 at 1500 GHz - (not a bug, but a comment) The splash screen when booting/shutdown WinMe is double height. I personally prefer to see the full image as it was time ago.