Java-Based x86 Emulator

jaavaaguru writes "Researchers at Oxford University have produced a Java-based x86 emulator that they hope will be useful in testing applications and learning about viruses without damaging the host, utilizing the robust sandboxing that Java provides. They have an online demo available that boots DOS and has some games to play. Being purely Java, this emulator should be able to run on almost anything, including cell phones." The code is not yet available outside the Oxford community; the developers are said to be working on a suitable general license. In the meantime the code can be licensed on a case-by-case basis.

Comments

Interesting, but

[dreamchaser]

I can only imagine that this will make even Bochs look fast in comparison!

Still, I'd love to tinker with this from a 'gee whiz' standpoint.

Re:Interesting, but

[Qwertie]

I'd have to agree. Using instruction-by-instruction emulation, a C++ based SNES emulator I wrote around 1998 used at least 150Mhz of processing power to emulate the SNES' 3Mhz processor. When I rewrote it in assembly, it was 5-10 times faster. I expect that some pretty sophisticated techniques would be required to exceed a snail's pace when using Java for emulation, eg "dynamic recompilation": translating sections of x86 machine language to Java bytecode... but getting this to work 100% correctly would be pretty tricky.

If it's hard to get good emulation speed in C++, it's even harder in Java.

Re:Interesting, but

[saboola]

If I might ask, what emulator was it? I have been an emulator nut for a little over a decade and would love to know if I used yours.

Re:Interesting, but

[chorltonian]

Errm... how about trying it out before judging it? As has been covered god knows how many times before, Java is capable of runtime optimisations not possible with statically compiled languages like C++.

Re:Interesting, but

[Victor Antolini]

A little bit of searching brought this

Btw, here's a Gameboy emulator written in Visual Basic!
It's quite fast... puzzling.

Re:Interesting, but

[void_bips(brain)]

If it's hard to get good emulation speed in C++, it's even harder in Java.
No more.
You got to see (search) comparisons where Java beats C++ in speed.
Mostly because of JIT producing native code.

Re:Interesting, but

[shaitand]

'Java is capable of runtime optimisations not possible with statically compiled languages like C++.'

And with them it can perform almost as fast as C in some fringe cases.

Re:Interesting, but

[Citizen of Earth]

Java is capable of runtime optimisations not possible with statically compiled languages like C++.

There is a world of difference between "theoretically capable" and "reliable does". Is there some practical demonstration that compute-intensive tasks like emulation can be reliably executed with Java without sucking?

Re:Interesting, but

[Wesley Felter]

Sure, an x86 interpreter written in Java is going to be pretty slow, but a JIT written in Java beats a C interpreter (bochs) any day.

Re:Interesting, but

[Anonymous Coward]

"Dynamic Recompilation" is exactly what this emulator does, which is the reason it's novel.

The X86 machine code is translated directly into java bytecode, which is then compiled to the target architecture and cached by the JVM.

Re:Interesting, but

[Anonymous Coward]

Don't you know, around here:

• All Java is slow
• All Perl is unreadable
• All PHP is insecure
• All JavaScript is a useless intrusion into your browser

... and all comments like those are written by "experts" who've never written one line in the language in question.

Re:Interesting, but

[MobyTurbo]

Errm... how about trying it out before judging it? As has been covered god knows how many times before, Java is capable of runtime optimisations not possible with statically compiled languages like C++. Maybe so, but it is running much slower than DOSEMU or DOSBOX does in Linux here, which are probably written in C or C++, with possibly some assembly; and can do emulation of all the games it emulates. Java is indeed capable of certain optimizations that are not done in a non-JIT compiler, but that simply is because it needs them. Anyone who tells you that Java operating system emulators typically run faster than C operating system emulators has been smoking SUNW crack. That having been said, there are reasons for choosing Java over C. One of them is built-in security sandboxing, which was obviously the reason for the choice.

Re:Interesting, but

[mrmeval]

Why Java? Qemu works as does VMWare and others....

Re:Interesting, but

[tomhudson]

Errm... how about trying it out before judging it?

errm ... how about because the applet failed to load?

If you go to the site, you'll see their premise is stupid - that game companies will license this to sell old dos games on cell phones, rather than porting them. Of course what they overloook is once you have the emulator, you don't need the game companies - just go through any abandonware site, or your stacks of old floppies.

Re:Interesting, but

[ConceptJunkie]

Ridiculous! Java can perform NOPs as fast as any compiled language.

Re:Interesting, but

[mgiuca]

"dynamic recompilation": translating sections of x86 machine language to Java bytecode...

Which then gets dynamically recompiled by the Java VM into x86 machine language :)

(At least, when running on an actual x86).

Seriously though, this is quite impressive (to have it written in Java). But what are the advantages of this versus QEMU? (Besides a wider range of platforms). I mean... QEMU already offers total sandboxing doesn't it?

Re:Interesting, but

[mcrbids]

Maybe so, but it is running much slower than DOSEMU or DOSBOX does in Linux here, which are probably written in C or C++, with possibly some assembly;

DOSEMU and DOSBOX both are not hardware emulators - they are a reverse-engineering of software that runs on otherwise identical hardware. They are, therefore, unsuitable for comparison.

Since Java run as bytecode on any number of H/W platforms, this is more like SoftPC on a Mac 68k - software truly emulating hardware. (Yes, you could run this X86 emulator on x86 - but it would also run on Sparc with comparable speed)

Re:Interesting, but

[RzUpAnmsCwrds]

All Java is slow

Compared to C++, yes, it typically is. But it's usually within 20-30%, sometimes a bit worse, sometiems a bit better. In some rare cases, Java can even beat machine-code compiled languages.

All Perl is unreadable

Absolutely not. But Perl culture encourages the kind of programming which leads to unreadable code. And Perl syntax certainly doesn't help either.

I would much, much rather work on Java code that someone else wrote. It's not that you can't write horrible Java code, it's just that the language syntax and culture discourages it.

All PHP is insecure

Certainly not, but as someone who works with PHP code on a daily basis, I think it's fair to say that most PHP code is insecure. Even well-recognized projects like PHPbb frequently experience breaches because of SQL injection or some other stupid vulnerability that shouldn't exist in a decent language.

Part of it is the language, part of it is the culture. PHP is an absolutely wonderful language in many ways - it's easy to pick up, easy to set up, and remarkably fast for what it is. But it's not J2EE.

All JavaScript is a useless intrusion into your browser

You have this point. JavaScript (and Flash) are far too often the targets of scorn. You don't blame C++/C/Assembly for allowing a virus creator to write a virus - why should you blame JavaScript for allowing marketers to make more annoying ads?

Re:Interesting, but

[Anonymous Coward]

DOSBOX runs fine on my PowerMac G4, which is hardly a x86-based PeeCee. Your point being?

Glass

Re:Interesting, but

[shutdown -p now]

Much faster, actually, thanks to its opportunity to perform runtime optimizations. Why, I've even heard rumours that it can extremely effeciently parallelize particularly long NOP loops!

Re:Interesting, but

[Anonymous Coward]

You forgot:

• All Your Base Are Belongs To Us.

Re:Interesting, but

[LBt1st]

Tell that to Nintendo.

Re:Interesting, but

[Anonymous Coward]

I know we're off-topic, a discussion of the relative performance of C, C++, Java and .NET can be saved for another time but I want to comment on your statements regarding PHP and JS.

> because of SQL injection or some other stupid vulnerability that shouldn't exist
> in a decent language.

That's short sighted, my first PHP library back in 2001 when I picked up the language was to prevent SQL injection. Neither have I had a problem with register globals because I always initialized global scope vars before use.

> Part of it is the language, part of it is the culture.

I disagree it's the language, I also disagree that being a bad coder and an idiot is culture.

> You have this point. JavaScript (and Flash) are far too often the targets of scorn.
> You don't blame C++/C/Assembly for allowing a virus creator to write a virus - why
> should you blame JavaScript for allowing marketers to make more annoying ads?

Because javascript should be optional yet many sites require it, using it as a delivery mechanism for obnoxious ads. There's also no way to audit javascript before it runs, visiting a web page with js enabled is like running arbitrary code (Argue about sandboxing all you like, the security stats speak for themselves). Imagine being forced to execute a binary from every web page and every advertisers iframe, would we start complaining about compiled languages then?

Hint: When we complain about javascript, we're not complaining about the language itself.

Re:Interesting, but

[TheRaven64]

The target market (from the web site) is game publishers wanting to sell old DOS games on a mobile phone. J2ME is the easiest thing to have working across multiple families of mobile phone (it may not be quite write once, run anywhere, but the per-platform tweaks are fairly small compared to using the platform's native SDK).

For games (or, indeed, any DOS programs), I would suggest DOSBox, rather than QEMU, since DOSBox implements the DOS system calls itself, rather than forcing you to run emulated DOS under your emulated apps. I wouldn't like to be the one to try to port DOSBox to ARM though (although it does run happily on PowerPC, so it wouldn't be too hard...)

Re:Interesting, but

[mgiuca]

This is true (I read this on the website after posting).

Also, as demonstrated on the website, being able to run it as a browser applet is quite awesome.

Re:Interesting, but

[pruss]

They say the emulated system runs at 10% of the CPU speed of the emulating system. That's not bad at all. With a 1 ghz system, one gets a 100 mhz DOS system, which is more than enough!

Re:Interesting, but

[Anonymous Coward]

DOSEMU and DOSBOX both are not hardware emulators - they are a reverse-engineering of software that runs on otherwise identical hardware. They are, therefore, unsuitable for comparison.

You are wrong.

DOSEMU does only work on x86 and x86_64 platforms, but it nonetheless uses hardware emulation, not virtualisation, to run 16-bit programs. DOSBOX is a pure emulator, though it does make use of certain optimisations to speed up said emulation when running on an x86 host.

Re:Interesting, but

[Haeleth]

how about because the applet failed to load?

Worked fine for me. It's slightly slow, and I couldn't get it to register the "alt" key, but those are issues that could easily be fixed by tuning it to run on a specific platform.

Of course what they overloook is once you have the emulator, you don't need the game companies - just go through any abandonware site,

Um, if someone is selling the game, it isn't abandonware.

Besides, abandonware is illegal. Many people consider it ethically justifiable, on the grounds that they'd pay for the software if anyone was willing to sell it to them. But that argument kind of falls rather flat the moment there is someone willing to sell it to you, doesn't it?

or your stacks of old floppies.

For those who have the old floppies, yes - but many won't have kept them, or will find that they're dead, or simply won't have any hardware that can read them any more - particularly if they bought the 5 1/4" versions.

