Hi,
Many DOS apps needs a lot of base memory even if EMS or XMS memory are used.
The first 64K of memory being lock to catch null pointer, the DOS memory must start at 0x10000 as you can see in the code below (msdos/dosmem.c) :
/*********************************************************************** * DOSMEM_InfoBlock * * Gets the DOS memory info block. */ static dosmem_info *DOSMEM_InfoBlock(void) { return (dosmem_info*)(DOSMEM_dosmem+0x10000); /* 64K */ }
/*********************************************************************** * DOSMEM_InitMemory * * Initialises the DOS memory structures. */ static void DOSMEM_InitMemory(void) { /* Low 64Kb are reserved for DOS/BIOS so the useable area starts at * 1000:0000 and ends at 9FFF:FFEF. */
Changing this value to the end of the BIOS DATA area (0x500) does the job and things work as expected (at least for DOS apps). But I was told that this causes problems for others apps. Probably for Win16 ones that use DOS3CALL and not int21h via DPMI.
If it's true, a solution could be to initialize DOS memory differently for pure DOS apps by modifying the DOSMEM_Init function.
DOSMEM_Init is called at 3 different places : - process_attach in dlls/kernel/kernel_main.c - DOSVM_Init in dlls/winedos/dosvm.c - MZ_InitMemory in dlls/winedos.dosvm.c
and acts differently the first and second calls.
Since I don't know wine internals enough and the "flow of execution", I have no idea how to do it in a clean way that do not break everything.
If someone can help me or give me hints?
A+ Christian
--- Christian Costa titan.costa@wanadoo.fr wrote:
Hi,
Hi!
Many DOS apps needs a lot of base memory even if EMS or XMS memory are used.
The first 64K of memory being lock to catch null pointer, the DOS memory must start at 0x10000 as you can see in the code below (msdos/dosmem.c) :
-snip-
Changing this value to the end of the BIOS DATA area (0x500) does the job and things work as expected (at least for DOS apps). But I was told that this causes problems for others apps. Probably for Win16 ones that use DOS3CALL and not int21h via DPMI.
I don't know it if is possible, but if that is true, why not just emulate int21h calls when DOS3CALL is called when we are running a win16 app, and the rest of the time, leave everything be? Or better yet, why not change the value to the end of the bios data area only when we are running pure dos apps?
If it's true, a solution could be to initialize DOS memory differently for pure DOS apps by modifying the DOSMEM_Init function.
DOSMEM_Init is called at 3 different places :
- process_attach in dlls/kernel/kernel_main.c
- DOSVM_Init in dlls/winedos/dosvm.c
- MZ_InitMemory in dlls/winedos.dosvm.c
and acts differently the first and second calls.
Since I don't know wine internals enough and the "flow of execution", I have no idea how to do it in a clean way that do not break everything.
If someone can help me or give me hints?
Or you could do that, but there is no sure-fire way to do everything cleanly and even then, it may not fix every dos app, or even worse it could break some non-dos app in unforeseen ways... What is DOSEmu licensed under and is it actually open source? I'm wondering, maybe if it is under a compatible license and open source, couldn't we take the DOS3CALL or int21h routines (or at least parts of them) from there...
-Dustin
__________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
I belive this is what the TWIN project did for there x86/Win Emulation based on WINE. TWIN is LGPL and wine has never been able to use that code untill now.
-
do everything cleanly and even then, it may not fix every dos app, or even worse it could break some non-dos app in unforeseen ways... What is DOSEmu licensed under and is it actually open source? I'm wondering, maybe if it is under a compatible license and open source, couldn't we take the DOS3CALL or int21h routines (or at least parts of them) from there...
__________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
I don't know it if is possible, but if that is true, why not just emulate int21h calls when DOS3CALL is called when we are running a win16 app, and the rest of the time, leave everything be?
IIRC, int21h is based upon DOS3CALL except for some few parts which are only implemented in int 21h.
Or better yet, why not change the value to the end of the bios data area only when we are running pure dos apps?
I mentionned this in the post and I also think it's the best solution since only pure dos apps may need a lot of base memory.
Or you could do that, but there is no sure-fire way to do everything cleanly and even then, it may not fix every dos app, or even worse it could break some non-dos app in unforeseen ways...
Could you be more precise? What the problem(s) that may make things not work? Or what do the apps do we cannot handle?
What is DOSEmu licensed under and is it actually open source? I'm wondering, maybe if it is under a compatible license and open source, couldn't we take the DOS3CALL or int21h routines (or at least parts of them) from there...
Hum... Since the code already exists in WINE, I prefer understand it and enhanced it. I think, It will take much less time. ;-)
A+ Christian