The new try / catch doesn't works because JMF overwrites some classes. I think it is not fixable, JMF is way to old anyway.
It's just an incompatibility with JMF that other people should be aware of.

Fullscreen works ok for me, but I need to hint some not well known features of applets:

Makes the applet draggable and detaches it from the browser window.
How to use: holding ALT click the applet and drag it.

1<param value="true" name="draggable">

Makes a separate JVM instance for each applet so multiple applets on one page can't affect each other.
If one applet crashes the JVM, the others will still work, also if the browser page with the applet gets closed, that immediately kills the JVM too.
Without this param the JVM will stay open a while and will close on it's own after some time, seems the default behavior is to keep the JVM open in case other applets will be loaded, even if you closed the page with the applet.

1<param value="true" name="separate_jvm">

If you can please add those params to your demo page, so other people can test them out.

Woooo!!! The fullscreen works perfect!!! 😁

One question. Its possible save the game status on a IMG disk?

Excellent work! Tested fullscreen mode in the unsigned applet... Not at home at the moment to confirm exact versions but, seems like works ok with sun java 1.6 and windows, having problems in any Linux machines I've tested :

Win 7 x86, Chromium Browser, Java 1.6 - Fullscreen works
Win 7 x86, Chromium Browser, Java 1.7 - No effect
Linux Debian Wheezy x86 , Chromium Browser, Java 1.6 - Applet freezes
Linux Debian Wheezy x64 , Chromium Browser, Java 1.6 - Applet freezes
Linux Debian Wheezy x86, Chromium Browser, Java 1.7 - Nothing happens

Desuque - With the unsigned applet, you can save your game, but the next time you visit the page, a fresh IMG is loaded so you have lost the save. However, theres a signed applet you can use which will allow you to save your game. the IMG file is downloaded to a hidden folder in your user directory on your computer, so you can resume save games the next time you play. You wont have these saved games when you connect from another computer though.

Thanks Largo! I can save the img file in localhost?

I found out when running jdosbox with 2 parameters it gives an extreme speed boost.
run on command line:
java -jar -Xms40m -Xmx384m jdosbox.jar

with this parameters i get ~67 Fps in PCPBench instead of ~46.
even Quake 1 is now playable (at the first 20 seconds it is laggy, but then it runs smooth. seems like a bug in current jdosbox)

now i want to use these 2 parameters within an applet but i can't figure it out how to do this.
<param name="java_arguments" value="-Xms40m -Xmx384m"> - does not work
i also tried with a .jnlp file and some other options but i always get about 46 Fps in Applet mode.

Anyone knows how to use these 2 parameters with an Applet?

divinity wrote:

even Quake 1 is now playable (at the first 20 seconds it is laggy, but then it runs smooth. seems like a bug in current jdosbox)

It could also be Java's JIT compiler that's kicking in.

divinity: Performance can be tricky. Here are some ideas:

1) The last beta I posted on this board is about 50% faster than the current release when using the recompiling dynamic core. If you are testing it as an applet make sure you are running the newest version and not a cached version.

2) There are 2 cores in the java version of dosbox, normal which is a pretty accurate reproduction of the c dosbox version and a dynamic one which is a modified version of the normal core, the jdosbox dynamic core has no relation to the c dosbox dynamic core. When the jar is running in standalone or signed applet mode the dynamic core can recompile itself into a more efficient form. This recompiling form is much faster but might explain the performance hit you see for the first few seconds since it takes time to do the recompiling (which takes places on another thread and thus will turn off your multi-core turbo mode that boosts a single core if only one thread is eating up the CPU).

3) In applet mode the default RAM size for dosbox is 8MB. So if you aren't using a custom dosbox.conf then the standalone version will use 16MB for RAM and the applet only 8MB. This would make a pretty big difference for games like Quakes.

As for using more memory in an applet, I haven't had much luck with those parameters either.

Let me know if you discover anything with .jnlp. I plan to start testing with that since there is no way with so little memory I will be able to get ReactOS to run well in an applet.

Here is an update since my last beta: I'm pretty sure I won't have a new official release before the end of the year. I got distracted with the dosbox-x patches and I kept adding more and more since then.

I have completed:

1) Ported PS/2 Mouses from Dosbox-X (but I need to work on sensitivity issues)
2) Ported QEMU's ide controller. It will boot CD's and DVD's.
3) Ported QEMU's floppy controller.
4) Found a bug in the way I ported part of the iret instruction from Dosbox which prevented NT 4.0 from starting
5) Support for some 686 instructions
6) Support for using Bochs bios

Now ReactOS and NT 4.0 work in VGA 16 color mode.

TODO:

1) To use more colors and higher resolutions for ReactOS I will need to impelement Video Bios Extension (VBE).
2) The NT 4.0 S3 driver did not like dosbox's implementation of the video card. It shows only a blank screen.
3) Fix PS/2 mouse sensitivity
4) More testing for the IDE and floppy controllers. I suspect they could use some performance improvements.
5) Finish work on the network card so that it will work with a pure Java implementation (no pcap libraries). This is a port of QEMU slirp code. This is a big project and may get pushed out to a future release.
6) Investigate the "cp: memory exhausted" error when booting JPC's linux demo.

Seems like memory must be enabled by the Web-Server.
http://stackoverflow.com/questions/8877370/ja … in-catalina-bat

My local server with Tomcat (catalina) does not find Java. Can't test it now.

Quote from another site:
I have this in my server's .profile:
export JAVA_OPTS="-Xmx768m -XX:PermSize=192m -XX:MaxPermSize=256m"

So put - export JAVA_OPTS="-Xms40m -Xmx384m" - into Servers .profile

There are many sites describing how to do this. It's depending on the server.
Maybe this could work.

Java applets are a client-local code delivery mechanism... why would the server jvm matter for anything?

Here is a demo showing off ReactOS. The performance isn't great, but it's an interesting achievement.

http://jdosbox.sourceforge.net/reactos/reactos.jnlp

1) It requires 256MB of JVM memory in order for ReactOS to use 64MB
2) It will copy the ReactOS disk image to your home directory (~/.jdosbox/reactos64kColor.img). On Windows this may be c:\users\<your name>\.jdosbox\reactos64kColor.img. It was 3x slower to load if I left the image in the jar file.
3) Double right click will release the mouse
4) Right-Alt + Enter to enter/exit full screen
5) Only 8/16/32 bit color at 800x600 and 1024x768 is supported. I am researching higher resolution and I have no plans for 24-bit color

Thanks for the new version danoon!

Very smooth, the performance is now really good. Especially the Windows 3.1 compatibility has improved. Finally the 64K Colors work without any artifacts for me in all resolutions.

I did some tests with 3D rendering appz for benchmarks and the speed sure improved. POVRAY is still a bit slow, but i think it's the 3.0.2 compile that is generally slower than usual. Also the only benchmark machine that uses 800x600 in 64K, WinS, swap space and 32-Bit disk access. For Truespace and Vue times have significantly improved.

If anyone elswanna see what i mean here are my benchmark machines:

Vue 1.2

http://www.renderarmy.com/vuenew.htm

Truespace 1.0

http://www.renderarmy.com/ts.htm

POVRay 3.0.2

http://www.renderarmy.com/povray.htm

Thanks fonzel for testing the new release. That was pretty cool to see povvray render in a browser. I see that you self signed jdosbox.jar so that the recompiler would work. If you self sign the other jar that contains the hard disk image you won't get that confusing 2nd dialog that asks you to hit "no".

Ah, good tip, imma try that. Well the jodbox.jar was signed by you since i blantantly stole it right from your reactos release, but i was simply so curious about the changes since reactos is already working like a charm with it. The 3D rendering is a nice benchmarking, especially POVRay 3.0.2, hehe. But POVRay is also damn slow in a "normal" x86 binary compiled dosbox. Compatibility is also generally great, since people from WIn xp over win7 to linux have tested it so far without any problems. I'm surprised how fast Vue 1.2 now renders, i could barely see any difference to the standard win32 dosbox here, just works super fast.

I hope that one day it will have network support included. I am aware that it comes with NE2000 support "somehow in combination with pcap", but i guess at least for the pcap part I am too dumb, never got that working.

Progress Update:

Windows XP now installs and runs in Safe Mode. On the Linux front, I'm still have problems with "cp: memory exhausted" on Ubuntu but DSL seems to works.

Here is a new demo, this it is running the live cd of Damn Small Linux (DSL). Keep in mind this will probably be pretty slow for you unless you have a pretty powerful computer.

http://jdosbox.sourceforge.net/dsl/dsl.jnlp