And, frankly, given a choice between paying something like $5.99 for a game, or getting it "free" by wasting three hours rummaging through old floppies or trawling through dodgy warez sites, I think I'll pay. My time is worth more than two dollars an hour, thank you very much.

Re:Interesting, but

[Haeleth]

Why Java? Qemu works as does VMWare and others....

On your phone?

Re:Interesting, but

[tomhudson]

Cartridge-based games aren't the same as ones distributed on floppies (though you can find the ROMs online for most of them - just google for MAME ROM).

Re:Interesting, but

[iampiti]

Dosemu is virtualized and requires an x86 processor to work, dosbox does not. Dosbox actually emulates the hardware and has been compiled on a variety of platforms many not using x86 processors. It has a dynamic recompiler that makes things faster if the host processor is a x86 but on other architectures still works, just more slowly.

Re:Interesting, but

[tomhudson]

"but those are issues that could easily be fixed by tuning it to run on a specific platform."

Oh yes, java's "write once, run everywhere" ... still doesn't work. Java really needs to be redone from scratch.

There were a lot of games that were put out as shareware or demoware that are still available. Also, I have 5-1/4 and 3-1/2 floppies that are still readable just fine - I keep an old pentium floating around just in case ...

Re:Interesting, but

[Anonymous Coward]

Well, my argument is I wouldn't buy it even if someone IS selling it. If I can find it, great. If I can't find it, oh well.

Either case I'm not paying for it.

Re:Interesting, but

[The Spoonman]

We don't need to have written a line of Java to know the applications that were written in that abomination of a language are SLOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO OOOOOOOOOOOOOOOOOOOOOOOOOOOOOW.

Re:Interesting, but

[cryptoluddite]

All Java is slow Compared to C++, yes, it typically is. But it's usually within 20-30%, sometimes a bit worse, sometiems a bit better. In some rare cases, Java can even beat machine-code compiled languages. Actually currently pretty much all Java programs are faster than equivalent C++ ones. Add array bounds checks on all access, use use only references instead of pointers, and don't allow objects to be used after their memory is free'd and your C++ program will grind to a halt.

The only time a Java program ever crashes is due to a bug in the JVM. The only time it ever introduces a security bug is when the application's logic is wrong (ie only high-level defects not buffer overflows and stacks).

A C++ program that is uncrashable and secure will be much slower than the Java equivalent.

Re:Interesting, but

[LBt1st]

My point was, you can easily get old games. Yet Nintendo's making a killing on Wii's Virtual Console.

Re:Interesting, but

[tomhudson]

Of course they are - and I'll be one of their customers, if I ever get around to buying a Wii (which I probably will - it'll be my first console since the SNES, and I think it would be fun to have for when friends visit). However, running a java dos emulator on a mobile phone won't cut it - the screen resolution is wrong, the input devices just aren't there (keyboard, mouse and joystick can't be replaced by a N-S-E-W clicker and a number pad), and if its slow on a 3ghz pc with 2 gig of ram, imagine how slow it'll be on a mobile phone running less than 1/10 the speed, and less than 1/100 the ram?

Re:Interesting, but

[Anonymous Coward]

What do you mean the source code isn't avaliable?

It is if you typed jad -p

Now we can play ~14 year old video games like doom in a web browser at two frames per second.

Re:Interesting, but

[heinousjay]

Awesome, you've successfully combined unnecessary anger, anecdotal evidence, the arrogant assumption that only your opinion matters, a Slashdot meme, and a bunch of insults into one post. I think you get some kind of award for that.

Re:Interesting, but

[that this is not und]

Be careful. They'll all put on their Java rings and pummel you.

Re:Interesting, but

[that this is not und]

Nintendo is in trouble if the ability to play older-generation Nintendo games on Wii is a big part of their 'making a killing' on the Wii platform. People don't look backwards in anywhere near the volume that people look forwards when choosing a Game console. Lots of people already have the old hardware.

Re:Interesting, but

[complete loony]

See Jake 2 for an example. Yes, Java can attain speeds similar to C. But you have to think like a C programmer, being very careful about memory allocation and object life cycles.

Re:Interesting, but

[LarsWestergren]

Yes. At last year's JavaOne Matt Howitt demoed a Playstation 1 emulator written in Java. He ran three or four different games simultaniously without any performance problems, and went through some of the code. And this was with software rendering only, no OpenGL layer. He said he would open source it, but unfortunately no code has appeared yet.

So running a little x86 emulator should be no problem...

Re:Interesting, but

[Vintermann]

True. It would be very interesting if anyone had time to take the Shootout C programs, run them though ccured and compare the results. My guess is that we'd see performance in line with the other type-safe, low-level compiled languages (e.g Ada and Eiffel)

Re:Interesting, but

[FunkyELF]

Wow, so you're saying if you think about your code and write it decent it will perform decent?

I thought you were supposed to get that for free.</sarcasm>

Re:Interesting, but

[TopSpin]

Java is capable of runtime optimisations (sic) not possible with statically compiled languages like C++

Java VMs can't optimize away the cost of reference counting a garbage collected heap. The inability of Java to allocate objects on the stack (and avoid other costs) for short lived objects is also painful. The need to optimize GC performance leads to a large working set, which limits scalability (20MB hello world, etc.) The real world also tends to find ways of suffering poor startup performance, because a surprising amount of software does not actually work well from within a J2EE container.

Java isn't as efficient as C or C++. That's the cold, hard truth. I wish it were. I really, really do. It just isn't, and I won't play to its weakness. Instead, I play to its strengths, like this:

Java provides a Sandbox. That's one of the features Oxford is leveraging for its x86 emulator. Yes, you really can safely run and x86 emulator as an applet inside a browser. DOS inside a browser.

Java is portable. As of now, anything with a sufficient JVM can emulate x86. You can just take that for granted.

See? Far more pleasant. Ignore the trolls, use the right tool for the job, and enjoy low blood pressure.

Re:Interesting, but

[Lally Singh]

Well, there's Just In Time compilation, which is part of the JRE we all use today. It runs a lightweight profiler and compiles the most-used section ("hotspots") to native machine code.

Re:Interesting, but

[Doctor Memory]

compute-intensive tasks like emulation can be reliably executed with Java without sucking? Actually, I would think Java would do pretty well at this. Figure the bulk of the emulator is going to be decoding and executing instructions, and the most commonly-executed instructions are going to be executed millions of times, so the hotspot compiler will tag those code paths and optimize them early on. Plus, memory is probably going to be implemented as a huge linear array, allocated at startup, so there's not going to be a lot of object allocation/freeing, so the GC probably won't be a factor. I/O will probably be a bottleneck, but that's true with any emulator.

If the implementors are at all clever, there really shouldn't be too much performance loss.

Re:Interesting, but

[ConceptJunkie]

Technology rocks! We can do nothing so much faster and more efficiently.

On a phone?

[pap3rw8]

Wow, x86 on my phone? Finally I can run linux on it! Probably dead slow though. Still cool.

Re:On a phone?

[Xymor]

They claim 10% native speed, which is somewhat fast in terms of emulation.

Re:On a phone?

[bWareiWare.co.uk]

And I claim to be God!

I get a 1Mhz 8086 on a AMD64 X2 4400+.

Struggling to understand...

[Anonymous Coward]

...why. With several high-quality emulators already in existence, why is this interesting?

Re:Struggling to understand...

[dreamchaser]

It is interesting from the standpoint that the emulator itself *should* be fully portable to any platform that runs java. It's probably not useful commercially but from a geek standpoint it could be cool.

Re:Struggling to understand...

[Anonymous Coward]

It won't be as big of an issue in the future. The hardware will be good enough that one day Java emulation will be as fast as running native code is today, and of course native code (direct translation) will probly be faster too.

Re:Struggling to understand...

[alexj33]

Java without emulation has been promising stuff like this for a long time and hasn't arrived. How long do you thing it'll be before Java+emulation does?

Re:Struggling to understand...

[Anonymous Coward]

It is interesting from the standpoint that the emulator itself *should* be fully portable to any platform that runs java.
Oh, so I can emulate an x86 on an x86, then? And on, er,... don't tell me... there is another one, isn't there...?

Re:Struggling to understand...

[7ex]

Because it's new!

Re:Struggling to understand...

[Anonymous Coward]

Both have arrived, that's not the problem. The problem is that now that we can run a 1995 application as fast as it was running in 1995, no one is interested in running those applications anymore.

Re:Struggling to understand...

[Anonymous Coward]

I heard there are some guys who put incompatible processors on embedded targets for historical reasons, and these are what still keeps the ARM division of Intel and a couple of struggling smaller manufacturers going. But I'm sure the dinosaurs responsible for such weird decisions will die off any day now and the embedded industry will move on to modern stuff like Core Duo 2.

So...

[mriya3]

... now we should say: "x86 assembler: write once, run everywhere (slow as molasses in January)" ?

Re:So...

[alexj33]

Not quite. Try:

Person #1: "I have a Java x86 emulator for platform A!"

Person #2: "Dang! We wrote our product on a Java x86 emulator for platforms B and C! Welp, guess we'll have to rewrite that puppy so that its java A, B and C compliant.."

Person #1: "Ah, but mine is Java x86 emulator A enhanced, enterprise edition: "JAEE". Meaning anything that works with it should work with B and C."

Person #2: "But isn't that the slowest of all Java x86 emulators? Also, The Java x86 B and C I was referring to were the Special Editions- you know, the ones that had memory leaks. We had to add a lot of code to compensate, which isn't really friendly to any form of A- even your JAEE."

Person #1: "Dang!"

You see where this is going....

Re:So...

[eclectro]

... now we should say: "x86 assembler: write once, run everywhere (slow as molasses in January)" ?

You know what would really be kewl? If you could make an integrated circuit that runs java real fast then you would have a chip that runs x86 assembly.

Re:So...

[shaitand]

'You know what would really be kewl? If you could make an integrated circuit that runs java real fast then you would have a chip that runs x86 assembly.'

Why wouldn't you just grab a Pentium 266 and have a chip that runs x86 assembly at twice the speed this thing will on my dual core athlon?

Re:So...

[Anonymous Coward]

Whoosh!

Re:So...

[Anonymous Coward]

ARM Jazelle chips run ~95% of java bytecode natively (the other 5% aren't practical to do natively). And yes, Linux runs quite well on ARM.

How's the efficiency?

[lbft]

Whilst this looks like a really interesting project, I'm failing to see how it's useful generally due to the limitations of writing it in Java and making it cross-platform. You would lose a lot of those possible (processor- or platform-specific) optimisations that make the leaders in the virtualisation market as fast as they are.

On, say, a mobile phone (which is mentioned by the site as a possible use) would there be enough processing grunt to do anything useful? I know Java's not as slow as some people would have you believe, but virtualisation requires as much speed to be squeezed out as possible to be usable.

On a desktop, what advantage does this have over the existing virtualisation options which don't have to deal with the Java environment?

Re:How's the efficiency?

[Anonymous Coward]

two words: minesweeper

Re:How's the efficiency?

[sumdumass]

I don't think this is meant for a general purpose vitalization application. This is more or less a research on what something does project. More specifically, You can take a virus and run in it a way to compromise the virtual machine without compromising the machine itself. This means your output is not likely to be damaged in any ways as well as you can monitor the activity from a removed setting while maintaining a presence.

And this wouldn't be just limited to a virus program either. Suppose we had this around when sony distributed their root kit. The root kit would have likely been found faster seeing how it hides in the OS but not outside the sandbox. Also, take something like WGA. What exactly does it do? Well, we have found more and more about it as time goes on but we never had the ability to discover it all at once.

But wait, it gets better. Suppose I have a program and are all the sudden getting calls that it doesn't work after update# 2 from some other company pertaining to some other product. I could use this virtual machine to watch how the interactions between my program and this other program or see were the files were changed easily and make adjustments accordingly. This would be exceptionally usefully if some other program is a competing business who wants to blame everything on your bad programing.

Now some of this can be addressed by existing virtualization and processes already available. But the sand box functioning available with Java makes it less likely the problem can spread somewhere else un noticed.

Re:How's the efficiency?

[slamb]

More specifically, You can take a virus and run in it a way to compromise the virtual machine without compromising the machine itself. This means your output is not likely to be damaged in any ways as well as you can monitor the activity from a removed setting while maintaining a presence.

Well, that's great, but you can already do that with VMware, Parallels, QEMU, or other virtualization tools. Sure, virtualization requires the same host and guest architecture, but we all have plenty of x86 machines sitting around, and near-native speeds are necessary to actually boot Windows Vista before the sun goes supernova. So while this is neat software, it's not as suitable for malware researchers as what they are already using. The JPC project needs to find a different niche.

Re:How's the efficiency?

[Gromius]

Actually I think it is for general purpose code. In fact I think its main purpose is for running general code on the grid and giving each process its own virtual sandbox, isolating it from the underlining hardware. This means that some random grid user wont be able to hose the machine they happen to be using which should make things easier from a grid admins point of view. Its the only reason I can possibly think of why they made it.

Incidently when I first heard about this today, I thought it would be the comp sci dept but it turns out its particle physics, which surprised me as I'm a member of the oxford group but on a different experiment. I am still reasonably baffled why they have done this, will have to ask them on monday. This probably explains the current sad state of the ATLAS software as they are all too busy getting Commander Keen to run on their mobile phones :)

Re:How's the efficiency?

[shaitand]

'and near-native speeds are necessary to actually boot Windows Vista before the sun goes supernova'

near-native? You'd better not only have a native system but a rather fast one to boot Vista in a timely manner. But its all worth it, because you can windows+tab and see a cool 3d cascade of windows. I don't even mind so much that they arbitrarily rearranged all the menus and control panel functions (without adding anything of use) for no apparent reason. All is good just so long as I can see window contents moving when I windows+tab. Clearly this was worth waiting 5 years for even if this is the first time since XP SP1 I have seen good old system freezes return. There is nothing like closing all the applications on your system and then walking away to get a drink and coming back to have your system freeze. This has become a great routine, I have even rearranged things a bit so that I can unplug the cable rather than having to hold down the button for 5 seconds.

Re:How's the efficiency?

[poopdeville]

I run OS X and Linux, and even I found your troll boring.

NEXT!

Re:How's the efficiency?

[kestasjk]

near-native speeds are necessary to actually boot Windows Vista before the sun goes supernova.

The sun isn't close to large enough to end in a supernova; it'll be a red giant, then end as a white dwarf.

Re:How's the efficiency?

[suckmysav]

Yes? And? I'm stll waiting for the second word I was promised . . .

Re:How's the efficiency?

[slamb]

Thanks for the correction - an unthinking attempt at hyperbole on my part.

I'll try again - by the time you boot Vista under this emulation, the Sun will have become a red giant, Earth's seas will have boiled away, and its atmosphere will have escaped into space, or at least you'll feel that way... If you were play back a time-lapse of the boot process so that Vista appeared at normal speed, you would look like the villain in Indiana Jones and the Last Crusade after he drank from a false chalice.

Re:How's the efficiency?

[yoyhed]

I'm sure there's already a Java minesweeper clone...

Re:How's the efficiency?

[yoyhed]

Agreed. And to the GP and GGP, nice trolls. Vista boots faster than XP, and both of them boot faster than Linux (and yes, I use all 3).

Re: How's the efficiency?

[Dolda2000]

near-native speeds are necessary to actually boot Windows Vista before the sun goes supernova.

The sun isn't close to large enough to end in a supernova; it'll be a red giant, then end as a white dwarf.

I was going to comment on that as well, but then I realized that he probably knew that already, and that that was precisely what he meant. :)

Comparisons to other emulators?

[Anonymous Coward]

How does it compare to Qemu or Bochs, both open-source x86 emulators?

Re:Comparisons to other emulators?

[dreamchaser]

Both of those need to be ported to the target OS that they will be hosted on. A java based emulator doesn't need to be ported.

Re:Comparisons to other emulators?

[badfish99]

A java based emulator doesn't need to be ported.
That's the huge advantage of java. Just port the 100 meg or so of JVM, throw in a faster processor and a few more gigs of memory, and it'll run on anything.

Re:Comparisons to other emulators?

[bluefoxlucid]

Because emulators are special. Now P2P clients on the other hand.. well, LimeWire Windows, LimeWire OSX, LimeWire OS9... hey at least LimeWire has a single port for BSD *and* Linux, no need to port there.

Re:Comparisons to other emulators?

[bluefoxlucid]

Most of Sun's JVM is in Java. It's like Minix: Kernel is in low-level kernel mode, while services are in user mode and use an interface to the kernel, and other services in user mode use those services, and userspace apps utilize those services. In Java, though, you're abstracting away from the hardware rather than from other software; so some part of Java (the JIT) is in a mix of C and assembly; while some other part of Java is in Java; while some other part of Java uses that part of Java and is written in Java; and the Java application along with most of Java get JIT'd into this big program. That's also why Java is slow. (Note: Minix is all C, or I guess you could write services in C++ if you really wanted.. or java.. but point is, it doesn't abstract from a lower-level language and create more fluff and more levels of abstraction to run through to exponentially increase the length of the code path, it just linearly lengthens the message passing path).

