DOS memory Question..... or How to increase base memory for DOS apps

[Christian Costa]

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

[Dustin Navea]

--- Christian Costa <titan.costa(a)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

[Steven Edwards]

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

[Christian Costa]

> 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