As before:

1) It requires 256MB of JVM memory in order for DSL to use 64MB
2) It will copy the DSL iso image to your home directory (~/.jdosbox/dls.iso). On Windows this may be c:\users\<your name>\.jdosbox\dsl.iso.
3) Double right click will release the mouse
4) Right-Alt + Enter to enter/exit full screen

Hi danoon,

nice work on the dsl demo.

Unfortunately something seems to have changed regarding memory? I used the same flags for my image as for the previous (React OS) built, but somehow my machine gets less memory and swap file.

A good demo is Lightwave 3D 4.0 which is a true memory hogger. Also it shows free physical and swap memory when you open a scene. I have made a nice image that runs fine on the "reacht OS Built", utilizing 32 MB RAM and 100 MB swap file in the virtual machine.

However, running the same image with your new "DSL built" Lightwave shows 0 KB RAM free and only 12 MB swap file left. Any ideas?

Here's the demo with ReactOS Built:

http://www.renderarmy.com/lw.htm

And here's the one with the DSL built:

http://www.renderarmy.com/lwdsl.htm

As you can see they both boot the same image but behave totally different.

Also i noted some distorted text in DOS during boot and "Program manager" turned into Prograb Manager" with kinda russian "b". Odd glitch, only had that at previous (pre ReactOS) builts with higher resolutions and color depth.

I fixed a bug with the reactos and dsl links. The program wasn't creating ~/.jdosbox if it didn't already exist which prevented the os's from booting up.

fronzel: In your first demo you had <param name="param1" value="-conf jar://dosbox.conf"> in the web page. On your second demo you forgot this which resulted in the applet only using 8MB which is the default RAM configuration for an applet

It has been too long since my last release. The problem is that there is always more to do in the code so I keep coding. I decided to just cut it off now so that I can get some testing and make sure there aren't too many regressions.

10.74.27 Jan 02, 2013
2* Added new hardware: IDE, Floppy and PS/2 Mouse
3* Now boots other OS's and from CD/DVD via one of the following boot commands
4  boot -bochs HD
5  boot -bochs CD
6  boot -bochs FD
7* Windows NT 4.0, React OS 0.3.14 and DSL 4 have been tested and work well
8* Windows XP will boot in Safe Mode
9* Many speed improvements
10* The FPU type can be set in the configuration file: [cpu] softfpu=true/false.  The default
11  is false and will use Java's float types for the x86 FPU
12* Right-Alt + Enter key will toggle full screen mode, works in applets as well
13* Add p6 CPU type in the configuration file.  This will enable some newer Linux distro to boot.

The new release is at http://sourceforge.net/projects/jdosbox/files … ox.jar/download

Feel free to test and report bugs here.

Amazing update! I get to play around with it and it works nicely well. Thank very much for that! 😉

One issue I'm facing currently is... booting qnx 4.25 demo disk.
It installs just fine.
When booting if you don't start photon (gui) it works.
When you start photon it works too, until the moment when you press some key on the keyboard, then it hangs and the console shows buffer full, dropping code.

And theres some issues with mouse over some games, it disappears everytime when it should change it's color or something like that.

I will get some logs soon anyway. 😉

lil_stenly and anyone else trying to run other OS's: Don't use any s3 video drivers, the dosbox s3 video card isn't a complete implementation or my port of it has bugs. Windows 95/98 is the only OS I saw that can use it. Instead use VGA or VBE.

lil_stenly, I'll have to try QNX, since I haven't tried mostly likely it may have exposed a bug.

I recently tried Tiny Core Linux which seems to work well. OS/2 dies very early, it tries to do something with the interrupt controller which hasn't been implemented yet.

And qnx4.25 demo disc is free but having hard times to find it because it is really old one.
ftp://ftp.rosnet.ru/pub/qnx/

QNX Install log: http://pastebin.com/v10y2NUy - work
QNX Firstrun log: http://pastebin.com/e4N7E7kx you should choose a graphic card without pressing anything on the keyboard, only mouse, then click to not start photon on every boot, the checkbox below and shutdown after that.
QNX Running log: http://pastebin.com/b0aDnGDH now without photon when login appears type root for name and press enter (keyboard works without starting the gui, then type ph to start photon and since you are logged in you will see the desktop, can play around the os without using the keyboard.
Screenshots: http://imgur.com/a/isLY3
😉