Bochs differs from many x86 emulators because it is written in portable C++ code. While this is a disadvantage in terms of performance, it allows Bochs to run equally well on a wide variety of platforms; it runs on Windows and *nix, and should run on any *nix-like system on which it compiles. No special code is needed to run on a given host architecture. Bochs includes a debugger that allows efficient debugging of even operating system code.
Bochs was written by Kevin Lawton starting in 1994. It began as a commercial product, but 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 http://bochs.sourceforge.net. Since then the Bochs Project has settled into its new home, and around release times has even been the most active project of the week at SourceForge.net.
Why and how did you get started?
Bryce: I was working at a processor design company and we needed to better understand how Linux worked with multiple processors. I searched for processor emulators and found that Bochs was a great starting point. My first project was adding some multiprocessor emulation features to Bochs so that I could run the Linux SMP kernel and study it. At the time, the project did not really have a home, only a mailing list with a lot of patches floating around. Several of us on the mailing list did some research and found that SourceForge.net would provide all of the services we needed to host the project.
Christophe: I joined the project just before Bochs 1.4 was released. At that time I was writing a free VGA BIOS to be used with Bochs and Plex86. I started fixing small issues that were annoying me, like the inability to use Bochs on X11 with a French keyboard. Then Bryce offered me to join the developers team, probably because he was fed up with applying my patches to the CVS. ;-)
Stanislav: I started with a simple Technion project in computer architecture and as a part of project I added to Bochs some little enhancements. I found that Bochs was missing some significant features that I could implement and contribute. I continued to do so even after I graduated.
Greg: I found out about Bochs from a slashdot post about x86 virtualization technologies. That was early 2001, and not much was going on. I coordinated with Kevin and Bryce on the move to SourceForge.net, and then set to work improving the timing model of the bochs system. I've also put in some work on several devices, helping to make Bochs interfaces feel faster to the end user.
What is the intended audience?
Bryce: 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.
Greg: Bochs is most useful for OS developers who need to see detailed debugging information on their system as it is running. It is also useful for people generally interested in system emulation, but is often too slow for these purposes. Many people also use it for running old games, where a slow machine can be as much a benefit as a hinderance.
How many people do you believe are using your software?
Bryce: 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 450 subscribers. The latest version has been downloaded over 100,000 times from SourceForge.net.
What are a couple of notable examples of how people are using your software?
Bryce: 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.
Christophe: In the May 2004 issue of Login:, a French magazine about alternativecomputing and OSS, Bochs is provided on the accompanying CD-ROM for people to test ReactOS without installing anything on their hard disk. In the June 2004 issue of GNU/Linux Magazine France there is the first article of a series about writing a simple OS. Bochs and Qemu are presented and used as valuable development tools (simulator, debugger, log traces).
Greg: I know the author of Minix usually points to Bochs as a good environment to test Minix in.
What gave you an indication that your project was becoming successful?
Bryce: When our 2.0 release annoucement was on the front page of slashdot.com, several of my family members saw it and asked me about it.
What has been your biggest surprise?
Christophe: I was quite surprised to learn that Bochs was actually used for a MIT OS course.
Greg: When we moved to SourceForge.net we were amazed how we jumped to be one of the top downloads. It seemed like there was a lot of pent-up demand to get Bochs going again.
What has been your biggest challenge?
Bryce: Time management. For me, serious software development requires large chunks of time without interruption. One hour at a time is not long enough to get much done. There are months when I can contribute a lot, and others when I can barely keep up with the email traffic.
Christophe: I wished I had more time to work on Bochs. Reading and answering email, testing patches, reproducing and fixing bugs, and research for feature requests and new version releases take a lot of time, and I can't keep up with the current pace.
Greg: Dealing with an all-volunteer team of developers. There are a lot of big projects that everyone agrees need to be done, but no one has the time to tackle because it's a big job that can't really be divided among multiple developers.
Why do you think your project has been so well received?
Bryce: Bochs lets people do things that are very difficult or expensive otherwise. Commerical PC emulators are pricey, especially ones that allow you to stop and look inside the machine while it runs. Also, the developers' mailing list is very active and helps people get going in the right direction.
Greg: At least for a while, Bochs provided the only good method for free system emulation.
Where do you see your project going?
Bryce: We always continue to improve the emulation of peripherals such as network cards and graphics cards. Each operating system uses the hardware in slightly different ways, so it's a never-ending process.
Greg: With the development of system emulation in Qemu, Bochs may refocus on being a good tool for OS development. This has always been Bochs's strength.
What's on your project wish list?
Bryce: Improving video quality, emulation speed, supporting newer types of peripherals, being able to save the machine state and restore it later.
Greg: Someone willing to take the time to implement dynamic translation and really speed things up.
What are you most proud of?
Bryce: I'm proud that I helped to re-energize this project back in 2002. After it had gone for several years without regular maintenance, our team gave Bochs a new Web site, code repository, and bug and feature tracking, and started releasing code again. As some of the original developers have faded in and out of the picture, others have stepped in to continue the work. More than anything else, that convinces me that the project is alive and well.
Christophe: There are a few personal achievement I'm proud of, like implementingCD-ROM booting in the BIOS, but the thing I'm mostly proud of is version 2.0, for the numerous improvements and features contributed by all the regular and occasional developers.
If you could change something about the project, what would it be?
Bryce: It would help to have a designated leader who could consistently devote half or full time to the project, and help to set priorities and a common vision. Some of our subprojects can be completed by one person in his spare time, but others require more planning and coordination than we can typically muster.
Christophe: Speed! This is the ubiquitous criticism about Bochs. Unfortunately, big speed improvements means radical changes in the architecture.
How do you coordinate the project?
Bryce: We discuss roadmaps and ideas on the mailing list, or on IRC. This helpsto set priorities and divide up tasks. But often, since all of us are volunteers with limited time and energy, the projects that get done are the ones that some developer finds the most useful or interesting. We accept patches from the community after testing them out.
Toward release time, we coordinate our efforts more. We do a feature freeze, and one person takes charge of building release candidates (which everyone helps to test and fix), then the release itself. We use CVS tags and branches to keep releases clean.
Greg: Mostly people do what interests them. We also make a lot of effort to keep OSes working, so most testing consists of trying to boot OSes and ensuring that they work.
Do you work on the project full-time, or do you have another job?
We all have day jobs.
If you work on the project part-time, how much time would you say you spend, per week, on it?
Bryce: 1 to 30 hours, varies. Lately, closer to 1.
Christophe: It depends on how much spare time I have left after my day work and family. These days, it's between 2 and 10 hours a week.
Greg: 1-2 hours. I'm no longer a primary developer.
What is your development environment like?
Bryce: Primary development machine: Red Hat Linux, gcc, gdb, gprof, valgrind. For Windows builds: Windows 98, Microsoft VC++ 6.0, Cygwin
Christophe: My development environment is composed of two PC machines, an Athlondesktop and a PIII laptop, both running Debian GNU/Linux. My favorite tools are mozilla, vi, gcc and gdb. I also have access to a PC running Windows 98 and Visual C++ for the Win32 builds, and to a G3 Mac running Debian GNU/Linux for big-endian testing and debugging.
Feb 7, 2004: Bochs 2.1.1 fixed several bugs in 2.1
Jan 11, 2004: Bochs 2.1 improved color display, added 3DNow! and PNI instructions, added PCI and USB cards, and supports VMware hard disk formats.
Dec 21, 2002: Bochs v2.0 : 2x emulation speedup, AMD x86-64, MMX, SSE, SSE2 instructions, wxWindows and SVGAlib ports, up to 8 hard disks/CD-ROMs, TUN/TAP network interface, and many I/O device improvements, Mac OS X/Carbon interface, updated Mac OS 9 port.
How can others contribute?
We currently need help with the following tasks:
We have a project to-do list, and we welcome anybody interested in working on one of these issues.
Some of the items are rather simple and can be implemented by single individuals. Other items are quite complex and development needs to be coordinated. So, if somebody want to contribute, please drop us a note in the developers mailing list, so we know which issue is being worked on, and we can exchange ideas on the subject.
Anyone who has a lot of time to burn who would like to redo the core processor routines for speed would be great.
Project Name: Bochs
Background of Project Leader:
Name: Bryce Denney
Occupation or experience: Web database programmer, microprocessor designer
Education: Bachelor of Arts, Physics. Bachelor of Music, Piano Performance.
Location: Natick, Massachusetts, USA
Name: Chris Bothamy
Occupation or experience: Web Application Developer
Education: French equivalent to a B.Sc. in Computer Science
Location: Paris, France
Name: Stanislav Shwartsman
Occupation or experience: Computer Architecture Research and Development
Education: B.Sc. Mathematics, Technion Haifa, Israel
Location: Haifa, Israel
Name: Volker Ruppert
Occupation or experience: Microprocessor Designer
Education: B.S. Electrical and Computer Engineering, Carnegie Mellon University
Location: Austin, Texas, USA
Quote about SF.net?
Wow, you mean we get all this for free?!
Why did you place the project on SF.net?
It provided tons of tools that helped our project to thrive. I don't know of anything else like it.
How has SourceForge.net helped you?
SourceForge.net exposed me to many open source development tools and techniques which have turned into marketable skills. When interviewing for my present job, it was a pleasant surprise to find that they used Linux, CVS, Secure Shell, Perl, Apache, and a bug database similar to SF.net. SourceForge.net hosts many other projects which benefit me and my company as well, such as Popfile, TightVNC, Filezilla, Nagios, Bacula, and HttpUnit. It also provides a central point for collaboration -- mailing lists, Web page, CVS, downloads, etc. We've really been able to organize as an open source project, which we weren't able to do with only a mailing list.
The number one benefit of using SourceForge.net is:
The Bochs project has used the bug and feature trackers extensively to organize our ideas and task assignments. When the number of tasks seems overwhelming, we use the "group" field to show which tasks are scheduled for which release. Having the historical record of what has been fixed (and how and when) allows users to find solutions to known problems.