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

[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

[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

[LBt1st]

Tell that to Nintendo.

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

[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

[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

[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.

So...

[mriya3]

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

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: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.

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. :)

Two great tastes

[FatherBusa]

Talk about gilding the lily!

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

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?

[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?

[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.

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.

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

[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!

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.

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?

Did you try it?

[Ron Harwood]

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

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?

[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

[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

[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.

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?

Re:On a phone?

[Xymor]

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

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.

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.

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.

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).

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.

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).

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

Re:Struggling to understand...

[7ex]

Because it's new!

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

[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

[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

[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...

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.

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.

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?

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.

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...

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?

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.

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.

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:lame description

[antiZ]

Cool stuff Joris! And the source is there too!

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.

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.

Re:On a phone?

[bWareiWare.co.uk]

And I claim to be God!

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

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.

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.

Java is like XML...

[Schraegstrichpunkt]

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