Re:Comparisons to other emulators?

[pjt33]

The JVM isn't 100MB, but about 3. It's the SE 1.6 standard libraries that are 100MB (or 50MB, anyway - rt.jar is 46). If you just want to run the emulator and don't care about your port being called Java then you only need to port the libraries which it uses, which could be quite small. The Personal Profile of J2ME is a cut-down version of SE 1.3 and can be implemented in under 10MB.

Two great tastes

[FatherBusa]

Talk about gilding the lily!

What's next? A Windows emulator written in Intercal?

What's wrong with virtualisation?

[pdbaby]

What's wrong with virtualisation? Yes, you can't run it on a phone's ARM processor but you wouldn't do that in the first place.

Java x86 emulator speed

[christurkel]

Java only: snail speed
Java+DOS: Snail with ball and chain
Java+DOS on non x86: Snail nailed to the table

So it runs DOS eh?

[ookabooka]

But can it run Linux. . .?

Why did they use Java? It would have been faster in C++.

I for one welcome our new old x86 overlords.

Did I miss any?

Re:So it runs DOS eh?

[HoosierPeschke]

In Soviet Russia x86 emulates Java?

Re:So it runs DOS eh?

[Anonymous Coward]

beowulf

Re:So it runs DOS eh?

[Anonymous Coward]

In Soviet Russia, DOS runs Java.

Re:So it runs DOS eh?

[muftak]

I tried using a linux boot floppy instead of the dos one, and it just hangs before booting the kernel.

Re:So it runs DOS eh?

[terom]

But can it run Linux...?

Based on the table at the bottom of this page, dubious. Only real mode (e.g. DOS) is supported properly, the protected mode that any modern OS uses is in "beta" for interpreted stage, and compiled mode is "currently less mature". The cited 10% performance figure is for compiled real mode, and I'm willing to bet that interpreted protected mode would be somewhat slower.

Also, it doesn't say anything about supporting real graphics (8-bit VGA isn't everything), and something like USB or a CD drive would also be pleasant. What's the performance of the file-based-filesystem it uses?

Re:So it runs DOS eh?

[rrohbeck]

>Did I miss any?

In Soviet Russia, Java runs x86!

Re:So it runs DOS eh?

[sinkemlow]

Step 1: Write x86 emulator in java.

Step 2: Wait three years for it to boot DOS

Step 3: ???

Step 4: Profit!!!

There, I think that pretty much rounds out the list.

Re:So it runs DOS eh?

[Anonymous Coward]

Can you imagine a Beowulf cluster of virtulized x86 processors?

Re:So it runs DOS eh?

[Anonymous Coward]

In Korea, only old people emulate x86.

Netcraft confirms it: x86 is emulated.

Re:So it runs DOS eh?

[Constantine XVI]

Just wait for them to implement the friggin laser beams on the x86 emulator

java me is not java se

[Billly Gates]

It will take some work to port.

But still cool though.

Re:java me is not java se

[pjt33]

Java ME isn't a single configuration or profile. It's probably not too hard to port to CDC/PP, but CLDC1.0/MIDP may be trickier.

What do you do when it crashes?

[CTho9305]

I was playing around with DEBUG.COM and ran "OUT 20, AX"...and now it's apparently dead. A lot of things don't seem to work - e.g. "mode 80,20". Even "dir c:" when the current drive is "a:" seems to hang. I wonder how complete the hardware emulation is. Can you run Windows 3.1 on this? How about programs that probe for a joystick?

Re:What do you do when it crashes?

[ScrewMaster]

All I know is, if it can't run Duke Nukem Atomic Edition, Shadow Warrior or Blood it's useless.

Re:What do you do when it crashes?

[Eudial]

I was playing around with DEBUG.COM and ran "OUT 20, AX"...and now it's apparently dead. A lot of things don't seem to work - e.g. "mode 80,20". Even "dir c:" when the current drive is "a:" seems to hang. I wonder how complete the hardware emulation is. Can you run Windows 3.1 on this? How about programs that probe for a joystick?

It isn't dead! For crying out loud, it's java! It's still processing the instruction... Come back in September for the result.

Re:What do you do when it crashes?

[jrumney]

