×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Java-Based x86 Emulator

kdawson posted about 7 years ago | from the DOS-you-say dept.

Java 263

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.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

263 comments

Interesting, but (5, Funny)

dreamchaser (49529) | about 7 years ago | (#18473349)

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 (5, Interesting)

Qwertie (797303) | about 7 years ago | (#18473419)

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.

can you run java in the x86? (5, Interesting)

leuk_he (194174) | about 7 years ago | (#18473611)

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? (2, Informative)

faragon (789704) | about 7 years ago | (#18473827)

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

Re:can you run java in the x86? (4, Funny)

Citizen of Earth (569446) | about 7 years ago | (#18473933)

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:Interesting, but (3, Insightful)

chorltonian (887201) | about 7 years ago | (#18473739)

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 (5, Funny)

shaitand (626655) | about 7 years ago | (#18474091)

'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 (2, Interesting)

Citizen of Earth (569446) | about 7 years ago | (#18474105)

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 (1)

void_bips(brain) (929252) | about 7 years ago | (#18473879)

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 (1, Informative)

Anonymous Coward | about 7 years ago | (#18474373)

"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 (-1, Offtopic)

Anonymous Coward | about 7 years ago | (#18473507)

I just ran it on my COMPUTER and it made BOCHS seem slow in COMPARISON. So you are wrong THERE, and if I catch you or your friends playing NEAR by bins AGAIN I will be calling your PARENTS.

gee whiz (0)

Anonymous Coward | about 7 years ago | (#18473579)

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

Re:Interesting, but (1)

Wesley Felter (138342) | about 7 years ago | (#18474345)

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.

On a phone? (1, Troll)

pap3rw8 (962737) | about 7 years ago | (#18473353)

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

I'm amazed that no one asked yet (0)

Anonymous Coward | about 7 years ago | (#18474135)

but does it run linux? does it eventually??

Ah, a Java-based x86 emulator... (-1, Redundant)

R.Mo_Robert (737913) | about 7 years ago | (#18473355)

...because emulation isn't already slow enough. :) Haha, just kidding, I know Java really isn't that bad anymore, and I do understand the reasons they chose the language. I just had to say it...

Re:Ah, a Java-based x86 emulator... (2, Informative)

gravis777 (123605) | about 7 years ago | (#18473675)

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?

Lemmings without a mouse (1)

tepples (727027) | about 7 years ago | (#18473761)

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 (1)

gravis777 (123605) | about 7 years ago | (#18474343)

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.

Why Java ? (1)

DrYak (748999) | about 7 years ago | (#18474337)

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 ?

Struggling to understand... (0)

Anonymous Coward | about 7 years ago | (#18473367)

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

Re:Struggling to understand... (1)

dreamchaser (49529) | about 7 years ago | (#18473381)

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

Anonymous Coward | about 7 years ago | (#18473425)

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... (2, Interesting)

alexj33 (968322) | about 7 years ago | (#18473567)

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... (1, Interesting)

Anonymous Coward | about 7 years ago | (#18474459)

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

Anonymous Coward | about 7 years ago | (#18473663)

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

So... (5, Funny)

mriya3 (803189) | about 7 years ago | (#18473369)

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

Re:So... (1)

alexj33 (968322) | about 7 years ago | (#18473483)

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

eclectro (227083) | about 7 years ago | (#18473665)

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

shaitand (626655) | about 7 years ago | (#18474129)

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

How's the efficiency? (2, Interesting)

lbft (950835) | about 7 years ago | (#18473417)

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? (1, Funny)

Anonymous Coward | about 7 years ago | (#18473471)

two words: minesweeper

Well for one (5, Interesting)

brunes69 (86786) | about 7 years ago | (#18473479)

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 (2, Interesting)

EvilIdler (21087) | about 7 years ago | (#18473557)

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 (5, Informative)

daeg (828071) | about 7 years ago | (#18473613)

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 (2, Interesting)

jimmydevice (699057) | about 7 years ago | (#18474125)

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 (1)

Threni (635302) | about 7 years ago | (#18474333)

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 (1)

VGPowerlord (621254) | about 7 years ago | (#18474429)

Eclipse and NetBeans are both written in Java, albeit with different GUI toolkits. Eclipse uses SWT [eclipse.org], while NetBeans uses Swing [sun.com].

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 (1)

caseih (160668) | about 7 years ago | (#18473907)

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:How's the efficiency? (2, Insightful)

sumdumass (711423) | about 7 years ago | (#18473559)

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? (4, Insightful)

slamb (119285) | about 7 years ago | (#18473695)

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? (1)

shaitand (626655) | about 7 years ago | (#18474179)

'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? (2, Interesting)

Gromius (677157) | about 7 years ago | (#18473855)

Actually I think it is for general purpose code. In fact I think its main purpose is for running general code on the grid [wikipedia.org] 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 :)

Comparisons to other emulators? (0)

Anonymous Coward | about 7 years ago | (#18473427)

How does it compare to Qemu [bellard.free.fr] or Bochs [sourceforge.net], both open-source x86 emulators?

Re:Comparisons to other emulators? (2, Insightful)

dreamchaser (49529) | about 7 years ago | (#18473453)

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? (3, Funny)

badfish99 (826052) | about 7 years ago | (#18473691)

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? (1)

bluefoxlucid (723572) | about 7 years ago | (#18473743)

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? (0, Flamebait)

pjt33 (739471) | about 7 years ago | (#18474445)

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.

Re:Comparisons to other emulators? (1)

bluefoxlucid (723572) | about 7 years ago | (#18473699)

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.

What's wrong with virtualisation? (0, Flamebait)

pdbaby (609052) | about 7 years ago | (#18473435)

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 (4, Funny)

christurkel (520220) | about 7 years ago | (#18473437)

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

Java isn't really slow... (1)

Belial6 (794905) | about 7 years ago | (#18473723)

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

Anonymous Coward | about 7 years ago | (#18473875)

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.

So it runs DOS eh? (4, Funny)

ookabooka (731013) | about 7 years ago | (#18473441)

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? (0)

Anonymous Coward | about 7 years ago | (#18473779)

beowulf

Re:So it runs DOS eh? (0)

Anonymous Coward | about 7 years ago | (#18473807)

In Soviet Russia, DOS runs Java.

Re:So it runs DOS eh? (1)

muftak (636261) | about 7 years ago | (#18474145)

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? (1)

terom (1077107) | about 7 years ago | (#18474261)

But can it run Linux...?

Based on the table at the bottom of this page [ox.ac.uk], 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?

java me is not java se (1)

Billly Gates (198444) | about 7 years ago | (#18473443)

It will take some work to port.

But still cool though.

Re:java me is not java se (1)

pjt33 (739471) | about 7 years ago | (#18473809)

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? (2, Insightful)

CTho9305 (264265) | about 7 years ago | (#18473445)

I was playing around with DEBUG.COM and ran "OUT 20, AX"...and now it's apparently dead [ctho.ath.cx]. 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? (1)

ScrewMaster (602015) | about 7 years ago | (#18473577)

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? (1, Funny)

Eudial (590661) | about 7 years ago | (#18474107)

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.

on a good Java runtime... (2, Insightful)

dshk (838175) | about 7 years ago | (#18473499)

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

alphamugwump (918799) | about 7 years ago | (#18474137)

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.

The mythical "good Java runtime". (0)

Anonymous Coward | about 7 years ago | (#18474431)

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.

Applications (0)

Anonymous Coward | about 7 years ago | (#18473535)

"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/ [theregister.co.uk]

Commander Keen! (1)

IICV (652597) | about 7 years ago | (#18473545)

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! (1)

digitig (1056110) | about 7 years ago | (#18473803)

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! (1)

BiggyP (466507) | about 7 years ago | (#18474247)

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.

Can I conclude: Survive /. effect = robust (0)

Anonymous Coward | about 7 years ago | (#18473555)

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 (2, Insightful)

animaal (183055) | about 7 years ago | (#18473771)

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 (0)

Anonymous Coward | about 7 years ago | (#18473841)

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.

Java isn't slow anymore (1, Interesting)

Ranx (28829) | about 7 years ago | (#18473619)

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.

Compared to what? (2, Insightful)

alienmole (15522) | about 7 years ago | (#18473773)

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:Java isn't slow anymore (0)

Anonymous Coward | about 7 years ago | (#18473949)

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.

Keyboard Layout change hangs (1)

jawtheshark (198669) | about 7 years ago | (#18473735)

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.

Other projects doing the same/faster thing.. (3, Informative)

Boj (313432) | about 7 years ago | (#18473845)

There are at least 2 solutions doing a similar thing. The open source binarytranslator.org/PearColator offers x86 and PowerPC emulation:
http://binarytranslator.org/ [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 [uci.edu]
which appears not to be publicly available.

My intepretation (4, Funny)

Excelcia (906188) | about 7 years ago | (#18473877)

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.

license (1)

pmsyyz (23514) | about 7 years ago | (#18473917)

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

Re:license (2, Insightful)

mohjlir (553108) | about 7 years ago | (#18474339)

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.

Obligatory... (0)

Anonymous Coward | about 7 years ago | (#18473941)

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.

Why not Simics? (2, Informative)

Anonymous Coward | about 7 years ago | (#18474215)

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?

I tried the demo, but it didn't work (1)

Master of Transhuman (597628) | about 7 years ago | (#18474283)

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.

Java is fine for emulation (1)

tezza (539307) | about 7 years ago | (#18474427)

[1995] When I was at university [unsw.edu.au] on Java 1.0, we were taught operating systems on emulated Minix [minix3.org]. 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.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...