Become a fan of Slashdot on Facebook

 



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:
  • Boch vs. VMWare (Score:4, Interesting)

    by thopo ( 315128 ) on Saturday December 21, 2002 @09:02PM (#4938322)
    Does anyone one know which one of them is faster, or let's just say better?
  • BeOS MHz (Score:2, Interesting)

    by Anonymous Coward on Saturday December 21, 2002 @09:03PM (#4938327)
    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.
  • What does it do? (Score:2, Interesting)

    by glennard ( 635971 ) on Saturday December 21, 2002 @09:09PM (#4938360)
    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 seanadams.com ( 463190 ) on Saturday December 21, 2002 @09: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.
  • by reynaert ( 264437 ) on Saturday December 21, 2002 @09: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.
  • Re:Just curious... (Score:1, Interesting)

    by ksuMacGyver ( 562019 ) on Saturday December 21, 2002 @09:32PM (#4938454) Homepage
    Look here [sourceforge.net]
  • by garcia ( 6573 ) on Saturday December 21, 2002 @09:32PM (#4938455)
    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.
  • by Ryu2 ( 89645 ) on Saturday December 21, 2002 @09: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.
  • Comment removed (Score:2, Interesting)

    by account_deleted ( 4530225 ) on Saturday December 21, 2002 @09:37PM (#4938480)
    Comment removed based on user account deletion
  • by justMichael ( 606509 ) on Saturday December 21, 2002 @10:02PM (#4938560) Homepage
    You might want to look at Win4Lin [netraverse.com]. The last version I used was 3.0 so I can't speak about 4.0. But in my experience 3.0 ran Win 98 just as fast if not fatser than native, probably due to disk IO. YMMV.
  • by mirabilos ( 219607 ) on Saturday December 21, 2002 @10:04PM (#4938569) Homepage
    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)
  • Re:Trade off ? (Score:2, Interesting)

    by Zzootnik ( 179922 ) on Saturday December 21, 2002 @10:20PM (#4938638)
    Interesting...I have the same problem...How about this for a solution...Use 98lite and install the absolute most stripped down version under bochs, then strip it down even more by replacing the shell with Photoshop (normally explorer, right?) which under windows is basically a replacement desktop anyway...

    Result--> massively quick win98 install booting automatically into Photoshop...Almost like one (slightly overweight) application... at least that seems like it would be the slickest way to do it... Last time I checked, photoshop didn't run too great under wine, and the 98lite bare bones install could cut stuff down to about 40 megs...
  • by phr2 ( 545169 ) on Saturday December 21, 2002 @10: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 runderwo ( 609077 ) <runderwoNO@SPAMmail.win.org> on Sunday December 22, 2002 @12:03AM (#4938961)
    Yes, DOSEMU usually works better, but AFAIK it only works on i386 and Linux (and maybe some BSDs).
    BSD has their own "doscmd". Dosemu currently only works on Linux/i386, but they are adding a 386 emulated core that should eventually release the architecture restriction. It is, however, highly dependent on specific features that have been merged into the Linux kernel.
  • by Sex Tourist ( 410414 ) on Sunday December 22, 2002 @02:43AM (#4939475)
    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".
  • Re:here it is: (Score:2, Interesting)

    by Malor ( 3658 ) on Sunday December 22, 2002 @04:14AM (#4939658) Journal
    More precisely, VMWare virtualizes the hardware. Most of the time, the virtual machine programs are just X86 programs and just run on the native hardware at full speed.

    However, PC I/O is (always??) memory-mapped. The processor writes commands to certain places in memory to cause things to happen. VMWare virtualizes this process; it uses the memory management unit to trap attempts to write to I/O devices on virtual machines. It then figures out what the virtualized program is trying to do, and does the actual correct thing with the real hardware. If the virtual machine is trying to write to disk, for instance, VMWare emulates the responses that the real hardware would make, but actually writes to or reads from a file on the host machine's filesystem.

    Apparently this trickery runs at a lower level than the operating system, because you can run just about any OS that's out.

    You notice this overhead the most on video and hard disk writes. Both video and disk I/O are *a lot* slower under VMWare. Network operations, however, aren't very affected; they run at nearly full speed. You can run most server-type applications very nicely under VMWare, unless they are extremely disk-intensive. You wouldn't want to run a database, but Apache runs great.

    Games are pretty much a loss in VMWare; the video virtualization is simply too slow. Solitaire is fine. Quake would be a slideshow, if it ran at all.

    To help avoid the disk I/O bottleneck, VMWare has the ability to assign a 'raw disk' to a virtual machine. This would probably be a lot faster, but I haven't worked with it. There are also versions of VMWare that are designed to entirely replace the host operating system. I imagine that they are much more efficient, but haven't worked with them either. (they cost thousands, not just hundreds.)

    Bochs, on the other hand, emulates EVERYTHING, including the CPU. This full virtualization allows the emulation to run on any processor, but it's A LOT slower than a real CPU (which is essentially a highly-tuned hardware emulator of the X86 instruction set.) The X86 is devilishly hard to emulate properly, because of all the different instruction layers (8086, 80286, 80386, 80486, 80586, 80686). You have to spend a lot of CPU time figuring out what each instruction is: is it 8-bit, 16-bit, 32-bit, MMX, or SSE? You can't take the same kind of easy shortcuts you can with cleaner instruction sets. Decoding takes a long time and a lot of host processor cycles, so you take an enormous speed hit.

    On top of that, you ALSO have to virtualize the video, I/O, and network, so you get all the overhead of VMWare, above and beyond the CPU emulation bottleneck. You probably couldn't run a realistic server of ANY sort under Bochs.

This restaurant was advertising breakfast any time. So I ordered french toast in the renaissance. - Steven Wright, comedian

Working...