It seems they forgot to emulate the bluescreen.

Re:What do you do when it crashes?

[mattoo]

It hung on me as well while trying to switch the keyboard layout using 'keyb be'...

Re:What do you do when it crashes?

[kasperd]

ran "OUT 20, AX"...and now it's apparently dead.

You are writing random bytes to the interrupt controler. What did you expect to happen? Just reload the page to reboot the virtual machine. (I'd have tested it on a different emulation as well, but I don't know how to get the disk images they are using).

Re:What do you do when it crashes?

[MrPeach]

I ran FDISK and deleted the C drive.

Lol.

Well for one

[brunes69]

For one this will let you run X86 DOS applications on a SPARC for example.

I'd like you to point me to the support page for VMWare on SPARC... oh wait that's cause there isn't one. QEMU can't even run most applications on a SPARC.

And forget about ARM.

I think this is great. Java is not as slow as people seem to think it is. One thing Java 5 (and 6) have that actually benefits virtualization is dynamic recompilation... the JVM knows the instruction sdequences better than the original author, and in theory can optimize the code paths in ways writing a virtualizer in assembly or C++ can not.

Re:Well for one

[EvilIdler]

Java isn't all that slow, but the bad rep is because of its startup time and a really unoptimised GUI.
It's fine for all sorts of things while running, but the two apps I use it for aren't exactly impressive.
If I leave Azureus up for a while, it's eating 400 megs of memory. It also takes 10+ seconds to show
its window. The other thing I regularly use Java for is my bank, which insists on using a friggin'
control in its window. It takes about a minute to show up, even with other Java apps running. It seems
the startup time is a per-process thing, not the entire loading of libraries and stuff.

I recently installed Eclipse, and it's a world apart from the slowness of the bank webapp and Azureus.
Starts up immediately, ready to rock. I may start using it once I figure out how :P

Re:Well for one

[daeg]

If you are using Firefox with Java and having ridiculous applet startup times, you need to disable your Java Cache. This is Java's fault, not Firefox's (supposedly).

Under the Java control applet, under the General tab, click "Settings..." under "Temporary Internet Files". Then click "View Applets...". It will take a moment to load (or in my case, 2-3 minutes). Then UNcheck "Enable Caching". Firefox now starts my applets almost instantly. This doesn't affect downloaded Java applications such as Azureus or Eclipse (both of which I use extensively).

Hope this helps.

Re:Well for one

[caseih]

QEMU is listed as fully supported on SPARC. Both the full hardware emulation (full machine requiring an OS) and Linux-on-Linux mode. The emulated CPU also does dynamic translation so the speed hit shouldn't be nearly as bad as bochs and this java emulator.

Still, though, your point is taken. This emulator could run x86 software anywhere the JVM is. Of course the primary purpose of it seem to be for research purposes (debugging rootkits, etc). Whether it will metamorphose into something practical remains to be seen.

Re:Well for one

[jimmydevice]

I did something even slower in 1973. A Cardiac ( Bell Labs cardboard computer ) emulator written in FORTRAN, running on a FORTRAN emulator written in HP 2000 BASIC running on a HP2100 mini. Cycle time = one instruction / Sec.
It could play tic-tac-toe, Very slowly.

Re:Well for one

[Threni]

I've not once managed to shut my (xp) machine down having used Azureus without holding the power button in for 5 seconds.

RE: eclipse - I don't know what Netbeans is written in, but after giving up on the learning curve and slow speed of Eclipse I found it a fast, untuitive breath of fresh air.

Re:Well for one

[VGPowerlord]

Eclipse and NetBeans are both written in Java, albeit with different GUI toolkits. Eclipse uses SWT, while NetBeans uses Swing.

You'd think that Eclipse would be faster due to SWT interfacing with the native widget set, but I guess this shows that GUI speed isn't everything. As a side note, Azureus also uses SWT.

Re:Well for one

[Nasarius]

For one this will let you run X86 DOS applications on a SPARC for example.

DOSBox already runs on SPARC, as it's a full emulator.

Re:Well for one

[Nasarius]

I recently installed Eclipse, and it's a world apart from the slowness of the bank webapp and Azureus. Starts up immediately, ready to rock. I may start using it once I figure out how :P

Really? Last time I used Eclipse (3.0M6, I think?), it was just as sluggish as Azureus. A shame, since it's an incredibly powerful Java IDE, and not half bad at C++ and Python. I just wish it used shareable project files, not the .workspace mess.

Re:Well for one

[Anonymous Coward]

On my debian system the control panel can be accessed here: /usr/lib/j2re1.5-sun/bin/ControlPanel

Re:Well for one

[wtarreau]

For one this will let you run X86 DOS applications on a SPARC for example.

I'd like you to point me to the support page for VMWare on SPARC... oh wait that's cause there isn't one. QEMU can't even run most applications on a SPARC.

In 1995, I used a PC emulator written in pure C which ran well on sparc. I even extended it to emulate 386/486 in real mode. I believe it was called "pcemu". It was fun by that time to be able to do this !

Willy

Re:Well for one

[AdamInParadise]

Project files (.classpath and .project) in Eclipse are shareable, with a few caveats. If you want to share them across developers, you need to enforce some stricts rules and sometimes it's not worth the shot. Also, do not checkout projects in .workspace.

Re:Well for one

[AdamInParadise]

This difference in startup times between Azureus and Eclipse is surprising. Both are based on the same framework (RCP) and I will argue that Eclipse is "bigger" than Azureus. On my box, the startup times are similar. How many torrents are you trying to download? Also, are you sure that Azureus is started in a recent JVM (like 1.6) instead of some ancient 1.4?

