Slashdot Mirror
Bochs 2.0 Released
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."
Anyone know the riugh performance tradeoff of say, Photoshop ?
from the link inside the article Welcome to the Bochs IA-32 Emulator Project 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. Bochs can be compiled and used in a variety of modes, some which are still in development. The 'typical' use of bochs is to provide complete x86 PC emulation, including the x86 processor, hardware devices, and memory. This allows you to run OS's and software within the emulator on your workstation, much like you have a machine inside of a machine. For instance, let's say your workstation is a Unix/X11 workstation, but you want to run Win'95 applications. Bochs will allow you to run Win 95 and associated software on your Unix/X11 workstation, displaying a window on your workstation, simulating a monitor on a PC. "
QUOTE
2.0: Speeding towards a Computer Near You
The new, improved, faster Bochs 2.0 is heading your way very soon, , click here for release details and links to release candidates.
END QUOTE
Is it just me, or does this sound like Bochs 2.0 is not released yet... A pre-release (4) is available... but not the final version...
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.
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)...
Last time I looked at their code they had a function call for every single x86 op-code - ouch! Even a switch loop would be preferable.
Is BOCHS smart enough to let the host machine run the non-privledged instructions if the host happens to be an x86 chip?
I have a hard time installing XP on a real machine.
Does anyone one know which one of them is faster, or let's just say better?
keep it simple.
Anyone care to comment on Bochs versus WINE or emus versus VMs?
If you go to the sourceforge download page, located here, it has links to all of the 2.0 final downloads. Have fun killing the servers... I already got my copy. :)
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.
Sig (appended to the end of comments you post, 120 chars)
With Connectix flogging Mac OS X users with promises of "25%" speed improvement (IFF you have a certain level of video card, the most bleeding edge OS update and a level 3 cache) over a universally panned as abysmally, "unusably" slow 5.x, a lot of Mac user eyes are looking to Bochs when they see the $99 "upgrade" pricing for the new 6.0.
1.4.1 did compile after a source fix to CDROM support but I haven't gotten it to do much. Prior versions were very slow. As a VPC (Mac & PC) users I'm eager to try out this latest Bochs.
project website is still showing latest as 1.4. Could it be that slashdot is actually on time/ahead for once!?
I'm curious... For virtual servers along the line of something like VMWare's GSX product, how well does bochs perform compared to these 3 alternatives?
...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.
Ho! Haha! Guard! Turn! Parry! Dodge! Spin! Ha! Thrust!
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.
comment directly in my journal
because the Windows calls are not emulated as in Bochs. Wine is conservatively 1000 times faster than Bochs.
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?
Remember that Microsoft is presently forcing corporations to accept the terms of XP licenses, even if they want to keep running non XP OS's like Win2k or even Windows 98. Since the XP license prohibits the use of Open Source software like BOCHS (or anything GPL'd) on corporate desktops, this cuts off a lot of BOCHS uses for businesses, unless they want to run a bunch of WIndows 95 apps.
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...
It's called a "Grammar Troll". Or as the Spelling Trolls like to call it, a "Grammer Troll". Get with the program!
AFAIK neither Basilisk nor Fusion do a proper job emulating X. Which doesn't leave much in the way of a stable, robust emulation option. Sorry, I know that doesn't really help -- but it might dispell anyone suggesting either of those two.
However, my knowledge emulation enivornments works the other way around (Linux on Mac systems over here).
If I run across anything -- I'll let you know.
-----
(The new and improved alcohol fueld UncleRage)
#SickNotWeak
Thanks! I thought it was quite good myself. I appreciate your support!
Which should I use?
I need to run both Mops and Life.
IN SOVIET RUSSIA, fucking stupid is this joke.
Anyone trying to compare bochs, speedwise, to wine or VMWare, is going to be sorely disappointed..
Of course, there are times when virtualization (VMWare) or O/S emulation (Wine) aren't appropriate. Two big reasons:
#1) Your host system is not an x86: Like you're on a MacPPC, for example.
#2) You are trying to do low-level debugging. (But I don't know how well bochs helps you do this).
If you're just trying to run another x86 operating system or whatnot on your x86, VMWare is a much better choice. (there is also a free project similar to vmware, called plex86, I think).
There have been a lot of coments here asking what Bochs is and how it compares to VMWare.
Bochs emulates *all* hardware components found in a normal x86 PC. Its written in C++ in a portable way.
In english this means it will run on any architecture that has a C++ compiler. Sparc, PowerPC, x86 - under Windows, Linux, MacOS9 and X.
VMWare is very clever because it allows the emulated program to run on the real CPU only interupting it when the program tries to access hardware.
This means that VMWare will always be much much faster than Bochs but it can only ever run on an x86 machine.
Also VMWare is vulnerable to baddly written software that manages to bypass its checks and reach the host machine.
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.
ah HA... hahahhahha
enough said
Bochs is reaching its goal verry quickly. It easily emulates NE2000 NIC hardware and with such a feat we can communicate to software inside of bochs using our own environment. Even better, we can spawn multiple bochs systems and the fenced-in software may communicate to eachother. That great... What I think stinks moreso is the virii that can get inside of the bochs systems and how badly they may wreck the software; not to mention the devestation of a anti-virus scanner inside bochs. Great, more limits to think of. And I was just now hoping Bochs would migrate a little towards the system of the bochs environment to interface to my Linux system's environment so I may have a virtual x86 that is somewhat accelerated. It'll always be just a testbed-type resource; nothing like DosEMU or Wine. Wine should be inter-would with Bochs for those of us not using X86 hardware, but that would be masochist of me
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.
There's 10 types of people in this world, those who understand binary and those who don't.
..a non-x86 architecture supercedes chips like AMD's x86-64. But that's at least 4+ years away IMHO.
Bochs already reached its goal. Alongside other features, it emulates NE2000 NIC hardware and with such a feat we can communicate to IP-enabled software inside of bochs using our own environment. Even better, we can spawn multiple bochs systems and the fenced-in software may communicate to eachother. That great... What I think stinks moreso is the virii that can get inside of the bochs systems and how badly they may wreck the software; not to mention the performance-wise devestation of a anti-virus scanner inside bochs. Great, more limits to think of. And I was just now hoping Bochs would migrate a little towards the system of the bochs environment to interface to my Linux system's environment so I may have a virtual x86 that is somewhat accelerated. It'll always be just a testbed-type resource; nothing like DosEMU or Wine. Wine *could* be inter-would with Bochs for those of us not using X86 hardware. Whas that being too masochist? Yes, No, Ignore?
But I'm sure you already Gnu that.
...is to let developers like the fine folks at ReactOS who would have a terrible time developing it if it weren't for Bochs!
:)
I don't see why everyone is comparing it to wine or vmware because it's simply not the same thing.
By the way... support ReactOS !!
-- Would it be acceptable to just put my name on my sig?
It'd be nice if they'd have updated their webpage to say so.
NO CARRIER
Uh, while emulation would be *handy*, it has no place in the kernel. And it definitely wouldn't "boost acceptance" of Linux on other platforms. Why would you want to run something in emulation, when for the vast majority of Open Source software, all you need is to do a few tweaks to the source and a recompile? And likely someone else has even done THAT for you?
* 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!!
I fought the corporate America, and the corporate America bought the law.
Yes, most Linux software is open source... but there is lots of closed-source Linux programs as well. For instance, many high-end graphics programs, such as Maya and Renderman are available on Linux, but aren't open source.
There's 10 types of people in this world, those who understand binary and those who don't.
Only here such a troll gets modded up to "Interesting".
Bochs/VPC/ZSNES/GnuBoy emulates a machine on any other, so it will run on any architecture from x86(PC) to PPC(macintosh) to ARM(my sharp zaurus) but is slower because it has to recreate all of the target machine's functions.
Wine just emulates winshit's APIs; it will only run on PC computers. It is a hell of a lot faster, but has more errors due to lack of winshit documentation. Most WINE crashes also occur in windows btw.
VMWare/MacOnLinux is a middle-ground between the two. It is a PC emulator, but instead of making the virtual processor out of C it is made out of assembly on the same machine it is emulating. The processor knows every command the virtual one needs, making the processes a lot more efficient.
Other thing such as big endian v. little endian are involved, but the user doesn't need to worry about that.
You can't judge a book by the way it wears its hair.
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)
My Karma isn't excellent, damn it! (And
Just build layer after layer of virtualization like that (Bochs running Windows VMWare in WINE on VirtualPC in a Mac emulator on Linux on VMWare on Bochs etc...) and eventually you'll have enough virtualization that you can pull the original hardware out from under it all, and your "virtual PC" will just run on it's own without hardware. The trick is just getting enough layers of software in their so that they all support eachother's hardware needs.
I know, I'd like that too. :(
Time to buy a mac?
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...
www.plex86.org sends a 404. And plex86's Savannah project page doesn't show much sign of activity. Is it moribund? Dead? How did it compare with vmware at its last sign of life?
My name is Cedric, and I'm a switcher!
:)
Linux (PC) --> OS X
Wahoo!!!!
Does it run Second Reality in Windows 2000/XP? Anyone know of any way to do this yet?
It's the deathmatch of the century!
and a host of other activeX stuff comes bundled with IE and office
plus they usually mae you upgrade IE to run windows update, it requires ie5 atm.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
I was sys admin at a render farm a couple years ago. Maya would have recompiled for any linux architecture if we paid them. We ended up going with x86 because other architectures can't provide the mhz/$$ that x86 does.
I bought an ipaq a couple years back, before moving to linux. And unfourtunatly for me it's wound up forcing me to keep windows around to transfer files to and from it. Anyone know if Bochs running windows would be able to sync with my ipaq?
Everything will be taken away from you.
These guys seem to have a Ultrasparc simulator http://cap.anu.edu.au/cap/projects/sulima/
I though Steve was the evil one? There are more?
Was it as good for Bochs as it was for me?
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).
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.
For those who feel the need to run XP via emulation, I have a simple solution for you: don't do it. You have the software, you must have the hardware, now for the tricky part: insert software into hardware & install. I swear to God, some of you people want to emulate everything.
Not only did you manage to get the incorrect OS (the subject of the conversation was Windows XP) but you also put in an OS that was released 18 months before the OS that everyone else was talking about!
How could you not prove your point that Windows sucks! You should be awarded the "LUNIX MEDAL OF WINDOWS FIGHTING COURAGE ALPHA!" for that piece of FUD.
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...
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.
Let us not forget Plex86, which is a virtualizer like VMWare, but is free.
http://savannah.nongnu.org/projects/plex86/
nothing short of killing Steve Jobs and replacing him with a clone (evil clone, of course) is going to get you OS X on a PC.
I think that must be a typo; the Steve Jobs who took millions from Bill gates, killed the Mac clones, and buried their x86 efforts is already the evil clone.
Comment removed based on user account deletion
Comment removed based on user account deletion
This comment is rated SUPER A-OK!
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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.
In short, programs like VMware are so much more complicated than CPU emulators like Bochs that it is nearly impossible to make anything work without testing. Since VMware is closed source, it is unlikely that it will be tested much on unsupported guest OSes, because that will not generate much profit. If you want to run Windows, Linux, or BSD, or Netware on it, fine. If you want to test your toy os, Bochs-like things (or better, another computer) is much better.
www.transitive.com --just in case Motorola goes the way of Enron and IBM won't play ball, they can start shipping 3GHz Pentium IVs until they recompile the non-Darwin parts of the system.
Also, System 7 supported a built-in 68K emulator, all right, but it was only transparent to the end-user. It was an "in your face" experience (now known as Carbon) for all Mac software developers. Eventually, Carbon (and its horrific inefficiencies) will die for all those except REALbasic programmers. If someone creates a QT-based version of BASIC (for Darwin/Cocoa), we might just see Carbon die completely.
Anyway, I don't get what cool possibilities for a PhD you are seeing there, since a dissertation is supposed to be new research, not reimplementation of existing technology.
What is keygen?
I though bochs development was dead, but I'm glad to hear that's false. I hope it will rub off on plex86, which is the only real hope for the "best of both world" strategy (win,lin on a box).
However good news!
Booting from Floppy... /. lame junk char filter
[snip cos of
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
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
When i want to install OS/2, BeOS it will not happen.
Isn't it nicer to get those OS-es working under say Linux or FreeBSD, VMware won't install them (deal with MS maybe ??)
IN SOVIET RUSSIA these jokes are made about you!
Let me illuminate the joys of installing Redhat Linux 7.3 (the last distro I installed):
Boot of of CD-Rom
Read several F(number) pages of information and decide which boot option is right for me ~ 5 min
Curse at a system that does not let my set my keyboard mapping to dvorak before forcing me to enter textual data ~ frustration +1
Wait for anaconda et all to load ~ 2 min
Select my keyboard mapping and mouse type (*)
Get to the partition screen and find out that the installer doesn't dynamically resize windows partitions to make room for itself. ~ frustration +2
Reboot
Warez partition magic
Use partition magic ~ 30 min
Reboot
Repeat above steps until the partition screen comes up.
Set up mount points and a swap partition because the system won't configure available space in a sane way automatically ~ frustration +3
Fsck & mkfs ~ 2 min
Choose 'custom' from the workstation/server/custom menu, and select package groups that I think I'll need.
Select "choose individual packages".
Realize that package management systems under linux don't descriminate between packages that users may or may not want to include (konqueror) and packages that are mandatory and must always be installed without bothering the user and making him/her read up on them (glibc) and should only be exposed as options when the user selects "ultra-expert" install mode ~ frustration +4, 5 min (to find the things I need [luckily I know what they are] )
Realize that standard desktop OS functionality requires a default install greater than 1 GB ~ 2 seconds, frustration +5
Wait for packages to install ~ 55 min
Install grub
Reboot
Enter install program because I didn't remove the CD and the CD boot loader isn't smart enough to present me with a "Press any key to boot from CD...." timeout option which boots from the hard disk if the OS is already installed ~ frustration +5
Remove CD
Reboot
Realize that even though linux has reached version 2.4 and redhat's distro has been around for so many years, no one has ever considered that long, fast-scrolling startup text barfed out by the kernel scares away users who "can't read the error messages fast enough to keep up" and instead replaced them with a progress bar by default, while still making advanced startup an option ~ frustration +6
Realize something similar while watching the init scripts ~ frustration +7
Appreciate that X just works and that I can log in graphically and that I don't have to configure anything in order to get to that point ~ frustration +6
Remember that windows has been this way for a very long time ~ frustration +7
Log in
Click the little red exclamation point, and read an error message that says I have to be registered in order to get automatic security updates ~ frustration +8
Remember that not even windows is that persnickety about giving out security patches ~ frustration +9
Remember that windows requires you to accept an agreement giving MS total access to your computer in order to patch critical security flaws ~ frustration +8
Register for rhn ~ 10 min
Change home page from redhat to my usual home page.
Be thankful that multiple reboots aren't necessary while downloading software updates ~ frustration +7, 2 hours
Download openoffice because it's been neglected in favor of inferior, splintered, buggy, incompatible individual office programs which were installed even thought I didn't want them.
Be forced to open a console, untar, find the setup file, and run it in order to install an office program because there is still no single, unified package management system for linux which results in confused users and puts extra strain on developers who package their own software by forcing them to either neglect certain distros, learn and use all of the major packaging systems, or write their own setup programs ~ frustration +8
Make an educated guess that even if package management system developers could put aside their egos, develop a decent universal package system, and get every distro to use it that it would still force me to use the console ~ frustration +9
Try to launch openoffice and find out that it crashes ~frustration +10
Read man pages, docs, visit IRC help chat, etc... ~ 2 hours, frustration +11
Give up for now, get a snack ~ 10 min, frustration +10
Realize the reason why the interface feels so uncomfortable: my wheel mouse doesn't work ~ frustration +11
Read up on XF86Config, hit IRC again, man pages, man pages, man pages galore ~ 30 min, frustration +12
Figure out how to turn on mouse wheel suuport ~ frustration +11
Be forced to edit a text config file in order to get a very basic feature to work that would be easy to autodetect and autoconfigure in the install program ~ frustration +12
Go through an incredibly long series of steps that I won't list here with lots of downloading, compiling (!), manual reading, IRCing, etc... to get 3D acceleration to work ~ 7 hours, frustration +15
Reinstall windows 2000 professional (it's a dual boot system), (it needed to be done anyway) ~ a whole lot less time, very little trouble.
Click "I Agree" for the first time after turning 18 ~ 1 second, freedom -<rotate clockwise="90 degrees">8</rotate>
Realize that gnu/linux will never take off as a mainstream desktop OS as long as it is hard to install, presents scary "informative" messages, forces the user to learn the console, has a default install that's more bloated than windows (yeah, really), and so on..., and that as long as windows remains the desktop OS of choice everyone loses, including gnu/linux users ~ frustration +<rotate clockwise="90 degrees">8</rotate>
Post on slashdot about my experience ~ -3 karma (I post at +2, slashbots who don't like to hear jaded but honest criticism of OSS can get it down to -1)
Sigh in despair ~ no net change
Let's just hope that some enterprising Russian hackers can write TCPA/Palladium emulation for bochs.
Right now it looks like Bocks decodes each opcode in the programs that it is running as it goes, each time... Essentially you are breaking the code apart into series of new opcodes that run on the native hardware.
Now... imagine if you will that as you decode the opcodes you store the new code that you generated and execute that instead. So that you only have to decode the software once. If you stored the new code to the file system you would basically have a form of a cross compiler that could make code written for one hardware platform be transferred to another platform.
This is basically how the AS400 series of mainframes works. The underlying hardware, including the CPU is completely transparent to the running programs. If you change processors the software is all recompiled on the fly as needed.
It would be interesting to actually have a VM layer like this on the computer at the lowest level to "virtualize the hardware" and then be able to run Linux compiled for an Alpha, Windows for an x86 and Mac for the powerpc simulateously and at near platform speeds.
A quad AMD sledgehammer clocked out to 3 GHz would definately have the raw speed to a VM platform like this easily and is coming in the next couple of years. There may even be extensions added to processors to make things like this easier if we can explore it with an open source project like this.
Ralf is your friend. My guess is this is what you're looking for. BASIC ROM? Yikes. Good luck on that one :)
Anyone knows what happened to plex86? other than being a dead project..I mean :(. Something like where is the source code!!
could be as a DOS-emulator so that we could still play all the old games.
Is it possible, and has anyone tried it?
I wonder how well BOCHS would run a Transmeta Crusoe. Or would that just cause an irony cascade resulting in a spatial singulatrity?
"Bishops and Bookies live off the irrational hopes of mankind." Bertrand Russell
Lucent even now provides a pre-packaged VMWare image
:
s se d/$CODE/vmware.zip
l
You have to click a EULA to get this link but it exists
http://plan9.bell-labs.com/magic/9down4e/compre
start here - http://plan9.bell-labs.com/plan9dist/download.htm
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Comment removed based on user account deletion
Cygwin inside Wine
"I assumed blithely that there were no elves out there in the darkness"
Anyway, I don't get what cool possibilities for a PhD you are seeing there, since a dissertation is supposed to be new research, not reimplementation of existing technology.
I wasn't aware that anyone had implemented a really good cross-compiling optimizing emulator, which would have made such a thing a viable research topic. My mistake. Expressing it in terms of PhDs was an attempt at pointing out exactly how much work is involved in developing such a thing, to forestall "can we tweak bochs to do this?" comments.
Comment removed based on user account deletion
Comment removed based on user account deletion
but what do i know, i'm just a model.
Hmm... maybe you'll understand my comment if you read it another time. But _before_ you do so you should make sure you understand the difference between a mere CPU and an entire box, complete with chipset, BIOS, gfx board, sfx board and all the other parts. BOCHS is a virtual box, and it does _not ever_ translate the binary code into native instructions. It takes this code as it is and executes it on a CPU that is completely emulated, including the registers, flags, busses and caches. This is a virtual machine, and this is _slow_.
:-) And this code morphing, or "converting chunks of machine code" (which you mistakenly called asm), is not really a clever plan; think of how hard it would be to morph code from an entirely different architecture that, for example, has much smaller caches, but much wider busses; a much smaller instruction set, but also much less general purpose registers; you get the idea. Of course it is perfectly possible to do such a thing, but it is not possible to do it both efficiently and automatically. The PS2 runs at 250MHz, but if you want an emulator on a consumer desktop PC, it takes at least a 250MHz CPU to emulate the PlayStation ONE.
Morphing the code so it runs natevily on the physical CPU you actually have is a different thing, which you can easily understand by considering that a virtual machine does not equal a real one
So, while you could morph some native code into slightly more efficient native code (by using new features like SIMD) _on the SAME platform_, you cannot emulate the _whole box_ and still be more efficient, see?
but what do i know, i'm just a model.
Competitive fury is not always anger. It is the true missionary's courage
and zeal in facing the possibility that one's best may not be enough.
-- Gene Scott
- this post brought to you by the Automated Last Post Generator...
If Mr. AC doesn't respond to this post, he fail it. He fail it.
Sex - Find It