Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Announcements

Bochs 2.0 Released 284

Jas Sandys-Lumsdaine writes "Bochs 2.0 has just been released - project lead Bryce Denney writes: "It's been a busy 6 months since our previous release! Bochs is now about twice as fast as version 1.4.1. Also, we can now emulate MMX instructions, SSE/SSE2, and even AMD x86-64 instructions if you turn on the appropriate configure options. The emulation improvements have paid off; several people have been able to install Windows XP recently." Excellent stuff."
This discussion has been archived. No new comments can be posted.

Bochs 2.0 Released

Comments Filter:
  • by Anonymous Coward on Saturday December 21, 2002 @08:01PM (#4938312)
    Bochs is a highly portable open source IA-32 (x86) PC emulator written in C++, that runs on most popular platforms. It includes emulation of the Intel x86 CPU, common I/O devices, and a custom BIOS. Currently, bochs can be compiled to emulate a 386, 486 or Pentium CPU. Bochs is capable of running most Operating Systems inside the emulation including Linux, Windows® 95, DOS, and recently Windows® NT 4. Bochs was written by Kevin Lawton and is currently maintained by this project.
    • by rve ( 4436 )
      What would a 386, 486 or pentium with windows and a NIC cost nowadays? Up to $50? It would still execute those old x86 apps and games fastre and probably more reliably... This sounds like a university research project. Useless but cool.
      • I disagree. Something like this is a godsend if you are doing kernel development or other such low-level development.

        Your view is too shallow. Think about more than just the "software users".
  • by Hadean ( 32319 ) <hadean.dragon+slashdotNO@SPAMgmail.com> on Saturday December 21, 2002 @08:01PM (#4938313)
    I tried using Bochs 1.4.1 to play some old DOS games (since VMware doesn't support SoundBlaster Live! for whatever reason), and it was so slow that my type "md games" took several seconds! With a bit of tweaking, I was able to get it decently working, but games would be horrendously slow... "Jones in the Fast Lane" was so slow, I almost screamed! (Of course, then it froze, but oh well...) My point: anything would be faster than what it was... Anyone have any experience with it yet?

    (My system isn't a super one, but 800mhz/512megs of RAM should be enough to play DOS games)...
    • by Anonymous Coward
      Should be, but keep in mind BOCHs emulates everything completely in software. The benefit of doing it this way is that BOCHs will run on -any- arch capable of compiling it, whereas VMWare, which uses the existing hardware for 'emulation' will only work on x86 machines. As you've noticed though, speed is the obvious tradeoff, with BOCHs being considerably slower than VMWare.
      • This is no excuse.
        In fact a company that I will possibly be working for has managed to do this but get the code to run faster than it runs natively! It has to be seen to be believed. (If you are wondering how it can run faster, think of the whole code-morphing thing)
    • why wouldn't you use DOSEmu which is far better at running DOS games than BOCHS?
      • Cause I don't use Linux?
      • I think that DOSEmu is an OS simulator, while BOCHS is a hardware emulator. this means that with BOCHS if one day you get bored of Jones in the Fast lane, you can just install another x86 os from (cough) original disks....

        Also, I believe that BOCHS is a smarter idea overall, because it deals with the better documented x86 architecture, rather than trying to emulate a bunch of byzantine APIs like WINE or worse yet reserved memory mappings of DOS. but that's just my nontechnical opinion.
    • Dude(ette?),
      Maybe you should upgrade to 2.0 and test it out again. I think your case would be a valuable pice of information.
    • Er wait, it's still 1.4.1 on their site... 2.0pre4 only. Who said it was released?
    • I tried using Bochs 1.4.1 to play some old DOS games (since VMware doesn't support SoundBlaster Live! for whatever reason), and it was so slow that my type "md games" took several seconds! With a bit of tweaking, I was able to get it decently working, but games would be horrendously slow... "Jones in the Fast Lane" was so slow, I almost screamed! (Of course, then it froze, but oh well...) My point: anything would be faster than what it was... Anyone have any experience with it yet?

      (My system isn't a super one, but 800mhz/512megs of RAM should be enough to play DOS games)...


      For now at least, the best way to enjoy those classics is to get hold of a 486/low end Pentium, bung in a soundcard and CD-ROM drive and install MS-DOS 6.22 (or failing that, Win98 will do for most games). I've been playing Monkey Island 2 all day using this setup, and no, I don't usually spend my saturdays doing that :-)

      I can still remeember how to complete Part One and get LeChuck resurrected, wahey!
    • by reynaert ( 264437 ) on Saturday December 21, 2002 @08:32PM (#4938453)
      If you just want to play old DOS games, try DOSBox [zophar.net]. It's specifically designed for this goal, and cheats in various ways to make it fast (for example, the BIOS and DOS are built-in instead of emulated). The main problem with it is the lack of 386 Protected Mode support.
      • Looks like a nice program... Sadly it doesn't play Jones in the Fast Lane, no matter what I try it ends up with the error:

        Exit to error: Call to interrupt 0xCD this is BAD

        But, it's not finished yet... I'll give it a shot later down the road. I'll just stick with doing it the hard way (having a second computer)... *shrug*
    • If you're running NT or 2000 you can try out VDMSound [sourceforge.net]. I've had a fair amount of luck getting some old DOS games to work correctly in a command prompt box under 2000.
    • I wouldn't call it SB Live! since it's PCI device. When I tried to run one of Craig's PCI Programs [datafast.net.au], it wouldn't show up as a PCI device at all.

      According to VMWare's support files [vmware.com], it is compatible with an SB16. (Ok, so compatible != actual card, but if they say to use it...)
  • Boch vs. VMWare (Score:4, Interesting)

    by thopo ( 315128 ) on Saturday December 21, 2002 @08:02PM (#4938322)
    Does anyone one know which one of them is faster, or let's just say better?
    • Re:Boch vs. VMWare (Score:4, Informative)

      by damiam ( 409504 ) on Saturday December 21, 2002 @08:07PM (#4938346)
      Bochs emulates the entire x86 instruction set, so it will run on any architecture. VMWare simply creates a virtual machine and passes instructions directly to the processor, so it only runs on x86 machines. VMWare is about a zillion times faster and easier to set up, but it also costs infinitly more than Bochs.
    • Re:Boch vs. VMWare (Score:5, Informative)

      by Mitchell Mebane ( 594797 ) on Saturday December 21, 2002 @08:12PM (#4938369) Homepage Journal
      That's like comparing apples and oranges. VMWare is a virtual machine; it only emulates certain parts of a computer. It's "passes through" most of the work to the host machine. This means that is a lot faster, but it can only run programs designed for the host architecture. Bochs, OTOH, is a full-fledged emulator, which, eventually, will let you run any program on any machine. Since it emulates every, though, it is FAR slower that VMWare. I hope they add some sort of JIT engine sometime.
      • Re:Boch vs. VMWare (Score:4, Informative)

        by ipsuid ( 568665 ) <ipsuid@yahoo.com> on Saturday December 21, 2002 @10:54PM (#4938926) Journal

        Precisely.

        I've used all three (Bochs, WINE, VMWare) and each are designed for different purposes.

        Bochs is quite slow for normal application usage, but it is absolutely ideal for low level OS development work. Compare crashing your real machine hundreds of times while debugging your bootloader and memory management code to having a "virtual" crash in Bochs. Also, Bochs provides stubs for implementing runtime instrumentation, so you can use powerful debugging techniques that remain 100% insulated from the debugee.

        If you are primarily concerned with running one or two Windows apps under Linux that you just can't live without, then Wine is for you. Sure, there are still some rough edges, but in many cases, your application will actually run faster under Linux then under Windows. However, parts of Wine are still incomplete, so YMMV. The biggest plus with the Wine approach is that interaction between apps is a tad simpler.

        VMWare creates a bit of a middle ground between Wine and Bochs. I've used it for the past two years to keep a copy of Win98 and Win2k on my Linux box. Because being an independent programmer/consultant sometimes requires me to use technologies I don't exactly embrace, the Windows in VMWare option allows me to maintain productivity while not opening myself to network *cough* problems. In addition, I can keep multiple OS's running concurrently so testing and debugging apps is fairly painless. Except for a few operations (installing software, for example) the virtual machine runs almost as fast as if I ran the OS natively. BTW, when Windows inevitably hoses itself, I have it running again in the time it takes to copy a 1G file ;-)


        So in summary, if you are doing some hardcore hacking, get yourself Bochs... it will save you many many reboots.

        If you want to run MS Office and can live with a few glitches, get yourself Wine.

        Looking to simplify cross-OS application debugging, need to have Windows close at hand, doing tech support? Then VMWare is your answer.

        Want to run the latest DirectX 9.0, wet your pants LOD game... yet run Linux as well? Get yourself a second machine.

    • > Does anyone one know which one of them is faster, or let's just say better?

      As per the BochsFaq Page: [sourceforge.net]

      Q: Tell me about peformance 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 sotware uch as plex86 (free) or vmware (commercial).
      • Why so slow? (Score:3, Informative)

        by smagoun ( 546733 )
        1.5MIPS seems awfully slow to me....like orders of magnitude slower than it should be. VirtualPC - a commerical product that emulates a PC - runs somewhere around the speed of a 233Mhz PII on my crufty old Powermac, which rockets along at 450Mhz. VPC provides full emulation of a PC the way Bochs does, but it's ~200x faster. That's an awfully big difference. What accounts for that difference? Is there any chance that Bochs will close the gap sometime soon? I'd much rather use a free product than VPC, but with a performance gap like that it's tough to justify...
        • Re:Why so slow? (Score:2, Informative)

          PPC was designed with emulation in mind. When you have 32 gp registers, it's easy to alias them to the x86's 8 gp registers. Also, VPC is a commercial product written by people that have *years* of experience writing x86 emulators back when Macintoshes were running on 680x0s at 40mhz or less. The GNU coding standards state that it's ok to assume unlimited core memory, processing power, etc.
  • by orbital3 ( 153855 ) on Saturday December 21, 2002 @08:02PM (#4938325)
    If you go to the sourceforge download page, located here [sourceforge.net], it has links to all of the 2.0 final downloads. Have fun killing the servers... I already got my copy. :)
  • BeOS MHz (Score:2, Interesting)

    by Anonymous Coward
    Huh? I have a beta of it which is what appears on site. What was released, again?

    I ran BeOS Max 2.1 on it, even though it hangs before running to completion. (As well as regular BeOS, so it's not the known AMD XP / Pentium 4 CPU bug.)

    The debugging console reports Bochs running as 13MHz. My machine is 1GHz. Still, it's speedier than older versions.

    I am still waiting to be able to run BeOS on it.
  • by bakes ( 87194 ) on Saturday December 21, 2002 @08:05PM (#4938338) Journal
    ...is some idiot to try to run Windows apps inside WINE running in Bochs under VMWare.

    And don't tell me you didn't all think the same thing as soon as you found out what Bochs was.
  • What does it do? (Score:2, Interesting)

    by glennard ( 635971 )
    anyone care to explain exactly what the software does? I don't really get it. Does it emulate different OS's while running an installed OS?
  • by Hadean ( 32319 ) <hadean.dragon+slashdotNO@SPAMgmail.com> on Saturday December 21, 2002 @08:16PM (#4938390)
    I know I already posted something similar, but only 2.0pre4 is available on their site. I used it, and it was only a smidgen faster than 1.4.1 - other nice goodies, of course, not still not powerful (speed wise) enough to do anything useful (games, larger software, etc.) I can't wait until it speeds up, though, since it seems to work better than VMware for me... (no pretty GUI though)

    (rant)
    To Slashdot Editors: CLICK THE FREAKING LINKS. I'm getting really, really sick of all these false stories. I swear, although it's only a joke right now, the fact that people can't trust Slashdot is becoming a real issue...
    • Re:2.0pre4 (Score:3, Informative)

      by kpansky ( 577361 )
      Sorry -- you are incorrect. The webpage for the site is not updated as fast as Slashdot can find out about their new releases. Look for a link on the left for "all releases" and download Bochs-2.0... it wasn't that hard.
  • by seanadams.com ( 463190 ) on Saturday December 21, 2002 @08:28PM (#4938442) Homepage
    But I have to admit I'm not all that well read on the state-of-the art in emulation. I know that Wine is like a clone of Windows running natively on Unix, so it's fast. Bochs is a full-blown, platform independent emulator, so it's compatible but slow. Vmware is X86 only, so it's faster, right?

    So many choices, but I really don't have time to try everything out. Mainly I care about compatibility over performance. $250 won't break the bank, but free is better of course. I need to run a few simple apps like UPS shipping software, but also a bunch of specialty stuff where hardware compatilibty might be hard and the apps aren't likely to have been thoroughly tested already (OrCAD, Microchip MPLAB, Xilinx WebPack, stuff like that). I could give a flying sh*t about games, but I suspect that's mostly what people want these for.

    Could anyone with experience using several of these emulators shed some light? It'd be really nice if the authors would provide some compatiblity/performance/stability matrices for popular apps, to help us choose.
    • if $250 isn't going to break the bank, buy a Windows system and use it for Windows only. There is absolutely no valid reason for emulating under Linux if you have $250 to spend. You are going to get a lot more out of your money that way.
      • But 250 isn't just for one system. VMware allows you to run as many vms as your ram permits. If I were doing something where I needed to keep win 98 around, I'd probably use vmware to emulate it rather than keeping a crappy box around

        ostiguy
        • I do this for various testing, including browser testing. With VMWare, I can keep a bunch of old browser combinations around with no extra hardware. Thanks to VMWare's "undoable disk mode", I never have to worry about windows corruption.

          And even better, when a colleague needs to do testing, I just copy the virtual disk onto a CD. Much easier than hardware.
      • Boy, do I disagree.

        If, for example, you've got a laptop, and have needs for both Windows and Linux, a perfect virtual machine environment is absolutely desireable. You can take your laptop anywhere, and simultaneously run apps of different varieties.

        I've got an iBook. I'd never have considered switching to Linux without MacOnLinux [maconlinux.org]. With proper virtual machine design, and a native processor, there's no crippling speed penalty either. Even if I had $1200 for another iBook. I've got both right here.

        Even with desktop machines, if you've spend $1500 on your primary system, WindowsXP on a virtual machine is going to be a hell of a lot faster than a new $250 machine.

        Oh. Wait. You said emulation. In that case, I couldn't agree more strongly. I just don't know of any $250 processor emulation packages. VMWare is just a virtual machine, right?
      • And what about kernel developement?

        It sure seems nice to have a development environment for kernel's in which you don't have to reboot the whole computer when you make a mistake.

        Furthermore, debuging a kernel on real hardware is inherently intrusive. Doing the same on a hardware -emulator- such as Bochs is not.
  • by Ryu2 ( 89645 ) on Saturday December 21, 2002 @08:35PM (#4938476) Homepage Journal
    One thing Linux on non-x86 platforms lacks is transparent X86 emulation, like on the Macintosh with its transparent 68K emulation, you click on a 68K app and it just works. I should be able to run a X86 ELF image on a non-X86 Linux box and have it just WORK! The Bochs approach is not the best way, since it's a virtual machine and emulates everything. A better way would be for X86 emulation only when needed, such as the application program code itself (syscalls continue to use the native library)

    Anyone look at the possibility of incorporating such emulation into the Linux kernel? It would be a enormous boost for acceptance of Linux on non-X86 platforms.
    • It actually has.

      You can run x86-16 applications on x86-32 CPUs,
      and you can run ELKS (Linux/8086) applications
      inside GNU/Linux/x86-32 (Linux/80386).

      Plus, x86 is a darn complicated architecture,
      think of all the legacy parts.
      This is why emulation writers have such a hard
      job. Even coders of projects such as Wine or
      the BSD Linuxulation (those are no emulation,
      but just a transfer layer) have a hard time to
      code, because most of the stuff is barely docu-
      mented, if at all.
      Again a problem is, the hardware basics books were
      written in the late 80es or early 90es, and they
      aren't available for sale usually any more (I tried
      to get a BIOS book from Microsoft Press here in
      Germany, but they couldn't even order it from the
      USA, and that was about three or four years ago!).

      If you actually have interest, I think the projects
      (bochs, plex86, wine) have fora and newsgroups,
      or at least irc channels (the webpage is a good
      start; most free projects sit at irc.freenode.net)
    • One thing Linux on non-x86 platforms lacks is transparent X86 emulation, like on the Macintosh with its transparent 68K emulation, you click on a 68K app and it just works. I should be able to run a X86 ELF image on a non-X86 Linux box and have it just WORK! The Bochs approach is not the best way, since it's a virtual machine and emulates everything. A better way would be for X86 emulation only when needed, such as the application program code itself (syscalls continue to use the native library)

      Dealing with endianness issues when wrapping all possible system calls would be so horrible it's not funny. Too many calls, too much mucking about to see what's *really* endian-sensitive under what conditions, and things like driver IOCTLs that you just plain don't know whether to wrap or not.

      OTOH, emulating x86 is a horrid screaming nightmare. The 68k architecture is relatively clean, relatively simple. i686 is, well, *not*. A clean, easy to maintain implementation runs extremely slowly. An implementation based on JIT cross-compiling and re-optimization of code improves to merely "crawling so slowly you want to claw your eyes out", as you have to track *all* possible side effects of all instructions, in an architecture that was definitely not designed to make that easy. If you're a god and write an emulator that not only cross-compiles but that tracks all side effects, finds out which ones don't matter and discards them, speculatively unrolls and optimizes and maybe even skips loops with code that checks for premature exits and state changes (to roll back state to non-unrolled/skipped loops in case of mispredicts), and in all other ways just extracts the salient computations being performed while discarding all busy-waiting and non-computation cruft, then it'll just be "slow".

      This would be a really cool series of PhD topics for about a dozen skilled CS grad students. After 10-15 years of work, this might be do-able, and the cross-compiling/optimization technology developed would have many other applications.

      In the meantime, recompiling is probably the way to go.

      In summary, good, real-time x86 emulation is a "pick one" scenario at the moment.

      The Crusoe doesn't count, as they're mapping to hardware specifically designed to emulate x86 machines.
  • Re: (Score:2, Interesting)

    Comment removed based on user account deletion
  • by Chester K ( 145560 ) on Saturday December 21, 2002 @08:41PM (#4938496) Homepage
    It'd be nice if they'd have updated their webpage to say so.
  • Be still my heart! (Score:2, Informative)

    by Isbiten ( 597220 )
    * Added plugin support for Linux, Solaris, MacOS X , and Cygwin. Plugins allow you to compile Bochs with support for many options and load the pieces that you want at runtime. Be still my heart!!
  • by phr2 ( 545169 ) on Saturday December 21, 2002 @09:28PM (#4938663)
    www.plex86.org sends a 404. And plex86's Savannah project page [nongnu.org] doesn't show much sign of activity. Is it moribund? Dead? How did it compare with vmware at its last sign of life?
  • by pla ( 258480 ) on Sunday December 22, 2002 @12:55AM (#4939318) Journal
    I love all these questions about "speed". If you want speed, use VMWare. Bochs EMULATES an 80x86, pure software, no hardware involved.

    So why would you want to use it?

    Personally, I use it mostly to run old DOS games. Games that won't run at all under Windows (you could insert "Linux" there just as well, or "OS X", or "HP-UX", or whatever you run on reasonably modern equipment). Games that run waaaaay too fast. Games that "don'y play well with others" and you wish you could have stuck in on its own machine even when you really *did* run DOS just to keep it from breaking other programs.

    It makes a GREAT debugging tool, for those who know how to write low-level code. As long as your problem doesn't involve instruction timing or asynchronous events, Bochs works almost as well as a VERY expensive ICE.

    Another nice use, I already mentioned partially, you can put a program in it's own "clean room". Ever wanted to see how some of the classic virii worked but didn't have the balls to risk your own machine? Put it in a Bochs and let it do its thing.

    Additionally, IMO, the speed (as of 1.4, and they claim twice the performance for 2.0) suffices for any CPU or graphics non-intensive task under Windows 95 OSR2, with FAR better compatibility than Wine (Not to disparage Wine, a great and worthy poject, but you just can't beat the real thing for accuracy of emulation )

    The one "bad" thing about Bochs, and I hope a developer for it reads this, you need to manually calibrate the IPS, and then everything else *relative* to that value. Although I understand why getting an *exact* value counts as an almost impossible feat, I don't see why a simple few-second internal benchmark at startup couldn't come to within 10% of the "right" value. Admittedly, though, I haven't played with 2.0 (away from home for a few days), so if you've added that for this release, my apologies (and thanks).
  • Reverse-engineering Windows applications. Normally it's easier to just guess how something works and re-implement it in Linux, but guesswork won't help you decode an undocumented compression algorithm or decrypt a DRM-protected movie.

    True, SoftICE is much faster and has better debugging features. But Windows developers aren't stupid -- if they really don't want you stepping through their code, the program can either disable SoftICE, or detect its presence and refuse to run.

    That's the advantage of Bochs: It's undetectable. Slow execution won't give it away, because the real-time clock is as fake as all the other Bochs hardware. It's like hardware ICE without the $40,000 price tag.

    Also, because Bochs is open-source, you can put in useful hacks like "Copy this big chunk of memory from the virtual computer to a file on the real computer every time this line is executed".
  • I have an old Umax parallel-port scanner for which there is no SANE backend to run it under Linux. Has anybody tried using Bochs to drive anything like this? I ask because I've (so far) had limited success with Wine...
  • I hope they have fixed Bochs .bochsrc config file parser. In 1.4.1 (the last release) in certain parts of the file you have to write "romimage: file=path/to/somewhere" and other places just write "floppya: 1_44=/path/to/somewhere/" with no file directive. Annoying for newbies.
    I did get Minix booting on top of Bochs on top of Linux. I should have tried Minix->Bochs->UML->Linux but I didn't bother. Shows the usefulness of good interfaces.
  • Booting from Floppy...
    [snip cos of /. lame junk char filter
    PBS...Plan 9 from Bell Labs
    entry: 80100020
    cpu0: 2MHz GenuineIntel P5 (cpuid: AX 0x0513 DX 0x800111)
    9486 free pages, 37944K bytes, 167544K swap
    ilock:: ad de ad de 06 00 00 00 3b 89 18 80 08 70 2c 80 01 00 00 00 70 65 01 80
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00
    ilock:: ad de ad de 06 00 00 00 3b 89 18 80 08 70 2c 80 01 00 00 00 70 65 01 80
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00

Money will say more in one moment than the most eloquent lover can in years.

Working...