Anyway, in Java, each process runs in a different JVM, so there is absolutely no sharing between processes. This is a long-standing issue and Sun is clearly not interested in implementing run-time sharing. However, startup time in 1.5 and 1.6 are much better than in 1.3 and 1.4 (and it's not only because computers are faster these days). Memory use is still an issue.

Re:Well for one

[krelian]

A little bit off topic but if I take your first paragraph and replace "java" with "firefox" it still makes sense. And firefox is written in c++ AFAIK.

Re:Well for one

[AddressException]

The recent ones use a read-only mmap for thew core classes, so they *do* share things between JVMs on the same machine.

Re:Well for one

[RightSaidFred99]

Oooh, yeah, the great big "I want to run x86 instructions on SPARC/PA-RISC/Power/etc..." market! That's _huge_ and useful!!!

OK, sarcasm aside - I find this to be a pointless exercise. Interesting in a very abstract kind of way, but of very, very, very limited usefulness. Java isn't slow in all things, this is true. However, I'm willing to bet this is dirt slow. Using native VM solutions running on x86 are painful enough, especially in terms of IO, this is going to perform horrifyingly bad.

Re:Well for one

[Tim C]

For Java (1.)6, follow the above but click "Settings" instead of "View...", and uncheck "Keep temporary files on my computer". Not tested, but that's the closest equivalent I could find to the above, and disables the "View..." button.

Re:Well for one

[kisielk]

I'm curious. What's the purpose of the cache if the implementation with the cache is so much slower than without?

on a good Java runtime...

[dshk]

if the emulator itself runs on x86 then the just in time compiler of the Java runtime may optimize the code enough that we get back almost the original assembly code... but without any buffer overflows and other security problems - theoretically.

Re:on a good Java runtime...

[alphamugwump]

No. The buffer overflows would still be there, emulated perfectly. Of course, if you ran it in a sandbox, it wouldn't make a difference -- but if it was that restricted, it wouldn't be able to do anything useful.

I mean, if your copy of windows running on VMWare on linux gets rooted, it still sucks, especially if you're really using that instance of windows. If data gets stolen, it's still stolen. If you get hacked, you're still hacked.

In a VM, you can revert to a clean image, but you can also revert the actual box to a clean image. It's just harder. It's not like there's some magical thing about emulators or VMs that makes security problems go away.

Oh No

[dunezone]

I accidentally formated my virtual floppy and hard drive.

Molasses - 35mph!

[Anonymous Coward]

not that slow if there's enough of it!

Applications

[Anonymous Coward]

"Researchers at Oxford have built an x86 emulator that runs purely on Java, making it ideal for security researchers who want to analyze and archive viruses, host honeypots and defend themselves against buggy or malicious software without hosing their machines"

From TheRegister:
http://www.theregister.co.uk/2007/03/23/java_emula tor/

Commander Keen!

[IICV]

Yeah yeah yeah, it's sort of slow, if you screw around with the debugger it dies, but...

They've got Commander Keen!

Re:Commander Keen!

[digitig]

That was decisive for me -- until I tried playing it. The keyboard handling is broken. Why bother porting games, they ask? Because that way they work. Neat idea, premature release.

Re:Commander Keen!

[BiggyP]

Hmph, it is indeed CK, but only CK1, i want keen4e!

actually, i think this emulator is far more suited to alleycat and sopwith2, maybe impact would be playable

Lemmings and Prince seem like odd choices, arent these cracked versions of commercial titles, i know no one cares thesedays but still.

Re:Commander Keen!

[gbjbaanb]

what you want, me old mucka, is DosBox. And then you can have all of 6 Commander Keen episodess. Here's the first one, enjoy.

Can I conclude: Survive /. effect = robust

[Anonymous Coward]

Now granted, I'm pretty sure that not all of /. would run warm for this and therefor I'm convinced that the /. effect will be of a lesser degree then you'd get with the hotter topics. BUT, having said that...

I know I'm biased when it comes to Java since I consider this to be a very flexible and fantastic programming language. But would I be too far off when I say that this /. demo could very well demonstrate the robustness which Java can deliver? If this webapp. survives a lot of geeks messing and hacking about in that virtual machine I'd be very tempted to label this as a very interesting experience when it comes to the Java robustness factor.

So what about it? Has anyone already experienced glitches or....

Re:Can I conclude: Survive /. effect = robust

[animaal]

If this webapp. survives a lot of geeks messing and hacking about in that virtual machine I'd be very tempted to label this as a very interesting experience when it comes to the Java robustness factor. There's no danger to the virtual machine. The emulator and disc images are all run within the browser. So each browser receives its own emulated memory space and fresh disc images. No processing occurs on the server (except for serving the application code and disc images to the browser).

Re:Can I conclude: Survive /. effect = robust

[Anonymous Coward]

I'd be very tempted to label this as a very interesting experience when it comes to the Java robustness factor.

eBay, Google (GMail, Adwords, and many more), FedEx (who has more Java developers than Sun, which speaks quite some ;)

You hardly can do any money transfer today without having Java involved at one point or another.

And this in only ten years, not a single language has ever done the same.

You can rest assured for Java's robustness in the real-world. And, no, most people do not realize how good the Java VM is.

Did you try it?

[Ron Harwood]

It's not bad - admittedly it's running DOS - but Prince of Persia seems to run nicely.

gee whiz

[Anonymous Coward]

If it can be spread across a beowulf cluster, install Windows and have it appear to be a single processor to it, load the latest game of interest or your favorite FPS, connect to the internet and start stress testing. Should have some type of "gee whiz" moment soon. This might make for an interesting honeypot design too. It might be interesting to try the same with a main frame, have it make all the processors count as one x86. Of course if such emulation is made possible by this, the "per processor fee" corporations are going to howl and I don't think their response will quite be "gee whiz".

can you run java in the x86?

[leuk_he]

THe next question would be: can you run java in the x86 emulator that runs an other emulator that runs java, that runs an other emulator.

Just like the old days when you ran windows real mode under a windows 386 mode windows.

Re:can you run java in the x86?

[faragon]

Why not? Just you get execution speed and available memory progressively downgraded/shrinked (doing it ad infinitum or ad nauseam , until you're out of memory for the next emulation context) :~P

Re:can you run java in the x86?

[Citizen of Earth]

The next question would be: can you run java in the x86 emulator that runs an other emulator that runs java, that runs another emulator.

...written in XSLT.

Re:can you run java in the x86?

[idonthack]

...or would you?
Linux on emulated hardware can be faster than Linux on real hardware:
http://linux.slashdot.org/article.pl?sid=06/05/31/ 0641207

Re:can you run java in the x86?

[Cyberax]

Yes.

The next step is to get rid of hardware altogether.

Re:can you run java in the x86?

[Pseudonym]

It's turtles all the way down, I tell you!

Re:can you run java in the x86?

[timeOday]

Linux on emulated hardware can be faster than Linux on real hardware:

There you go, a perpetual speedup machine. Run enough layers of Java on X86 on Java on X86 and supercomputers will be replaced by Cyrix 386s.

Re:can you run java in the x86?

[The_Wilschon]

Oh, I was going to write it for a Turing machine, running in Conway's Game of Life, implemented in Postscript.

Re:can you run java in the x86?

[Anonymous Coward]

"Emulators without hardware? How are you supposed to run them?"

"What you have to realize, is that there is no hardware."

And the user was enlightened.

Re:can you run java in the x86?

[rabbit78]

YES. This shows a DOS inside JPC inside IKVM (Java) inside .NET. :-D

Re:can you run java in the x86?

[kasperd]

Just you get execution speed and available memory progressively downgraded/shrinked

If you do a full emulation of the instruction set, you are going to get a slowdown which is exponential in the number of layers. OTOH if you want an architecture to emulate itself, it might be possible to virtualize it, such that the actual computations (which should be where you spend most of the CPU time) actually run natively thus no slowdown. However even in that case, there will be some privileged operations, which have to be emulated. I guess they will typically have an exponential slowdown, thus when you start having a few layers, they are going to be so expensive that adding another layer is infeasible. I wonder if it is possible to design an architecture such that it can virtualize itself in a way where no instruction have a cost that is more than linear in the number of layers.

As for memory usage, you are obviously going to need at least a constant amount for each layer, thus there will be a linear overhead in the number of layers. But is it going to be worse? Are page tables going to cause an exponential overhead in memory usage as well? (And is the base going to be large enough for that to matter? 1.001^n isn't that bad a complexity).

Re:can you run java in the x86?

[faragon]

That is because we're assuming one-way-forward interlayer knowledge, i.e., layer 0 emulates layer 1, layer 1 emulates layer 2, but layer 0 knows nothing about layer(s) at level 2. Allowing layer-mixing/inference via abstraction, could increase performance, as soon as higher level I/O bottleneck or CPU stall analysis could allow better instruction mixing or let other layer continue on execution while the conflictive is rescheduled. For me it is likely to how a OS works, but change the basic unit (thread/process) by a virtual machine. Current "hypervisors" do profiling for both CPU and I/O balancing, to maximize throughput, latency, or other exotic profiles.

Re:can you run java in the x86?

[kasperd]

but layer 0 knows nothing about layer(s) at level 2.

In general I'd say that is a good thing. Knowledge about more layers is going to make the implementation more complicated, and we'd rather have emulators be simpler than more complicated. A lot of the complexity in emulators is due to the history of the architecture they are emulating. (The PC is a nasty mess of patches rather than a well designed system). But the simpler the emulation can be made, the more reliable I'd expect it to be.

What I'd like to see is not really a system where each layer has knowledge about a lot of layers below, but rather one where the designer has the knowledge. Figure out what the cost of multiple layers of your own virtualization is going to be, and improve on that without assuming that you are necesarilly going to be running under your own virtualization in the end.

Current "hypervisors" ...

Current hypervisors are not really designed for running under themselves, in fact the architecture is not even designed with virtualization in mind. There are attempts to improve on this, but I haven't yet had the oppertunity to play with any of those. Of course being able to virtualize yourself is the first step, only then can you start considering performance.

Re:can you run java in the x86?

[faragon]

You're right; current hypervisors are not really designed for running under themselves nor, in most cases, for running other supervisors, quite primitive everything. I was mostly figuring hypothesis, don't take me seriously :-)

Re:can you run java in the x86?

[that this is not und]

That's cool, because I have a large collection of all the weird variants of 386/486 processors from 'back in that ugly era' when everybody was looking for cheaper ways to run Windoze 3 in enhanced mode. This means that someday this sort of perpetual motion will make my collection very VERY valuable on eBay.

1 MHz 12-bit CMOS microprocessors are already selling for more than Pentium D processors on eBay, by the way.

Re:can you run java in the x86?

[that this is not und]

Getting rid of it by using up as much as possible for the most mundane tasks possible?

Java isn't slow anymore

[Ranx]

The first ten reactions are about how slow Java is. Wake up! It's 2007, NOT 1997. The world has changed. Don't you keep your knowledge up to date? Are you amateurs? And no, a benchmark from 2001 doesn't count too.

Re:Java isn't slow anymore

[Anonymous Coward]

Just stop it. You aren't fooling anyone. Anybody that has to use typical corporate java apps to do their jobs knows what a crock of shit the "java's not slow" claim is. I'm sure you've got tons of excuses to attempt to explain away common experience, but nobody's buying it.

Re:Java isn't slow anymore

[wtarreau]

The first ten reactions are about how slow Java is. Wake up! It's 2007, NOT 1997. The world has changed. Don't you keep your knowledge up to date? Are you amateurs? And no, a benchmark from 2001 doesn't count too.

No of course it isn't, and that's why BEA does not mind proposing you only a few hundreds of CPUs and as many gigs of RAM to port to weblogic an application which has been running well in pure C on at least a few tens of CPUs...

This must be because they don't know java yet, not because the technology is horribly slow.

It always gets me nervous to read what people can write on those technos. It looks like they have never seen them in use in enterprise. Maybe on your PC to print "hello world" it looks as fast as C, but stop being naive and look how many kilowatts are burnt by machines running java in enterprises. Then you may reconsider your statement.

Willy.

Re:Java isn't slow anymore

[pommiekiwifruit]

Surely the point is that printing "hello world" on a fast PC takes several seconds in Java, whereas it takes a fraction of a second in almost any other language, let alone a compiled one. Mind you, Microsoft has risen to the challenge of Hollywood Movie operating systems with Windows XP so it can take several seconds now to do anything for the first time (e.g. the first time you delete a file after a reboot), so perhaps they have something to do with Java's startup times.

Re:Java isn't slow anymore

[Anonymous Coward]

Surely the point is that printing "hello world" on a fast PC takes several seconds in Java

Either you're including the start up time for the JVM (bad, because you're being intentionally misleading over a microbenchmark), or you're lying through your teeth (also bad.)

Re:Java isn't slow anymore

[Anonymous Coward]

Oh, is the JVM optional then? The whole point of timing "hello world" is to see how long a language runtime takes to get its arse into gear.

Re:Java isn't slow anymore

[pommiekiwifruit]

Hmm, I have downloaded the latest JDK version now (over 50 megabytes, phew!) and it seems that PCs have got faster over the last ten years. Apart from the first time you run a java program (several seconds) the startup time for "hello world" has got down to 0.3 seconds on my fast PC, which compares to 0.1 seconds for a decent sized (2Mbyte) C++ program or 0.03 seconds for a small C++ program.

So it is now practical to be used in batch files/as part of a build process from a makefile - only ten times slower than a native program but PCs are at least ten times faster than when Java was introduced.

For long running programs obviously startup time is less important, but monolithic kitchen sink programs are not "the unix way" which /. espouses allegedly :-). Of course this has not much to do with perceived slowness in the GUI, which has nothing to do with the Java language.

Yes

[alienmole]

Imagine a Beowulf cluster of these...

Re:Ah, a Java-based x86 emulator...

[gravis777]

Since when did emulators become news on slashdot? Its still buggy too. No mouse support (makes playing Lemmings a pain), graphic corruption in some places in Lemmings, arrow keys get effed up when playing Prince of Persia, no sound support, and, well, its kinda slow. Some lagging in Prince of Persia, and I am on a p4. Now, did the original post say that they wanted to use this to test viruses? Please tell me they are not planning on installing windows on this thing.

Although I would smile if they installed Windows 3.1 and the thing dropped into dosshell when you exited. Of course many licensing things there. I guess there is no licensing issues showing off a product you are trying to license with shareware titles, is there?

Just one.

[Bill, Shooter of Bul]

In soviet Russia x86 emulates Java.

Re:Just one.

[Anonymous Coward]

In soviet russia, x86 emulates java!

Java isn't really slow...

[Belial6]

Java isn't really slow when you consider that it is an emulator. As emulators go, Java is down right zippy. Of course everyone seems to forget that it IS an emulator.

Re:Java isn't really slow...

[Anonymous Coward]

It's not that everybody forgets, it's that they just don't care. If my corporate overlords force me to use some godawful steaming pile of java app to get my job done, the excuses for its memory leaks, horrible performance and clumsy UI from the java apologists mean nothing.

Keyboard Layout change hangs

[jawtheshark]

The first thing I typed at the prompt was "keyb sf" and it hangs... Great...

I can use the US layout, that's not it, but I prefer to see the letters on my keyboard when I type.

Re:Keyboard Layout change hangs

[kasperd]

The first thing I typed at the prompt was "keyb sf" and it hangs... Great...

That is kind of interesting. At some point I wrote a PC emulator myself (using virtual 86 mode), I found it easier to get KEYB working than to implement the full keyboard handling normally provided by the BIOS. Though I did find that the MS DOS version of KEYB does require all the nasty details of interrupt handling to be working. I don't know if the FreeDOS version of KEYB is better or worse in that respect, I never got FreeDOS booting on my own emulator.

