Hi Wine-devel
My name is Morten and I would like for some of my old DOS/WIN95 games to work with wine. :)
I know that I most likely could solve this by using DOSbox and/or DOSemu. But I don't consider either of them user friendly in it's raw form. And I hope in the future it could be more of a Go to this menu item, click a few choices and then play game thing.
So I have been looking into what one of them is needing (XCOM Apocalypse).
The first thing that needs work is the VGA screen driver. The game needs one of the unsupported video modes. After looking further into it, I can see that the current screen driver, needs to be more of an emulator than just a copy of the framebuffer/RAM window to/from the DirectDraw surface.
But since I need to do a lot rewrite of the code, to get a emulator into things, I would of course like to test all the stuff that I don't touch (in term of videomodes). But there isn't a test catalog in dlls/krnl386.exe16. That could of course be due to the fact that it is pretty hard to write test for that old platform and get proper test on a live version. Or am I missing something here?
Looking over the list of videomodes, I can see that a lot of them says supported. Is that really true or do they simply not break? Again is there anyway to test that those modes are truely supported in my code change (and in the current code)?
Another problem that I am facing at a later stage is that most of the games needs to be installed in win95 mode. But I think that most people will run with something like XP, Vista or Win7 as default mode. That will break most of the old installers as DOS version becomes 5.0 or something "silly" like that. So I am thinking about having to create a wrapper program where you can install your old programs through so the mode gets set correctly during install. And perhaps also creates some proper shortcuts in the menu. And perhaps even into the new game database that new windows version have. And thoughts/ideas on this?
Another way to handle this would be to do something like a MD5 on the install.exe (hoping that they differ) and then look up in the AppDB, to see which mode to use as installer mode (and run mode). Yes, that would most likely require changes to AppDB. But I can see a use for this even for the above wrapper program (Autodetect using AppDB).
Once I get a new VGA "driver" running, I will most likely start looking into INT10h and others that try to interface to the VGA "driver".
Best Regards Morten Rønne
On Thu, Apr 1, 2010 at 10:17 AM, Morten Rønne morten.roenne@tdcadsl.dk wrote:
Hi Wine-devel
My name is Morten and I would like for some of my old DOS/WIN95 games to work with wine. :)
I know that I most likely could solve this by using DOSbox and/or DOSemu. But I don't consider either of them user friendly in it's raw form. And I hope in the future it could be more of a Go to this menu item, click a few choices and then play game thing.
So I have been looking into what one of them is needing (XCOM Apocalypse).
The first thing that needs work is the VGA screen driver. The game needs one of the unsupported video modes. After looking further into it, I can see that the current screen driver, needs to be more of an emulator than just a copy of the framebuffer/RAM window to/from the DirectDraw surface.
But since I need to do a lot rewrite of the code, to get a emulator into things, I would of course like to test all the stuff that I don't touch (in term of videomodes). But there isn't a test catalog in dlls/krnl386.exe16. That could of course be due to the fact that it is pretty hard to write test for that old platform and get proper test on a live version. Or am I missing something here?
Looking over the list of videomodes, I can see that a lot of them says supported. Is that really true or do they simply not break? Again is there anyway to test that those modes are truely supported in my code change (and in the current code)?
Another problem that I am facing at a later stage is that most of the games needs to be installed in win95 mode. But I think that most people will run with something like XP, Vista or Win7 as default mode. That will break most of the old installers as DOS version becomes 5.0 or something "silly" like that. So I am thinking about having to create a wrapper program where you can install your old programs through so the mode gets set correctly during install. And perhaps also creates some proper shortcuts in the menu. And perhaps even into the new game database that new windows version have. And thoughts/ideas on this?
Another way to handle this would be to do something like a MD5 on the install.exe (hoping that they differ) and then look up in the AppDB, to see which mode to use as installer mode (and run mode). Yes, that would most likely require changes to AppDB. But I can see a use for this even for the above wrapper program (Autodetect using AppDB).
Once I get a new VGA "driver" running, I will most likely start looking into INT10h and others that try to interface to the VGA "driver".
Best Regards Morten Rønne
Hi Morten,
First of all welcome to Wine. Myself I'm a bit worried about whether we should improve our DOS support even further. The problem is that more and more people are moving over to 64-bit Linux. While you can run 32-bit programs on a 64-bit system, there is no protected mode support (vm86; there is emulation in some cases using a kernel module). I don't know all the details about what works and not but I fear the 64-bit move makes DOS support in Wine not that useful these days but I might be wrong.
Roderick
Am 01.04.2010 um 11:24 schrieb Roderick Colenbrander:
First of all welcome to Wine. Myself I'm a bit worried about whether we should improve our DOS support even further. The problem is that more and more people are moving over to 64-bit Linux. While you can run 32-bit programs on a 64-bit system, there is no protected mode support (vm86; there is emulation in some cases using a kernel module).
There's protected mode 32 bit, protected mode 16 bit, but no vm86 16 bit. So no real mode apps in Wine. We'd need to integrate a CPU emulator or JIT compiler into Wine to get this working.
There are a surprising big number of Win95 area apps that have an installer that starts off in vm86 mode...
Stefan Dösinger wrote:
Am 01.04.2010 um 11:24 schrieb Roderick Colenbrander:
First of all welcome to Wine. Myself I'm a bit worried about whether we should improve our DOS support even further. The problem is that more and more people are moving over to 64-bit Linux. While you can run 32-bit programs on a 64-bit system, there is no protected mode support (vm86; there is emulation in some cases using a kernel module).
There's protected mode 32 bit, protected mode 16 bit, but no vm86 16 bit. So no real mode apps in Wine. We'd need to integrate a CPU emulator or JIT compiler into Wine to get this working.
Security people would love that! That way Wine won't ever need to be able to mmap address 0x00000000.
There are a surprising big number of Win95 area apps that have an installer that starts off in vm86 mode...
bye michael
* On Thu, 1 Apr 2010, Stefan Dösinger wrote:
Am 01.04.2010 um 11:24 schrieb Roderick Colenbrander:
Myself I'm a bit worried about whether we should improve our DOS support even further. The problem is that more and more people are moving over to 64-bit Linux. While you can run 32-bit programs on a 64-bit system, there is no protected mode support (vm86; there is emulation in some cases using a kernel module).
There's protected mode 32 bit, protected mode 16 bit, but no vm86 16 bit. So no real mode apps in Wine. We'd need to integrate a CPU emulator or JIT compiler into Wine to get this working.
DOSBox does something like this already. I lack ideas about to what extent DOSBox could be integrated, but at least its CPU emulator could do. Or maybe DOSBox could even be bridged/integrated and do all the DOS stuff here?
Then IIRC there were discussions in the past about integrating Qemu into Wine. Some folks at Darwine have achieved this to some degree: [1]
That probably won't fly directly [2] but some aspects of the design of an emulator integration can be investigated already, IMHO.
S.
[1] http://darwine.sourceforge.net/docs/dev-doc.xml [2] http://wiki.winehq.org/FAQ#head-5804ec2bb090feaf81f572993444efd8ec2a8569
On Thu, Apr 1, 2010 at 8:20 PM, Saulius Krasuckas saulius2@ar.fi.lt wrote:
- On Thu, 1 Apr 2010, Stefan Dösinger wrote:
Am 01.04.2010 um 11:24 schrieb Roderick Colenbrander:
Myself I'm a bit worried about whether we should improve our DOS support even further. The problem is that more and more people are moving over to 64-bit Linux. While you can run 32-bit programs on a 64-bit system, there is no protected mode support (vm86; there is emulation in some cases using a kernel module).
There's protected mode 32 bit, protected mode 16 bit, but no vm86 16 bit. So no real mode apps in Wine. We'd need to integrate a CPU emulator or JIT compiler into Wine to get this working.
DOSBox does something like this already. I lack ideas about to what extent DOSBox could be integrated, but at least its CPU emulator could do. Or maybe DOSBox could even be bridged/integrated and do all the DOS stuff here?
Then IIRC there were discussions in the past about integrating Qemu into Wine. Some folks at Darwine have achieved this to some degree: [1]
That probably won't fly directly [2] but some aspects of the design of an emulator integration can be investigated already, IMHO.
S.
[1] http://darwine.sourceforge.net/docs/dev-doc.xml [2] http://wiki.winehq.org/FAQ#head-5804ec2bb090feaf81f572993444efd8ec2a8569
AFAIK we can't integrate with DOSBox, Dosemu or FreeDOS for the same reason we can't integrate with Samba: their GPL licence.
QEMU's CPU core library however is LGPL (http://wiki.qemu.org/License) just like Wine - but in my experience QEMU is very slow when it does full emulation.
Damjan
* On Fri, 2 Apr 2010, Damjan Jovanovic wrote:
On Thu, Apr 1, 2010 at 8:20 PM, Saulius Krasuckas saulius2@ar.fi.lt wrote:
- On Thu, 1 Apr 2010, Stefan Dösinger wrote:
There's protected mode 32 bit, protected mode 16 bit, but no vm86 16 bit. So no real mode apps in Wine. We'd need to integrate a CPU emulator or JIT compiler into Wine to get this working.
DOSBox does something like this already. I lack ideas about to what extent DOSBox could be integrated, but at least its CPU emulator could do. Or maybe DOSBox could even be bridged/integrated and do all the DOS stuff here?
Then IIRC there were discussions in the past about integrating Qemu into Wine. Some folks at Darwine have achieved this to some degree: [1]
AFAIK we can't integrate with DOSBox, Dosemu or FreeDOS for the same reason we can't integrate with Samba: their GPL licence.
I am profane at licensing, but does GPL restrict even usage of binary (linking, execution), or only a compilation of source code?
in my experience QEMU is very slow when it does full emulation.
Should not be slower that eg. BOCHS.
S.
On Fri, Apr 2, 2010 at 1:42 PM, Saulius Krasuckas saulius2@ar.fi.lt wrote:
- On Fri, 2 Apr 2010, Damjan Jovanovic wrote:
On Thu, Apr 1, 2010 at 8:20 PM, Saulius Krasuckas saulius2@ar.fi.lt wrote:
- On Thu, 1 Apr 2010, Stefan Dösinger wrote:
There's protected mode 32 bit, protected mode 16 bit, but no vm86 16 bit. So no real mode apps in Wine. We'd need to integrate a CPU emulator or JIT compiler into Wine to get this working.
DOSBox does something like this already. I lack ideas about to what extent DOSBox could be integrated, but at least its CPU emulator could do. Or maybe DOSBox could even be bridged/integrated and do all the DOS stuff here?
Then IIRC there were discussions in the past about integrating Qemu into Wine. Some folks at Darwine have achieved this to some degree: [1]
AFAIK we can't integrate with DOSBox, Dosemu or FreeDOS for the same reason we can't integrate with Samba: their GPL licence.
I am profane at licensing, but does GPL restrict even usage of binary (linking, execution), or only a compilation of source code?
I'm not a lawyer, but my understanding of the license is that you cannot in general link to GPL code without making the whole binary fall under GPL. The LGPL allows a program to link to it without affecting the license of the program, though.
You can however have your non-GPL code execute a separate GPL binary without affecting the legal state of your own code. The important part is that the programs are kept separate.
/Johan Gill
On Thu, Apr 1, 2010 at 4:47 PM, Stefan Dösinger stefandoesinger@gmx.at wrote:
Am 01.04.2010 um 11:24 schrieb Roderick Colenbrander:
First of all welcome to Wine. Myself I'm a bit worried about whether we should improve our DOS support even further. The problem is that more and more people are moving over to 64-bit Linux. While you can run 32-bit programs on a 64-bit system, there is no protected mode support (vm86; there is emulation in some cases using a kernel module).
There's protected mode 32 bit, protected mode 16 bit, but no vm86 16 bit. So no real mode apps in Wine. We'd need to integrate a CPU emulator or JIT compiler into Wine to get this working.
There are a surprising big number of Win95 area apps that have an installer that starts off in vm86 mode...
Actually we don't need a CPU emulator for 64 bit after all. There's a project on Sourceforge that's gotten VM86 working in 64-bit Linux: http://v86-64.sourceforge.net/
It claims to work with Wine.
Damjan
-
Damjan Jovanovic -
Johan Gill -
Michael Stefaniuc -
Morten Rønne -
Roderick Colenbrander -
Saulius Krasuckas -
Stefan Dösinger