Love that you got Caesar 3 to run so nicely. I've been trying a game [Fritz 2] where the mouse is perfect only on the lower half of the screen using the same .jar file you use for C3. Is there a mouse setting that I'm unaware of to make it function better? I can post a link to show you if needed.

I too was surprised at how well Caesar 3 worked. I would be surprised if any other game ran. Age of Empires gets pretty close. My initial goal was Diablo 2 but it turns out that it uses dialog templates for the main menus which would require a ton of work. Currently I'm researching what it would take to port wine to dosbox. I have gotten core WINE dll's to compile and I have started running them. I'm to the point where I need to figure out how to handle the wine server.

I am glad to see that you have not given up on this. I am very interested in the prospect of porting WINE to DOSBox. I think that this could be the best solution for the 9x games that refuse to run on modern Windows and non Windows platforms.

but wine is not a emulator (it would only run on 86x[-64])

Porting wine to run in DOS or DOSBox's DOS, would be a monsterous task. Wine is not a full OS in itself. It needs an underlying OS that handles the multitasking for it. Not only that, but Wine has a huge amount of dependencies that you would also need to port to DOS. Your best bet, is just to stick to other virtual machines (Qemu or VirtualBox), or check out ReactOS (that one is more NT than Win9x).

Yeah, it is a big project. But I already have limited experience getting the java port of dosbox to run windows code. I'm sure my thread scheduler wasn't perfect, but it did run and create new processes and threads. The hard part is debugging the code. Right now I'm porting wine to run on windows so that I can use visual studio to line debug the code. I only recently discovered that it appears that I won't be able to set the fs selector so either I have to write a kernel driver for that or find a work around. I will probably just put the WINE TEB in a Windows TLS. This will probably prevent many programming from running on WINE under windows, but it might be enough for me to continue debugging my linux abstraction layer.

I started a new project for this so that I could track my changes to WINE at http://sourceforge.net/projects/boxedwine/ Currently it will compile several WINE dll's in a Visual Studio 10 project but it doesn't not run anything.

Of course there are a lot of huge hurdles to overcome, but as a proof of concept I would hope to have a "hello world" win32 app running sometime in the near term. I don't have as much free time for this as I would like so who knows how long this will take.

As for why I am doing this when you can just load linux in a VM and run WINE on that, I guess my only answer is because its an interesting challenge.

Currently my challenges to getting "Hello World" working on windows is

1) FS selector
2) WINE server (building and communicating with)

Future challenges to getting "Hello World" working in dos box

1) Need to figure out if the linux abstraction layer will be build into Dosbox like I did with the Win32 code of jDosbox or written as a stand alone 32-bit dos program (maybe leverage hx dos extender).
2) Long file name support

Should probably move the DOS/Windows Wine port to a new thread.

It is awesome to see someone attempt porting Wine. I hope to hear more on your progress.

Just so you know, one of the things you will run into is display driver stuff. I know for a fact that Alexandre Julliard is currently making it possible for Wine to support multiple display drivers (such as Quartz and Wayland). The first step is separating all the dependencies on X. Not an easy task, but progress is being made there. That and the recent DIB engine work, will help make your port very possible.

FYI, I work at CodeWeavers.

laxdragon: I think for the time being we can keep this discussion here. I will most likely code the wine loader in java since I already have most of the code there from previous work.

Thanks for the info on the driver. When I get to that point I will be sure to look at the latest WINE code. For now that seems like a long ways off.

I'm hoping the X stuff won't be too bad. I'm hoping I can take advantage of the WINE virtual desktop. Hopefully it does what I think it does where I will be able to draw all the Win32 windows inside a single frame buffer.

Just found this and it's awsome 😁 Just registered to thank you for your work, and although porting WINE is very cool, I hope you keep improving jDosbox.

collector wrote:

I am glad to see that you have not given up on this. I am very interested in the prospect of porting WINE to DOSBox. I think that this could be the best solution for the 9x games that refuse to run on modern Windows and non Windows platforms.

Isn't it easier to just port Wine to different OSes like it is done now? So for example port it to winxp/7 so that it properly works. And even when Wine is working under Linux is it at all useful for playing win9x games?

You would still have the problem of 16-bit games on x64.

Hi 😀

Is the java port of dosbox still a work in progress? Site has been updated "only" in Feb. 2, 2012... The thing I'm most interested at the moment is:

Implement Dosbox keymapper

I can't even make "c:" with my portuguese keyboard 😖 have to put it in the autoexec section of the conf file...

Yes, I'm still alive, I've just been busy with new born twins 😀

Currently I'm getting back up to speed by porting back dosbox svn checkin into jDosbox. I have 131 to go. I expect that to take a few weeks.

I'm still interested in getting WINE to work on jDosbox, but even if I continue with that it will be a long ways off. Its more of a hobby, I'm curious about the WINE architecture.

I haven't forgotten about the keyboard mapper. I would like to make an updated release this year before Christmas since I noticed a lot of the svn checkins I'm porting improve game compatibility, perhaps I will try to sneak in the keymapper into that release.

Running jDosBox as an applet on Java 1.7.0_07 gives this error, any chance anyone knows what's wrong ?

1Java Exception in thread "Thread-16" java.lang.IllegalAccessError: class com.sun.media.sound.AbstractPlayer cannot access its superclass com.sun.media.sound.AbstractMidiDevice
2	at java.lang.ClassLoader.defineClass1(Native Method)
3	at java.lang.ClassLoader.defineClass(Unknown Source)
4	at java.security.SecureClassLoader.defineClass(Unknown Source)
5	at java.net.URLClassLoader.defineClass(Unknown Source)
6	at java.net.URLClassLoader.access$100(Unknown Source)
7	at java.net.URLClassLoader$1.run(Unknown Source)
8	at java.net.URLClassLoader$1.run(Unknown Source)
9	at java.security.AccessController.doPrivileged(Native Method)
10	at java.net.URLClassLoader.findClass(Unknown Source)
11	at java.lang.ClassLoader.loadClass(Unknown Source)
12	at java.lang.ClassLoader.loadClass(Unknown Source)
13	at java.lang.ClassLoader.defineClass1(Native Method)
14	at java.lang.ClassLoader.defineClass(Unknown Source)
15	at java.security.SecureClassLoader.defineClass(Unknown Source)
16	at java.net.URLClassLoader.defineClass(Unknown Source)
17	at java.net.URLClassLoader.access$100(Unknown Source)
18	at java.net.URLClassLoader$1.run(Unknown Source)
19	at java.net.URLClassLoader$1.run(Unknown Source)
20	at java.security.AccessController.doPrivileged(Native Method)
21	at java.net.URLClassLoader.findClass(Unknown Source)
22	at java.lang.ClassLoader.loadClass(Unknown Source)
23	at java.lang.ClassLoader.loadClass(Unknown Source)
24	at com.sun.media.sound.MixerSequencerProvider.getDeviceInfo(MixerSequencerProvider.java:28)
25	at javax.sound.midi.MidiSystem.getMidiDeviceInfo(Unknown Source)
26	at jdos.gui.Midi.<init>(Midi.java:149)
27	at jdos.gui.Midi$2.call(Midi.java:243)
28	at jdos.misc.setup.Section.ExecuteInit(Section.java:47)
29	at jdos.misc.setup.Section.ExecuteInit(Section.java:42)
30	at jdos.misc.setup.Config.Init(Config.java:87)
31	at jdos.gui.Main.main(Main.java:952)
32	at jdos.gui.MainApplet.run(MainApplet.java:227)
33	at java.lang.Thread.run(Unknown Source)

Update:

Looked into the code in Midi.java and found out what triggers it:

1MidiDevice.Info[] devices = MidiSystem.getMidiDeviceInfo();

Still don't know how to fix it...

I wonder if permissions changed with unsigned applets in Java 7. Could you try self signing and see if it helps?

Here is an example of how to sign, you will need to change the paths and it assume you use "jdosbox" as the password.

1IF NOT EXIST myKeyStore "c:\Program Files\Java\jdk1.6.0_25\bin\keytool" -genkey -alias jdosbox -keystore myKeyStore
2"c:\Program Files\Java\jdk1.6.0_25\bin\jarsigner.exe" -keystore myKeyStore -storepass jdosbox -keypass jdosbox jdosbox.jar jdosbox

Self-signed applets have the same problem.
Could this => http://download.java.net/jdk8/docs/technotes/ … ncements_7.html
be the problem for triggering error on midi init ?

Update:

Commenting out code in Midi.java from line ~150

1MidiDevice.Info[] devices = MidiSystem.getMidiDeviceInfo();

until the end of the constructor solves the error and the Midi still works.
What is that code used for anyway ?

That was interesting to see the changes at that link. I tested in on 32-bit java 7 update 7 on Win 7 x64 and MidiSystem.getMidiDeviceInfo() returned one device with the name Gervill, so it appears to work for me. I tested on a self signed app on firefox and as a stand alone app.

I wonder what is different about your system. Have you tested it as a stand alone app? What browser were you using? What OS?

Standalone app works without problems, just applets give this error, signed or not signed makes no difference.

I'm using Firefox 15.0.1 on Win 8 x64 with 32-bit Java Plugin - JRE version 1.7.0_07-b11 (Java 7 update 7)

Update:

I finally found out what happend.

Do not install this => http://www.oracle.com/technetwork/java/javase … oad-142937.html
It will mess with the Midi stuff.

0.74.26 beta

Please test if this unsigned jdosbox applet works in full screen.

To go into full screen:

1) Press and hold right-alt key
2) While continuing to hold the right-alt key hit the enter key.

Hopefully this key combination should work the same as in Dosbox.

If full screen doesn't work, or it doesn't fill the entire screen please let me know:

1) OS type and version
2) Browser type and version
3) Java version including update revision

http://jdosbox.sourceforge.net/beta/74.26.3/doom.html

ZaDarkSide: If you didn't uninstall JMF could you try this beta. I added more try/catch's around the midi stuff, so hopefully it will no longer crash. The worst that should happen now is that midi would be disabled.

If anyone wants to do additional test on this beta feel free. It includes:

1) Up to date on Dosbox SVN changes
2) GUS support (ported by Kevin O'Dwyer)
3) The recompiler is about 50% faster. Doom -timedeom demo1 yields about 2300 on my Core i7 920 whereas Dosbox gets about 900.
4) Keymapper code has been implemented, but the gui to change the values has not, so full screen toggle, cpu cycles inc/dec and pause key combinations should now work.

Well, first I have to say my German keyboard (like all German keyboards) has no "Right Alt" key as such - so I tried AltGr+Enter instead. The game (which had been running very well in its window before I did that) freezed immediately without going full-screen.

My system is a Core2Quad running at 2.83 GHz with 4 gigs of RAM, Asus P5B mainboard, and a GTX 260 GPU.

My OS is Ubuntu Linux 12.10 (Quantal) amd64 Beta 2, fully updated to newest packages just an hour ago.

uname -a gives: Linux tearex 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

java -version gives: java version "1.7.0_07" OpenJDK Runtime Environment (IcedTea7 2.3.2) (7u7-2.3.2a-1ubuntu1) OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode).

firefox -version gives: Mozilla Firefox 16.0.1, and the about: page says Build identifier: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:16.0) Gecko/20100101 Firefox/16.0.

Thanks for your great effort at this!

EDIT: My computer has no speakers connected at this moment, so I can't say if sound worked or not.