Lemmings without a mouse

[tepples]

No mouse support (makes playing Lemmings a pain) I've read that Lemmings is a pain on the PSP too, and for the same reason. The only reason Lemmings came out on the PSP is because Sony bought Psygnosis. Any other publisher would have put it out on the DS, on Windows Mobile, or both.

Although I would smile if they installed Windows 3.1 and the thing dropped into dosshell when you exited. I've always wondered why "DOSS Hell" was spelled with two S's.

Re:Lemmings without a mouse

[gravis777]

I've read that Lemmings is a pain on the PSP too, and for the same reason. The only reason Lemmings came out on the PSP is because Sony bought Psygnosis. Any other publisher would have put it out on the DS, on Windows Mobile, or both. Actually, Lemmings on the PS3 is remarkably well done. Good play control, redesigned levels, and they sell the thing for like $5.

Compared to what?

[alienmole]

You're missing something here. Sure, Java is faster than some languages like Python or Ruby or PHP, but that doesn't necessarily put it in the realm of languages that are a good choice for implementing hardware emulators. There are many other languages that would be faster and, at the same time, more high-level than Java. (The ML family comes to mind.) The Java sandbox argument they use in this case is rather bogus - if you're writing an emulator, you can easily build sandbox functionality into it. In short, the choice of Java for this project is nowhere near as rational as the authors would have you believe. They probably chose it because that's what they were familiar with, or because it helped them get funding.

Re:Compared to what?

[ToasterMonkey]

Why is writing this emulator in Java a bad idea? It seems to have acceptable performance. The fact that it can play games at a decent clip suggests it could perform just fine with most other applications (of the same era as these games at least.) Games are generally much more resource intensive than other types of applications. It's even runs on any system with a Java platform, that's not something to shrug at. I'm typing this on a Mac, and it loaded just fine in my browser.

You seem to be missing something here, you have no good reasons NOT to write this emulator in Java.

-Steve

Re:Compared to what?

[alienmole]

If the purpose of this emulator is just to run DOS, DOS programs, and programs of similar size, then perhaps implementing it in Java is "acceptable", as you say. However, DOS ran happily in 640KB of memory or less, on CPUs that started from 4.77 MHz. That's why it's possible to emulate it successfully on modern hardware, because the hardware now has clock speeds nearly 1,000 times faster and memories more than a thousand time larger. To emulate more demanding systems, better performance would be needed, and Java would become a handicap.

My other point is that the sandbox features of Java are really not that significant if you're writing your own emulator. Finally, of course, there's the fact that Java is a rather inexpressive and unnecessarily verbose language, with a relatively primitive yet complex type system.

Re:Compared to what?

[dsmall]

Previous post said "if you're writing an emulator, you can easily build sandbox functionality into it."

Well, that's not necessarily true. The word "easily" gets used too much. To add a sandbox can clobber performance in software-only emulation. In those emulators you have to keep the fetch-dispatch loop down to the bare minimum (no code at all would be nice, but difficult to attain). Anytime you're adding range checks the performance drops very quickly.

In the case of the PC you can sometimes confine the range checks to the emulated BIOS (which you can rewrite in the target language and thus make very quick) and the emulated hardware for that fun I/O stuff. There's a great deal of bookkeeping in emulating PC hardware.

I'd be rather hesitant to trust the range-checks of a rewritten BIOS against all viruses. Bugs happen. People are creative, although fortunately creativity doesn't seem to happen to virus writers much.

-- thanks,

Dave Small

Other projects doing the same/faster thing..

[Boj]

There are at least 2 solutions doing a similar thing. The open source binarytranslator.org/PearColator offers x86 and PowerPC emulation:
http://binarytranslator.org/
There are attempts to integrate this into the JNode open source Java OS to make a JNode/GNU stack.

There is also the VEELS/JXEmu system:
http://nil.ics.uci.edu/~gal/?page=VEELS
which appears not to be publicly available.

My intepretation

[Excelcia]

An interpreted language being used to write an opcode interpreter.

For an encore, perhaps they can write a JVM in BASIC.

WARNING: Performance implosion imminent due to recursive interpretation.

Re:My intepretation

[batkiwi]

