Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Java-Based x86 Emulator

Posted by kdawson on Sat Mar 24, 2007 04:05 PM
from the DOS-you-say dept.
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.
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • by dreamchaser (49529) on Saturday March 24 2007, @04:08PM (#18473349) Homepage Journal
    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 (Score:5, Interesting)

      by Qwertie (797303) on Saturday March 24 2007, @04:22PM (#18473419) Homepage
      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.
      • by leuk_he (194174) on Saturday March 24 2007, @04:47PM (#18473611) Homepage
        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.
      • 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: (Score:3, Insightful)

        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++.
        • by shaitand (626655) on Saturday March 24 2007, @05:56PM (#18474091) Homepage Journal
          '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: (Score:3, Insightful)

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

        • by Anonymous Coward on Saturday March 24 2007, @07:03PM (#18474485)
          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.
        • by MobyTurbo (537363) on Saturday March 24 2007, @07:42PM (#18474809)

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

          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.

    • It's not bad - admittedly it's running DOS - but Prince of Persia seems to run nicely.
  • So... (Score:5, Funny)

    by mriya3 (803189) on Saturday March 24 2007, @04:11PM (#18473369) Homepage
    ... now we should say: "x86 assembler: write once, run everywhere (slow as molasses in January)" ?
  • 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 wou
    • Well for one (Score:5, Interesting)

      by brunes69 (86786) <<gro.daetsriek> <ta> <todhsals>> on Saturday March 24 2007, @04:31PM (#18473479) Homepage
      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: (Score:3, Interesting)

        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 s
        • Re:Well for one (Score:5, Informative)

          by daeg (828071) on Saturday March 24 2007, @04:47PM (#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: (Score:3, Insightful)

      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 a
      • by slamb (119285) * on Saturday March 24 2007, @05:01PM (#18473695) Homepage

        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.

  • by christurkel (520220) on Saturday March 24 2007, @04:25PM (#18473437) Homepage Journal
    Java only: snail speed
    Java+DOS: Snail with ball and chain
    Java+DOS on non x86: Snail nailed to the table
  • by ookabooka (731013) on Saturday March 24 2007, @04:25PM (#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?
  • It will take some work to port.

    But still cool though.
  • by CTho9305 (264265) on Saturday March 24 2007, @04:25PM (#18473445) Homepage
    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?
  • 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.
  • by Boj (313432) on Saturday March 24 2007, @05:19PM (#18473845) Homepage
    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.
  • by Excelcia (906188) <kfitzner@excelcia.org> on Saturday March 24 2007, @05:24PM (#18473877) Homepage
    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.
    • 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: (Score:3, Insightful)

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

            An

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

      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 W
    • Re: (Score:3, Insightful)

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

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