Slashdot Mirror
Bochs x86 IA-32 Emulator 2.1 Released
Asmodeus writes "Just noticed that the 2.1 release of the Bochs IA-32 emulator is out at the Bochs home page
For those not in the know, Bochs is an open source implementation of the x86 instruction set(s) and a virtual PC (al la VMWare) which is capable of booting FreeDOS and Linux under the host control of another OS."
that would imply that they actually *READ* the articles before they post them... which we all kow is not the case ;)
It would be, if darWINE actually used Bochs...
Bochs emulates the IA-32 instruction set and enables you to run IA-32 software on any sort of hardware that you can compile Bochs on. (eg. I once ran it on a MicroVAX at an incredibly slow speed)
VMWare requires IA-32 hardware. Most of the instructions are executed natively and only some of the priviledged operations are emulated so that whatever is run under VMWare can work as if it has full control over the CPU while in fact being an un-priviledged task.
Nice! I haven't checked tried it out yet, but if its speed is comparable to VMWare, then it's yet another step towards Windipendence. I use Linux 80% of the time, but I find myself returning to Windows for two things. 3dsMAX and Adobe stuff. The latest versions of either of which don't run in WINE, unfortunately enough. I think I'll give Bochs a try.
Bochs isn't just capable of running DOS clones:
Operating Systems inside the emulation including Linux, Windows(R) 95, DOS, and Windows(R) NT 4
It can also run Windows 2000 - and probably XP as well if product activation works.
Wow.... ummmm.... slashdot?
;-)).
Could we not post "news" about things that came out an eon ago? Seriously... ROFL,,,,
----->
Bochs is kind-of OK. I use it regularly when I work on my exokernel project and it really IS A GREAT developing/debugging tool (especially if compiled with the GDB stubs
However, however, however... I wouldn't consider Bochs useful for anything other than hacking around with kernel/os stuff. Bochs needs a re-write from scratch and emulate a real standard PC motherboard - not an 80386 with i486, pentium, athlon, mmx, PCI, USB, ATA etc... hacks around it. PCI support is non-existent. Video is flakey - well you can get VESA-compliant > 800x600 if you physically change the source (easy). All emulated devices are ISA "bus"-based. Over the years stuff just kind-of gotten piled on, and on and on - with no sensible strucure. I am not talking out of my ass either - at some point in my life I felt that Bochs would be a great project to hack.
Did you even read the blurb? It said right there that it'd use Bochs.
I meta-mod all positive moderation Unfair, because it's abuse of the system.
Many others have already posted this, but VMware != Bochs, because VMware uses virtulization to run a guest OS with minor overhead on a host system. Bochs, on the other hand, emulates everything, even if the host system is IA32, causing massive performance degredation. I see that your applications are rather large scale(3DSMAX and Adobe applications) - and probably would rely heavily on graphics adaptor and memory. Bochs is definately not your answer, as if you could even get it to work, it would be so incredibly slow that you'll forget why you were doing it in the first place before the program even loads (trust me, it has happened before).
Look to VMware to do things like this - it may have a fee attached, but its fast and capable, but not open source.
Perhaps the person who submitted the article did so from inside Bochs.
/. article.
Gotta love that blazing static instruction translation speed! Only a month or so to fire up a web browser and post a
"The worst tyrannies were the ones where a governance required its own logic on every embedded node." - Vernor Vinge
Darwine is going to use QEMU
But if it's retro DOS games you're after check out dosbox which runs pretty fast and runs on many platforms.
Doesn't it make you feel good to know that our freedoms are protected by politicans, lawyers and journalists.
I know that in the past, the number of registers of the PPC was far in excess of the capabillities of the x86. Example: No PPC emulator yet exists, no matter what vaporware merchants have said in the past.
Finally, my one experience with Bochs was on BeOS. I couldn't figure it out. On the other hand, Virtual PC was easy as pie. Why doesn't Bochs copy the usabillity of Virtual PC --- the gui is neat and clean, plenty of options; throw open source in the mix and we could have a weiner. (And a real alternative to MS owned, newly activation-coded Virtual PC.)
I stopped upgrading when MS bought it. It was only fair.
Xen has already been covered on slashdot
great for OS Systems development, but not much more. If you are programming an operating system, there is nothing better then Bochs running with gdb debugging stubs. Peroid. All this talk "Bochs can't run photoshop at a good speed" and "Bochs takes for ever to load windows" is bulljive. Of course it does, because that's not the point! Why do I own a 386 and use it with DOS 6.22? Because I want to do assembly programming and test out algorithms written in IA32 assembly. If I tried to run PS 8 and WinXP on it and subsequently complained about the speeds, I'd be flamed to death. The same goes for bochs. Kudos to the developers! A lot of great improvements were put into this release, everything from 3D assembly instructions to a whole new disassembler. Bochs is every OS Developer's dream come true. And it's just gettin' better... (Also, the best "bug fix" imho is that you don't need an extra font installed in X-Windows now). And if you want to emulate windows and have it run fast, go buy a $400 PC from Walmart. They play quake fine while waiting for the latest kernel to compile. :->
- Simrook
'Truth' is linked in a circular relation with systems of power which produce and sustain it...
Don't you mean that the other way around? :-P
I tried bochs a while ago, thinking I could get a virtual Windows 98 running on top of Linux.
I was wrong.
It was hard to install, and even when it did (after waiting for 2 hours + on a 2.4Ghz machine), it crashed BAD.
Serves me right I guess.
READY.
PRINT ""+-0
If you want a free, open-source and (fairly) portable x86 emulator that provides better performance than Bochs then you could do far worse than QEMU. It uses a nifty dynamic recompilation techinque for its CPU emulation which gives much better speed than Bochs's interpretive emulation while remaining relatively easy to port.
It's a young project, and it has a long way to go before it'll be a real alternative to VMWare for most people, but it's getting there pretty quickly - the recently released 0.5.2 can already run Windows 98.
Gotta love that blazing static instruction translation speed! Auctually I gotta say I've noticed large speed improvements on i86 hosts between this and 2.02. Now if only they would release 2.1.1 already with the bug fix so you can compile in both x11 anf rfb(VNC) console support Also the bochs people outright admit that it is slow. They refuse to add any kind of trickery like running instructions natively on intel becasue its meant for debugging OSes and the like. Sometimes you need to be able to run through your OS's boot up one instruction at a time to find a bug. This allos you to do that.
--- Justin Dearing http://www.justaprogrammer.net/ We're just programmers.
This post has no point. It just provides some general (hopefully interesting) background info.
As many people pointed out, Bochs is an x86 emulator, rather than a virtualization system like VMWare. Emulation means that you have a representation of an x86 machine in memory, look at each instruction, and change the representation appropriately. Virtualization means the code runs on the actual CPU natively, and uses 386 ninja powers to intercept all I/O calls and reroute them to the base OS.
As a result, Bochs will run on any platform. VMWare will only run on x86. Bochs is slow enough to be useless for most common uses (a bit over a 100x hit in speed). VMWare has almost no hit in speed.
However, the free software community did have a project that attempted to reimplement VMWare. That project was called Plex86 (http://plex86.sourceforge.net/). For reasons that I do not know, Plex86 recently reinvented itself not to do full hardware virtualization -- rather, it does not implement the I/O layer, and instead provides special drivers for Linux to talk to its I/O layer. As a result, it can only run Linux (although it claims to run it reasonably well). They may implement drivers for other platforms, but I would be fairly sceptical of any real Windows support anytime soon. That seems a lot less useful now...
The Plex86 project, however, claims the possibility of using their virtualization technology in conjunction with Bochs to make a useable system: "There is the potential to use plex86 as an accelerator for bochs, as was demonstrated some time ago." (source: Plex86 FAQ). Likewise, it seems that if Bochs was more intelligently implemented, they could use just-in-time recompliation, a la Java or Transmeta, since they are effectively treating the x86 ISA as bytecode. That would be in the very, very distant future, but if either of these is implemented, the Bochs project is not as hopeless for end-user use as it may at first seem... Either or both of these technologies ought to give reasonable performance.
One problem is that VMWare is creating a patent minefield in front of Plex86 and Bochs. I am not familiar with all of the patents, but from what I've heard, they've got a pretty wide field of IP cut out. I'm not sure how hard they'll exploit it, since the people working there seem like nice guys, and understand the whole open/Linux/GNU/free/etc. thing. On the other hand, so did Caldera a few years back, and VMWare is definitely getting those patents for a reason....
One final point -- properly used, emulators like Bochs can provide amazingly powerful debugging tools. You can run a full x86 machine (admittedly at very slow speeds), but grab snapshots of the system memory at different points. You can then roll back, use a capture of all inputs to roll forward, etc.
I recently needed native windows support for a small project at the firm. (WINE wasn't doing it for me) and I fired up windows 98 in bochs. It was rather nice, had a 2 gig img and 128 megs RAM dedicated to it and it ran fairly smooth. Granted I could only boot it in this thing called "safe mode" or something like that. I did with it what I needed to do and then deleted the .img and .bochsrc. I never had to make any permanent changes to my computer. I must admit that Linux ( Unix in general) runs much better under bochs, but Windows was holding its own when IPS (instructions per second) was set to 5 million. I don't know if Windows was lagging as compared to Linux because of code quality or if bochs is geared towards linux more, or if that "safe mode" thing runs slower, so I'm not putting Windows down, just saying it doesn't seem to perform as well to me (Although I give Redmond an A+ for gui design).
Regards,
Steve
P.S.Way to go bochs team! Keep up the awesome work.
It can emulate AMD's 64 bit processor just fine.
Regards,
Steve
On their main page in the first paragraph it says ,"Bochs can be compiled to emulate a 386, 486, Pentium, Pentium Pro or AMD64 CPU, including optional MMX, SSE, SSE2 and 3DNow instructions."
Regards,
Steve
Yeah, it was posted here on the 12th of January, 2004.
Uhh, did you bother to read the link? Ohh wait, this is /.
If you HAD bothered to go to the BOCHS site you would notice that it DOES do 64-bit emulation. More specifically, it emulates the AMD64 instruction set (aka x86-64). This is rather nifty in that it allows developers to test out code for AMD64 without having to purchase the hardware. Obviously not an ideal development platform, but it could be useful for some.
Plex86 (and Xen, VMware, and Connectix, and Ensim, and others) are the things people should look at if they want fast virtualization of x86. The trouble all these technologies run into is that IO has to go through the "host" OS (the one actually running on the metal) - often popping into userspace to do it (read: context & ring switches --> slow!). This is necessary in order to allow multiple virtualized OS's to share the IO devices. This causes stuff that is IO intensive (games, compilers, databases, etc.) take a fairly serious performance hit. Interestingly enough, Intel is working on building this sort of capability in the chips directly - check out Vanderpool for instance. I don't know if AMD is doing anything similar, anybody heard anything?
Is lack of demand. Registers aren't relivant. It is a fact of a turing machine that any one can emulate any other. An x86 chip is perfectly capable of emulating a PPC chip. Now it might end up being slow (due to registeres needing to be in memory), but it would work fine. I actually have a feeling you could get it working pretty well. The 32 "general purpose" registers on a PPC actually aren't, many of them have specific tasks, and the number of registers actually on an x86 chip is not related to the number exposed by the ISA.
However, regardless, you can make an emulator. You can make an emulator in 100% C or Perl or Java if you like, and one that is portable to any platform. It needn't be anything low level. It'd be slow, but it'd work just fine.
Basically what it comes down to, is who wants a PPC emulator? I mean if you want a PPC system, get one. There are plenty available from IBM for reasonable prices. If it's Mac emulation you are looking at, well that's a problem. The Mac ROMs are not available outside of Mac hardware, nor is the OS, and without those, it is useless. So to run the emulator, someone would need a legit copy of the ROMs and OS, meaning they'd need to own a Mac. Well if you own the hardware an emulator is worthless.
x86 emulation on the Mac is of much more intrest. First off, it's actually feasable to do. PC BIOS is easy to license from a number of manufacturers, and MS is happy to sell copies of Windows, even for virtual machines. Also there are cases where you have a Mac and 99% of what you do is done natively but there is the ONE app that you need for something that is Windows only. So you get an emulator. Well the only Mac only apps I can think of are things like Final Cut Pro, which would run like shit in an emulator, so you'll have native hardware if you want to use it.
of the silliness/interesting possibilities of layering all these things:
....
Win98 on top of
VMWare on top of
Boch (or some other x86) on top of
OS/X, Linux, FreeBSD of top of
hehe, stupid, but might be fun to try if you got spare cpu power laying around... + plus you get to see what exactly VMware is doing to hardware (by looking a Bochs layer), or swap it around, and see what exactly Win98 is doing. Might be useful to find out all that hidden "functionality" in Windows for something like the Wine project. Just mouthing off here though...
How in the hell is the parent offtopic? /. reported that Darwine is going to use Bochs!
I need a pentium IV to run Commander Keen in dosbox.
Absolutely amazing.
Defenestrate Windows...
Finally, now I can install windows XP on my xbox!
(XP on Bochs on linux on xbox)
> It would be, if darWINE actually used Bochs... It does. Code from Bochs will be used to handle the emulation side of Darwine.
Now that you mention it, http://dosemu.sourceforge.net/stable/announce-1.2. 0.html
is out.
It's the PC Emulator for x86 based Linux.
Plex86 is the VMware alternative.
It is a fact of a turing machine that any one can emulate any other
It is a fact that they can. However that does not mean that it will be easy.
It'd be slow, but it'd work just fine.
This is exactly the problem: it would be slow. And up until a certain point, it's slow enough you might as well not do it at all. No, there's no commercial demand for PPC emulation on x86; there
doesn't really need to be. People write emulators just because they can. Do you think there is any "demand" for an emulator for the Amstrad CPC? In the meantime, there's some hobbyist demand from people who are "curious" about OS X; there's the guarantee of instant infamy for anyone who succeeds. People have really tried, put a lot of effort into trying to, emulate the PPC on an x86. I've never seen anyone succeed. As it turns out, though, writing a PPC emulator that runs on the x86 just happens to be unbelievably difficult to do with anything even remotely approaching an acceptable speed of emulation due to the neatly mismatching design philosophies of the two instruction sets. Yeah, if there was a real commercial *NEED* for someone to emulate, an acceptable emulator could probably be created. But the issue is a little more complicated than "oh, no one wants it".
If it's Mac emulation you are looking at, well that's a problem. The Mac ROMs are not available outside of Mac hardware, nor is the OS, and without those, it is useless. So to run the emulator, someone would need a legit copy of the ROMs and OS, meaning they'd need to own a Mac. Well if you own the hardware an emulator is worthless.
Not only is this not the hard part, this is the part that has already been solved. Modern macintoshes no longer have anything significant in ROM. The ROM is just a tiny kickstart thing and the OS is booted entirely using the openly documented Open Firmware protocol. This part is a non-issue.
Since the internals of an apple machine aren't that public, virtualizing the hardware might be a little bit difficult.. but, well, not that difficult, as practically all of the work has already been done for you in the form of the mac-on-linux project, a VMWare-like virtual machine for macintosh hardware that will let you boot OS X within a virtual machine on top of Linux. I am uncertain how much extra work needs to be done on top of that when emulating on the PC platform since I don't know what the internals of mac-on-linux look like. However, at the very least, the hardest and most voodoo-y part, actually getting it to boot, has already been done.
As far as the OS goes, you can buy a copy of the Mac OS without buying an actual mac. As in, you can go to a store and buy a copy of Mac OS X 10.3 in a box. This is not unrealistic; just because someone is emulating doesn't mean they aren't willing to actually buy the OS. Case in point, everyone who emulates Windows on the Mac does in fact actually have to buy a copy of Windows.
BTW, just out of curiousity, where are these PPC systems which you say are "available from IBM for reasonable prices"? I may just be going about it wrong, but I'm looking at IBM's website and the cheapest POWER-based system I can find is nearly $6000.
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
I have a sugesstion. If you are like me and have migrated from Windows to Linux then you should give Wine a try.. You see, All I found that I really needed were a few key windows apps (Outlook, Photoshop, Illustrator.. etc.) Wine takes a lot of patients and hard work at first to get the apps running correctly (recompiled several times, a learning curve I guess) but, if you persist it works great. Very fast. RARELY crashes the app.(once about every couple of weeks) It's even better than the Crossover office plugins that cost money. I found that I did not need the Windows desktop.. Just the apps. After all.. I'm very happy with the Gnome desktop ;-)
Of course either way it's speculation at this point.
Chu vi parolas Vikipedion?
I actually installed this full-range x86 emulator on Linux and then installed Win95 on it.
Aside from the fact that Win95 does a bazillion low level operations that all have to be emulated, Bochs itself really is _s_l_o_w_.
Other than checking for low level compliance with basic x86 stuff it's completely useless on a productive application usage level.
Then again, I have to say that Win95 actually *did* run. Err, make that crawl.
We suffer more in our imagination than in reality. - Seneca
Surely they could create an archutecture that supports pluggable CPU libraries. Then you could run the full reference software x86 library, or those of us who simply want to run windows on our desktop could use a more sophisticated library. QEMU already has a portable x86 library that supports dynamic translation and is 65 times faster than BOCHS.
I got bochs v2.1 to run Windows XP without any problems. The trick is to configure bochs with --enable-cpu-level=5 --disable-sse.
Here are some screenshots and a howto
anyone heard of fau machine?
www.faumachine.org
It's uselessly, ultra, deadly slow.
- Create a hard disk image:
- Stick in your win98 install CD and go!
/dev/cdrom -hda win98.img -boot d
- At the boot menu select boot to DOS option. Run FDISK and create a primary DOS partition. Exit qemu.
- Start up qemu again, this time go into Windows setup. Should be fairly standard.
- At some point it may give an odd error message or two. For me it complains about being unable to allocate memory for the device manager. A bit later it said it couldn't load explorer.exe and that I'd have to reinstall Windows; just rebooting (exit, restart qemu) got it going again.
- At some point after one of the reboots it'll try to install some networking stuff. For some reason I can't get Win98 to access the CD-ROM, so it can't install this and won't boot up in non-safe mode. You may want to perform this next step earlier:
- Boot off the CD into DOS w/ CD-ROM support. Copy the *.CAB files from d:\win98 into c:\windows\system\precopy. Reboot and if necessary go into safe mode and fiddle with the networking control panel to get it to finish installing things.
- Voila! It sort of works.
Some caveats; I haven't been at it long but here's my problems so far:dd if=/dev/zero of=win98.img bs=1M count=1024
qemu -cdrom
However it gets that far, which is impressive. :) And while the performance isn't super in absolute terms, it runs much faster on an old Pentium II than I ever got Bochs to run on my 2 GHz Athlon. I'm expecting good things in the future...
Chu vi parolas Vikipedion?
Someone with so much time on their hands, and so much technical knowledge sounds like the perfect addition to the Bochs team. In other words, put your code where your mouth is, flamer.
I want to delete my account but Slashdot doesn't allow it.
Simics has powerpc emulation on x86, and IBM has an internal product that does as well. Someone else here writes of a free software project called Sheepshaver that does the same, although I have no experience with it.
As far as your complaint regarding x86 architecture, it is completely bogus. Emulators are inefficient, and unless you have a multitude of registers you can not map registers to emulated registers because you have to run your own code. Memory is a good place for emulated registers to reside, and is likely to be THE place for an emulator, regardless of whether it runs on an IA32, AMD64, or a RISC machine.
DOSBOX has speaker, Adlib, CMS, SB pro 2.0, GUS, MT-32, Disney, and Tandy sound. Considering sound support was the main issue when it came to compatibility for DOS games, I'd say DOSBOX's sound support is its biggest feature.
Here's the new project page...
For those that would die defending it, Freedom
has a sweet taste that the protected will never know.
It's not open source, but the Dolphin Gamecube Emulator can actually emulate a gamecube on the PC, which of course includes its 486Mhz PPC processor. So it's possible, even on 32 bit. I was quite surprised by this. I really hope they will Open source at least their processor emulation.
http://www.dolphin-emu.com/
I just remembered I have a homepage at Cornell (my university network..) that can handle the /. bandwidth demand. Try this link for the
Windows XP under bochs HOWTO & screenshots.
Specifically XP.
Uh, I got windows 98 to work very well under bochs. Its actually quit fast (all things considered) on my 2.4GHz P4. I even have working sound and networking. Dont believe me? See this screenshot that I'm going to take right now...
Why is it that people on slashdot always assume that because you spent ${SHITLOAD OF CASH} on something, that you have a further reserve of ${SHITLOAD OF CASH}? It's probably -likely even- that having paid out the money for those two applications that ${SHIT LOAD OF CASH} has been reduced down to ${Laundry Quarters}.
Unless he works at a corporation; then you have to wonder why he doens't talk his boss into sponsoring Plex86.
http://www.netscape.net/ - free pages that don't have a low bandwidth limit
http://www.1and1.com/ - free hosting account for 3 years. Hard to get set up but works once you get it.
DosBox is, of course, the other option.
Vintage computer games and RPG books available. Email me if you're interested.
[W]riting a PPC emulator that runs on the x86 just happens to be unbelievably difficult to do with anything even remotely approaching an acceptable speed of emulation due to the neatly mismatching design philosophies of the two instruction sets.
Sooo...why does the PPC do a fair job of emulating an x86 then? I have VirtualPC on my 1.25 DP G4; it only uses ~60% [of *one* proc] when it's going full-tilt, yet it feels about as fast as my PIII-800 at my last job. Not screaming bleeding-edge fast, but perfectly usable for 2000/XP. Is it really because the PPC is that much leaner and more efficient a design than the x86, or is there just much less interest in an 'optimized' PPC emulator?
Facts do not cease to exist because they are ignored. - Aldous Huxley
Check out Sheepshaver x86 at http://www.emaculation.com/sheepshaver.php
It only emualtes older pre-G3 PPC however.
Perhaps I should have been more clear. What I mean is that the contrasting design decisions of the PPC and x86 make it very very easy to emulate x86 on PPC and very difficult to go the other way around. Here are the reasons why.
This is a vast oversimplification, but when you are emulating you want two things. First off, you want it to be easy to efficiently rephrase the source instruction set into the target instruction set. Second off, you want to be able to hold all the emulated registers in hardware registers (since machine code is often very carefully optimized such that the registers are being used to their full potential).
The first issue has to do with RISC vs CISC-- Reduced vs Complex instruction set computing, two differing design philosophies. Again I'm probably oversimplifying here, but the latter-- the philosophy x86 follows-- has to do with having a vocabulary of lots of instructions which do complicated things; the former, the philosophy PPC follows, has to do with having a small number of instructions which do simple things. The idea here is that the RISC chip does less work per instruction, but it is hopefully able to execute so many more instructions in the same amount of time that overall it does work faster. Neither x86 nor PPC perfectly follows their philosophies, but for the sake of this argument it comes out about the same.
This makes RISC chips happen to be unnaturally good in the specific case of emulation. Since RISC chips very rarely have instruction sets that that dramatically differ from one another, and since conceptually all CISC instructions can be represented as a series of RISC primitives, all that a RISC chip has to do when emulating another arbitrary instruction set is break the source instructions down into piecies. A CISC set meanwhile has to do a lot of wierd molding in order to remain optimized. (As a random thing to consider, emulators that run on a CISC/x86 machine often must involve assembly to run well; emulators for PPC machines are almost universally written in plain old c.) When you look at the specific case of emulating a RISC machine from a CISC machine, this goes from being a quirky advantage of RISC to a major pain.
Basically, look at it this way: let's say you want to pull two values from memory, add them, and store the result back to memory. A CISC chip might have a single instruction that does this; on RISC, you would issue two load instructions, an add instruction, and a store instruction. If you're emulating CISC from RISC, no problem, you just look up what the loadloadaddstore instruction means and how to break it down into RISC instructions. But if you're emulating RISC from CISC, you have the difficult and expensive task of constantly looking at the incoming stream of instructions and trying to analyze them to figure out how you can reorder them and possibly merge them together into bigger instructions... not something you want to be doing in realtime.
The second issue is the registers, which has already been discussed-- hitting memory is relatively VERY expensive. This isn't so much a problem in normal compiled programs because you can carefully arrange the register usage to be efficient, but with emulation it's a massive pain because you don't have any higher-level information about the program and so have very little basis from which to optimize.
These mismatches between the designs of the two chips just happen to serve to create a case where while both x86 and PPC do many things well, the specific job of emulating PPC is something of a perverse case for x86. This is all I was trying to say.
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
Is this a potential replacement for citrix, at least part of it? Or is it too slow?
Meaning I could throw a window from a unix server running MS access to any unix box or windows box(with the added software).
Or am I missing something.
Bochs 2.0 won't run 32-bit (DPMI) DOS programs. At least, not for me. DJGPP programs, trying to load Borland's DOS extender (32RTM.EXE), or running the DOS version of DOOM (using DOS4/GW) all cause the emulator to crash.
Has this been fixed?
What the fudge are you talking about? There's been an PPC mac emulator out for a while now. It's the x86 Linux port of SheepShaver. It emulates a G3 mac at good speeds on my Athlon XP 2700+ but can only run up to MacOS 8.6.
There are 2 kinds of people in this world: Those who write in decimal and those who don't
BOOYAH FUCKERZ.
Plex86 *used* to be a (future) open-source VMWare alternative. Now, after a long period of basically no development, its goals have been lowered substantially. I think the current plan is to do basically the same things that User Mode Linux already does, just in a slightly different way under the hood so that slightly fewer kernel modifications are required. Plex86 isn't going to be running Windows anytime soon. Disappointing, isn't it.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
Yes, qemu emulates an NE2000 which can connect to the host via the tun interface.
Chu vi parolas Vikipedion?
This is just plain ridiculous. If anything, emulating a PPC on another platform is easier than emulating an x86. Why? Because the x86 instruction set is psychopathic. It's like it was designed by sadists. Ugh.
The PPC instruction set it pretty simple in comparison. It's easy to understand. It's easy to emulate.
Saying it's "hard" because it might be slow is all nice and good, but that's not hard. That's just slow. Actually writing a functional emulator is not (in comparison) hard. It's just kind of unrewarding, with the lack of demand and all.
All this blah blah blah about the register sets is absurd. Here, watch me emulate the PPC register set on a Commodore 64:
long reg[32];
long altivec[32][4];
OMFG! I am teh hax0r god of the universe! *rolls eyes*
Here, watch me emulate the PPC register set on a Commodore 64:
long reg[32];
long altivec[32][4];
OMFG! I am teh hax0r god of the universe! *rolls eyes*
IIRC, "long" is 16 bits on the C64.
No conforming C compiler can implement char, short, or long with less than 8, 16, or 32 bits, respectively. The 6502 was an 8 bit processor anyway, why would they support multiple precision math for 16 but not 32 bits?