I know you're being funny, but Java isn't interpeted any more than C is. Both are compiled to produce machine code (one meant to be run on a virtual machine, one by a native one, but nothing's preventing someone from making a hardware JVM).

Re:My intepretation

[Anonymous Coward]

nothing's preventing someone from making a hardware JVM

Also, nothing is preventing someone from making Windows secure. But it hasn't happened yet, has it?

There are other reasons beyond technical reasons that keep hardware JVMs from becoming reality and then mainstream.

Re:My intepretation

[Anonymous Coward]

"Java isn't interpeted any more than C is"

yes it is.

the difference being, C is compiled to _real_ hardware, where as java is compiled to a virtual machine.

Re:My intepretation

[Excelcia]

I know you're not trying to be funny, but well, you are. While it's true that nothing is stopping someone from making a hardware Java bytecode running solution, the fact that it's possible doesn't make Java a non-interpreted language, any more than the fact that it's theoretically possible to create a hardware BASIC solution makes BASIC a non-interpreted language. Sure, it's possible, but until it's in a significant portion of desktop computers, thinking of it this way is a meaningless mental exercise.

Compiling a language to bytecode and running that in a VM is actually nothing new. Many BASIC interpreters worked that way, one notable one being Commodore's CBM BASIC on the Pet/SuperPet computers. They converted typed input into a sort of bytecode immediately on entering a line. Call this the first JIT compiler.

The move from bytecode to native wasn't a GNU gcj innovation either. Give that accolade to Borland. Back "In The Beginning"(tm), Pascal was a similar solution to Java. It compiled into a bytecode called P-Code. There was even hardware support for running P-Code - commercially, not just in the lab. Texas Instruments shipped a P-Code card for the TI/99 series. Not a lot of people used it, but it was done. It was still pretty obscure, though, and used mostly for education. Then Borland came around with Turbo Pascal and turned Pascal overnight from an educational exercise into something that real programs were made from.

Bytecode might make it theoretically a "compiled" language, but it doesn't make it non-interpreted. If the end result of the "compilation" is run through an interpreter, then it's interpreted. If the end result is run natively, then it's not.

Why the history lesson you might ask? It's to illustrate that Java and JVMs were a step back technologically, just like .NET. Yes, let's make everything into a bytecode-interpreted language just so it can take double (at least) the processing power to do everything and require an extra software layer to maintain on every platform it runs. Welcome to the days of BASIC, my friend. Please set your watch back 15 years.

Re:My intepretation

[a1mint]

Your statement that "the end result of the compilation is run through an interpreter", is incorrect. Bytecodes *are* translated to pure machine code instructions. Why else does a straightforward calculation like a a mandelbrot, say, run faster in Java than it does than optimized gnu C ? Try playing with it. ps. benchmarking Java is tricky. Often people measure including the JVM startup time, and the runtime-jit compilation time. Even some of the most recognized benchmarks on the internet are highly flawed. But for realistic performances, Java is far faster than many realize. The beauty is that the bytecodes get translated to the best possible instruction depending on the platform it's running on. It also gets to dynamically analyze how the program is run, and optimizes accordingly. So it's a step forward, not backward.

Re:My intepretation

[batkiwi]

Fine then, according to YOUR comments C is an interpreted language. C compiles to assembly, which is then INTERPRETED into machine code.
Also, your point of "It's to illustrate that Java and JVMs were a step back technologically, just like .NET" shows quite a bit of ignorance. In an enterprise environment, which is more expensive: Developer time, or more/faster servers?

Re:My intepretation

[Excelcia]

Where is the win in the situation? Native programs you maintain just the program. VM programs you maintain the program and the VM. The ignorance is people who convince enterprise management that this is a good thing.

Re:My intepretation

[Anonymous Coward]

Fine then, according to YOUR comments C is an interpreted language. C compiles to assembly, which is then INTERPRETED into machine code.

Actually the assembly is translated directly into machine code (normally a 1-1 relationship, although sometimes assembly programmers use pseudo-ops that expand to one or more actual operations). However, you are then absolutely correct - the machine code is interpreted by the processor, which is a hardware virtual machine. If the processor is controlled by one or more microprograms (as many are), you can regard the microprogram as the virtual machine program.

The idea of writing a virtual machine as a microprogram dates back to the 1950s. It was first used commercially in the System 360, where it allowed all the machines in the S/360 family to share a common architecture. Modern descendants of the S/360 will still run binaries compiled for the first model.

Microprogramming is a very old way of making a processor present a particular instruction set architecture, e.g. x86, regardless of the internal architecture of the CPU. This has a lot in common with Java, which presents a common instruction set (bytecodes) regardless of the underlying platform.

Virtual machines on virtual machines on virtual machines...

Re:My intepretation

[metamatic]

While it's true that nothing is stopping someone from making a hardware Java bytecode running solution, the fact that it's possible doesn't make Java a non-interpreted language, any more than the fact that it's theoretically possible to create a hardware BASIC solution makes BASIC a non-interpreted language.

Hardware CPUs that run Java bytecode directly already exist and have done for years.

So Java is no more "interpreted" than C, which was designed for a specific architecture (the PDP), and is also available in interpreted forms and used to compile code which is run as bytecode. You can even compile C to Java bytecode.

Whether something is compiled or interpreted is not a function of the language, nor is it defined based on which CPU instruction set happens to be most popular at the moment.

license

[pmsyyz]

Do me a favor and don't pimp software until we can be sure it is non-proprietary.

Re:license

[mohjlir]

So should we just run OSS news? Then all the MS trolls would have to get jobs! Seriously, this is news no matter what the copyright holders intend to do (or charge) for the software.

Re:license

[Nasarius]

Why is it news? It's not like an x86 emulator is anything new. While this is hardly the worst article ever posted to Slashdot, this emulator will be a pointless toy if it's closed-source.

Re:license

[mohjlir]

It is news because unlike bochs, this is written in java. It will run on your mobile phone, for instance, without *any* modification (provided it has jvm). Think retro arcade games on your mobile...

Obligatory...

[Anonymous Coward]

Bah... I have them all beat.

I have an x86 emulator written in BASIC with a JavaScript interpreter for extra security, utilizing Firefox's excellent sandboxing and BASIC's general lack of usefulness to ensure that no malware can get through. If malware does slip through, it will give researchers plenty of time to stop it.

I'm amazed that no one asked yet

[Anonymous Coward]

but does it run linux? does it eventually??

Why not Simics?

[Anonymous Coward]

I can get Simics for free if I am an academic and Simics gives over 300 MIPS on 2GHz AMD64s (and probaly a lot more on the Core 2 CPU). I really fail to see the use of something that probably is dog slow, written in Java, and probably cannot do reverse execution. Oh, btw, Simics does x86, x86-64, SPARC V8/V9, PPC32/64, MIPS32/64, ARM and perhaps some more.

Can someone explain the advantages of the Java based x86-emu in TFA over something like Simics?

Re:Why not Simics?

[ToasterMonkey]

Given the requirements of Simics, and that the Java x86 emulator in question can run inside a BROWSER, I'd say it's quite clear what the advantages are.

from http://www.virtutech.com/products/product-faqs.htm l

Q: What is required to run Simics?

Simics currently supports 32-bit IA32 hosts running Windows (2000 and XP) or Linux, AMD64 and EM64T hosts running Linux, and 64-bit SPARC hosts running Solaris. Minimum requirements to run Simics includes: Pentium 4 processor (for Windows or Linux host) processor, 512MB of RAM, and 500MB of available disk space.

Re:Why not Simics?

[Anonymous Coward]

The benifit to me as I see it, is that there's a huge wealth of apps written for x86. To run these in a browser environment offers a great number of new opotunities. What about SaS distribution of old apps via java applets. This offers a whole new plethgera of opotunities for software as a service, removeing the need for install, and therefore removeing the big old risk of infection/system incompatability requiring nasty roll backs etc... Just visit the site, make your choice, and get fed your app... Peachy if you ask me.

I tried the demo, but it didn't work

[Master of Transhuman]

via my Firefox on Kubuntu using the Java 1.5 plugin.

The demo started up okay, booting and getting to an A: prompt. But it wouldn't accept keyboard focus so I couldn't enter any instructions to run any of the games.

I contacted the project to let them know. They responded that I probably need to upgrade to Java 1.6 to insure keyboard focus. It's also possible that one of my Firefox extensions might have interfered. They said they have tested JPC with Firefox and Linux but not with Kubuntu specifically.

I was surprised that the startup worked fairly well. There is a very long delay while the Java applet loads and I thought Firefox had frozen, but eventually it started up rather well.

Re:I tried the demo, but it didn't work

[Nasarius]

I got the same problem with Konqueror and Java 1.6. No keyboard focus. *shrug*

Re:I tried the demo, but it didn't work

[gkhan1]

It did that to me at first to (I'm running Firefox under Ubuntu), but after reloading the page a couple of times, and making sure that the applet was the first thing I clicked, it worked fine

A bigger problem for me is that I use a non-US keyboard which means that it I couldn't do anything because I couldn't change the locale so when I typed ":" it entered ">". Meaning I couldn't do anything since I couldn't change the drive to c :) Anyone got a fix for this?

Re:I tried the demo, but it didn't work

[cecom]

Same problem here with Firefox and JDK 1.5. Shrug.

Re:I tried the demo, but it didn't work

[normuser]

to make it work you have to download the http://www.physics.ox.ac.uk/jpc/JPCAppletObfs.jar file. extract it to a folder (I put it in ~/jpc/) then make an html file in your jpc folder with an object (be sure to specify the width and heigth you want) with three param tags. the first one name CODE value "org.jpc.j2se.JPCApplet" the second one name type value "application/x-java-applet;version=1.5" and the third one name scriptable value "false". then just run your html file. At that point you can also play with the .img files. they are just dd dumps.

Re:I tried the demo, but it didn't work

[jaavaaguru]

I also use a non-US keyboard (a UK one) and haven't had any keyboard problems. Are you using a non-qwerty keyboard?

Re:I tried the demo, but it didn't work

[gkhan1]

No, it is a qwerty one but it's Swedish so I have a few extra keys ("å","ä" and "ö") and everything else is slightly moved around. This often happens the first time I use a new OS if I didn't set the locale during start-up or sometimes with dumb computer that don't expect that they might be played by more people than occupy North America.

Re:I tried the demo, but it didn't work

[Master of Transhuman]

Ah, that worked for me, too.

However, the games are so dumb (I never played games back in the DOS era, either), that after proving it worked and climbing three levels in Kong, I stopped playing it.

Cool project, though. It will be interesting to see where it ends up.

Re:I tried the demo, but it didn't work

[normuser]

been playing with this alitle more. the hd image is a sparse image made with bximage.

Why Java ?

[DrYak]

I do understand the reasons they chose the language

I don't. What does Java has to offer that some standard C emulator doesn't ?
Some of the current emulators provides special hooks so the emulated code can ask the emulator to perform some task for acceleration (like some emulators provide special graphic and network drivers for the emulated Windows).
But if you cut them, there are no differences between the emulator and a real machine from the virus' point of view.

If the emulator is well done enough there won't be any exploit that the virus could use to make the emulators's host run arbitrary code.
Or are they using Java just because they want not to need to do extra efforts to be sure the virus won't easily escalate out of the emulator ?

Re:Why Java ?

[suckmysav]

"What does Java has to offer that some standard C emulator doesn't?"

Can you compile C apps to run on your phone? I know I can't.

Re:Why Java ?

[Anonymous Coward]

"I don't. What does Java has to offer that some standard C emulator doesn't ?"

- You can write code much faster (i will not tell why)
- "Emulator" code is secure.
- Java IDE's are much more advanced.
- You dont need to "Port" the application from platform to platform. (in C i would like to imagine your makefile, of #ifdef lines.)
- Java is fast. give a try.

so give it up.

Java is fine for emulation

[tezza]

[1995] When I was at university on Java 1.0, we were taught operating systems on emulated Minix. It was fine then, no reason x86 won't be fine now.

Just give this project time. Everybody is queuing up to knock it down, but it should be fine. They're not planning to put Vista on it, just emulate some DOS data entry applications.

Re:Java is fine for emulation

[jsight]

What? Where would you get an emulated Minix that runs on Java?

The mythical "good Java runtime".

[Anonymous Coward]

First of all, what you're suggesting is complete bunk. If you knew even the slightest thing about JIT code generation or the optimizations that the JVM performs, you'd know how completely incorrect you are. Furthermore, your ignorance concerning emulator construction is even more pathetic. In this case, the Java code would get coverted to machine code by the JIT compiler. But that code will in no way be anywhere close to the machine code you're running on the emulator.

Remember, the emulator is virtualizing the x86 hardware. The operation it eventually performs may indeed be similar to that of the machine code being executed. But then there's the overhead of maintaining the virtualized processor state. This includes updating the flags upon each instruction. This also includes the overhead associated with maintaining the various page tables needed when using virtual memory. Then there's the complex address translation that also has to be emulated. Interrupts must be implemented separately, as the actual interrupt mechanism of the underlying x86 processor cannt be used.

Second of all, there is no such thing as a "good Java runtime". Even those put out by the top talent at Sun and IBM are rather terrible. That's basically just because a high-performance Java virtual machine is a difficult beast to construct, especially if you want to make it portable and reliable. For years we've heard about the optimization possibilities associated with JIT compiled code. But we've only seen a mere fraction of what is possible, mainly because hardware advances so quickly these days. It's just not economically feasible to implement such optimizations.

What is the point?

[chrysalis]

Sorry, but I don't get the point.

Viruses also need OS system calls to do the job. Unless there's also a full Windows emulation in Java (including the Windows bugs and vulnerabilities viruses depend on), how could this be used to analyze how viruses are working? And even if it was the case, what would be the point over QEmu?

If you need to understand what some piece of code is doing, there are tools called debuggers.

Re:What is the point?

[JustNiz]

Do you realise Windows isn't the only (x86) OS in the world? Actually there are far better ones out there....

Re:What is the point?

[jilles]

The point would be that it can be done. They're academics.

Having proven that it can be done and having proven that it can be done properly, they effectively prove you and other nay sayers wrong. They are claiming that it works and that it works with acceptable performance (for an emulator). A little out of the box thinking sometimes produces nice results. Why bother with C based emulators if you can do the job in the much more developer friendly Java? As I said, they're academics and probably have better things to do than wrestle with C when they can do the job a lot faster in Java.

As for useful applications of this technology. It requires further out of the box thinking. Of course the whole point of emulation is to run legacy stuff. Some examples: running a dos emulator in CDC java to emulate good old games without having to deploy native code to the phone. Embedding a dos emulator in a J2EE environment to run some legacy x86 server software (e.g. dbase). Both cases are examples where you wouldn't want the emulator to have exploitable memory leaks or drag the OS with it when it crashes. Java based emulators provide that feature, C based emulators don't.

Then, if it can be done for x86, it should be doable for other legacy CPUs as well. Unlike C based emulators, maintenance of this code base is probably a lot more straightforward.

Re:What is the point?

[chrysalis]

The topic is about viruses.

There are viruses on Atari ST, too, but this is a x86 emulator, not a m68K emulator.

Re:What is the point?

[DragonWriter]

Viruses also need OS system calls to do the job. Unless there's also a full Windows emulation in Java (including the Windows bugs and vulnerabilities viruses depend on), how could this be used to analyze how viruses are working?

If you emulate the machine in Java well enough, you don't have to "emulate" Windows in Java, you just install a regular x86 version of Windows onto the emulated x86 machine running on the JVM, and, bang, you've got Windows (with all its bugs and vulnerabilities!) running under your JVM.

Re:Ah, a Java-based x86 emulator...

[Anonymous Coward]

"Since when did emulators become news on slashdot?"

Sadly it's not just slashdot. I seem to encounter lots of sensational sounding studies by nonspecific "researchers at [Cambridge|Oxford]" performing miraculously mundane feats in the news. In scotland it's also fairly bad with the BBC local news often reporting about research at Glasgow University which is often, quite frankly, fucking laughable.

Wait for the lawsuits...

[DigitAl56K]

How much of the x86 instruction set has patents attached to it?

You probably wouldn't see the likes of Intel suing x86 emulators running on x86 (e.g. virtual machines), but it might be a different story if people start using x86 emulators on other CPU architectures through a Java VM because that cuts into their business.

Re:Wait for the lawsuits...

[frogstar_robot]

DOSBOX has been around for awhile and uses an emulated CPU. It works well enough to run DOS games and Windows 3.1.

Re:Wait for the lawsuits...

[DigitAl56K]

Nearly every distribution of DOSBOX is for x86 hosts. The point is that a Java emulator will have more widespread application.

Re:Wait for the lawsuits...

[halovaa]

Don't patents only last about 20 years? So any patents attached to the 286 should already have run out and the original 386 (which was released in 1986) should be just about free, if its not already. Unless of course, patents for it were filed/granted exceedingly late. Besides, other non-Intel processors implement most of the x86 instructions already, don't they? As far as I know, they're not licensed from Intel. Intel would have to justify to a court why they let them do it for so long and were only bothering enforcing the patents now. Maybe if people re-implemented the Core 2 Duo on a Java emulator they would bother....but by the time THAT emulator could produce anything usable...

We need no stinkin emulation

[k1e0x]

Uhh.. can't we just e-mail the virus to a windows user as we always have? Real panic is more fun than emulated panic.

Once.

[Weaselmancer]

Then, everything else just works.

Faster than Bochs

[Anonymous Coward]

I tried it out. It's reasonably fast. Seems quite a bit faster than Bochs. Of course an 8086 is easier to emulate than a Pentium-class CPU. All of you saying how slow Java is, well, in this case it isn't.

Java Playstation Emulator

[Anonymous Coward]

One example of how Java isn't too slow for this kind of thing: At this years Java One two guys presented their Playstation (1) emulator that was written in Java. It did on the fly compiling from machine code into java classes, and it was able to run PS1 games at full speed.

http://www.lombardisoftware.com/press-release_5-9- 06.php

Not fully functional

[AsmCoder8088]

It doesn't seem to emulate everything well. I tried running the "Debug" command and it froze up when trying to executing INT 21 (a common DOS interrupt): > Debug -A MOV AH, 2A INT 21 JMP 100 -R -T (crashes at this point) this interrupt basically gets the system time, so there's no reason for it to freeze up like that.

Slow

[andreyw]

Slow by definition. I wonder if you can use JIT techniques with java at all, but in the end, it still would have to be converted to native code.

Also, for something that's is apparently non-FOSS, they seem to be using both the BOCHS BIOS and the VGA ROM BIOS.... Now the VGA code is AFAIK LGPLd, so they should be okay unless they modified it (a possibility) but I'm pretty sure they had to modify the stock Bochs BIOS, unless they emulated Bochs. In either case, the Bochs BIOS is GPLd.

Run using your own floppy/hd images...

[Anonymous Coward]

I was able to run it manually, outside of the applet framework, by doing the following:

(1) Download jar from "http://www.physics.ox.ac.uk/jpc/JPCAppletObfs.jar "

(2) Execute using the following java command line:

> java -classpath JPCAppletObfs.jar org.jpc.j2se.PCMonitor

Also the jar archive contains the floppy and HD images, so you can replace them with your own:

> unzip -l JPCAppletObfs.jar
. . .
        38400 03-16-07 16:07 vgabios.bin
        65536 03-16-07 16:07 bios.bin
  10485760 03-16-07 16:07 dosgames.img
    1474560 03-16-07 16:07 floppy.img
. . .
  13756027 285 files

I tried replacing the floppy.img with a freesco.org linux image, but it failed to boot complaining about missing instructions. I'm guessing it only does the 8086 ISA.

Virtual Machine Advantages

[CustomDesigned]

There are a lot of applications that are not CPU bound, including business and accounting, but have a *lot* of code. We have used virtual machine code since the 1970s. When upgrading the hardware and/or OS (from Series/1 to 286 AT Xenix to Motorola 68020 to Motorola PPC to AIX to Linux), we just copy the applications and data. No mess, no fuss.

I can also think of a lot of applications that are *not* appropriate for virtual machines because of CPU performance demands. The right tool for the job and all that.

Cool thing.

[drolli]

Ok i now need a faster processor, but this is definitely cool. Why? Because it means that, as long as there is Hardware executing Java around, Dos programs can be used. Could make the transition and archiving of existing data easier.

Won't accept all keystrokes

[harmonica]

Renders my entering : as a > character (German system). Any other way to change to the c: volume?

Re:Won't accept all keystrokes

[Anonymous Coward]

Keyboard cannot be set to german keyboard. It seems to be impossible to configure "keyb ger". The emulator just throws a Java exception when processing the command...

Re:Won't accept all keystrokes

[Anonymous Coward]

I have the same problem. Can't use because I cant input a ':'. Not with my ':'-key nor with my 'ö' key, which is where the ':' is on enlish keyboars.
Would love to try it.

Re:Won't accept all keystrokes

[Anonymous Coward]

If you are running Windows, try to change your keybord layout to us and then use shift+ö. Worked for me. I did not try the Applet in the browser, but downloaded it and started it locally.

The next step

[Myria]

The next step will be for Microsoft to embrace-extend-exterminate the design for .NET, then use it to run legacy applications on a new OS that locks out native code and unsigned code.

(This is cynicism - I'm not being too serious.)

Quite interesting

[Orion Blastar]

Because this means non-X86 systems can finally run X86 code. Even if it is slow, it is better than not running X86 code at all. I assume it is a virtual X86 CPU in much the same way that MAME and MESS emulate CPUs via software.

I understand that until they are able to fully emulate certain hardware than this could be limited to just DOS programs. I think they at least out to be able to emulate a S3 Virge video card, Sound Blaster 16, Intel Chipset network card, and maybe serial ports with a Hayes compatible modem in order to run some older Windows operating systems in it using a virtual hard drive. Yet until they can at least do some of the GeForce or ATI Radeon virtual graphics cards, it will be hard to do XP and Vista and modern video games.

Just like the old Mac OS (Pre OSX) emulated a 680X0 CPU in software it took a while before PowerMac hardware caught up to allow the 680X0 emulation to be at a decent speed. A pity the same cannot be done to Intel Macs to emulate PowerPC and 680X0 cpus in software because of the big-endian little-endian differences. Although ARDI tried the 680X0 software CPU emulation in Executor they found that trying to do the same for a PowerPC CPU emulation was not as fast.

Still a Java based X86 emulator opens up a lot of possibilities, due to the fact that Java uses a sandbox and if the Java X86 virtual machine gets infected, chances are the host OS won't get infected even if it is a X86 system itself. It could be a good way to study viruses, without risking the host machine.

Not necessarily

[a1mint]

> It would have been faster in C++

C++ is not necessarily "always" faster than Java. Java bytecodes get translated to machine codes. Dynamic runtime optimizations and translations based on the platform it's running on, is something that's available in Java and not in C++.

Run a few simple loops with some math and arrays in C++ and in Java, and you'll see that the Java version often runs at about the same speed. Sometimes faster, sometimes slower.

Re:Not necessarily

[Anonymous Coward]

Now write a program and notice how much slower it gets besides of the extra memory consumption and the huge loading time. GRats Java trolls.

Is Java slow?

[Zx-man]

All you people saying how Java is slow may find it pretty amusing that this emulator in fact runs faster than DOSBOX on my G4 Mac Mini. Haven't tried it on a PC yet, though.

lame description

[Anonymous Coward]

Is the sumbitter part of the group that worked on this emulator or something? Waxes on about it like it brings something new to the table even though there's a laundry list of x86 emulators that have long done this one's claim to fame is. Lame. It's not even the first java x86 emulator: http://www.xs4all.nl/~rjoris/retro/

Re:lame description

[antiZ]

Cool stuff Joris! And the source is there too!

Re:Ah, a Java-based x86 emulator...

[Anonymous Coward]

Well there's a good catchphrase for an ad:

"Use Java (TM) on your next performance-intensive software project!
  It's not that bad any more!"

worked well on winxp + firefox + java6

[Baki]

Was playing mario and space invaders, at normal speed as if I had an early 80s PC in front of me. Impressive demo.

Yes I can.

[DrYak]

Can you compile C apps to run on your phone? I know I can't.

I happen to use Palm OS, so yes, I could.

And I don't see the point of running a x86 emulator on a phone.
- It's not a useful platform for debugging/analyzing code.
- It's not good for playing old skool DOS games (most smart phone lack the screen resolution)

Re:Yes I can.

[suckmysav]

"And I don't see the point of running a x86 emulator on a phone."

Because we are geeks, and we can, that's why. :-)

Re:Ah, a Java-based x86 emulator...

[Haeleth]

Since when did emulators become news on slashdot?

Since many Slashdotters started being interested in emulation, perhaps?

This is...

[jrothwell97]

in theory something that could revolutionise WebOSes. Instead of using a fixed OS system, users could install whatever OS they want, customise it to their heart's content, and be able to access it anywhere.

Wow, Nice Toy!

[Anonymous Coward]

Wow an x86 emulator written in java, mind you they don't say WHICH variant of the x86 series. May I suggest it's an 80x86? Why, it's written in JAVA after all :)

To get that 'true' 80x86 feel, why not run the JAVA based emulator, on a java interpreter, written in java.

Another toy, written in a toy programming language, seems fair. This does NOTHING that either VMWARE and a good debugger could do, or even BOCHS, QEMU, Etc, and mind you, they can do it far better.

This really shows that FLASH is slow...

[Dwedit]

You know something is seriously wrong with Flash when an X86 emulator running within Java outperforms Flash.

Flamebait??

[Weaselmancer]

Hey mod, I'm serious and I'm making a serious point.

Porting the JVM somewhere is about as much effort as porting a word processor, or any other 100 meg application. But if you port the JVM, all the applications you have in Java are ported by proxy. It's a one-time task.

So if your 100 meg word processor is in Java, once you port the JVM you get the word processor for free. And all of your other Java applications. You don't have to port them seperately. It's one porting task and then you're done.

And now that the JVM is open source, you can expect that to happen more often. It's part of the beauty of running VM based languages.

Licence - Lemmings etc.

[bWareiWare.co.uk]

I am also working on a licence that allows me to distribute commecial video games for fee. Do we really think that Sony considers Lemmings abandonware? - cool work though.

more like less than a 1000th the speed

[Anonymous Coward]

I don't know what they are talking about. It's 1000 times slower.

It could be useful . . .

[sanitycrumbling]

I see this as being useful under one condition only. When you ABSOLUTLY MUST have x86 emulation on a non-x86 platform for whatever reason. Like sparc or power. Much cheaper than those drop-in cards sun sells that let you run windows. (At least I assume it will be) Probably a lot slower though.

Typical Oxford NIH?

[lysse]

"the developers are said to be working on a suitable general license"

So as usual, if it hasn't been fiddled with by Oxonians, it doesn't exist yet... but then they write their own dictionary too, you know.

Interesting

[Anonymous Coward]

Now what's really interesting is if they can make a Cell-machine boot using Java boot-strapped.

Running x86 under a PS3 would definately be interesting.

Particle physics?

[Anonymous Coward]

Oxford particle physicists are confusing Space Invaders with particle physics.

This is abuse of tax payers money.

Java is like XML...

[Schraegstrichpunkt]

... which is like violence; If it doesn't solve the problem, use more.

It's been a long

[Anonymous Coward]

time since Java used a reference counting GC (if indeed it ever has).