> That could be related. How do you allocate the extra memory and
> where?
I manage memory using the standard INT 21.48, 49, & 4A. The segments sometimes
are installed in a UMB ad other times not, depending on the exact
circumstances. E.g., if UMB's are available and the CPU is in real mode, I
assume that something like UMBPCI is installed and the UMB's are probably
incompatible with DMA. Some of the segments need DMA and others don't, so some
may intentionally get installed in UMB's and others not.
I use INT 21.5801, 5802, 5803, & 5804 to manipulate exactly where the segment
ends up before I issue the INT 21.48.
I do relocate the installation program to the top of conventional memory and
run it from there. I've tried both just copying the program but leaving the
original in place (at the bottom of conventional memory), as well as relocating
and completely terminating the original process, and neither one works. I've
also tried with and without HIMEM(X) and (J)EMM, with the same results.
> Maybe JEMMEX has problems with fragmented memory, did you try
> JEMM386? The error itself does not tell much - GPF at a 64k segment
> boundary... Could mean that code jumped into an empty segment and
> fell of its end.
I've tried JEMMEX, HIMEMX+JEMM386, and MS HIMEM+EMM386. None of them help.
> While INSTALL differs from normal running of apps (as child tasks of
> SHELL) it should do so in the same way for different versions of DOS.
>
> In FreeDOS, you get - apart from a not complete PSP which is
> probably normal for all INSTALL situations anyway...:
Do you know exactly what is "incomplete" about the PSP?
> STATIC VOID InstallExec(struct instCmds *icmd)
> ...
> exb.exec.env_seg = 0;
> exb.exec.cmd_line = (CommandTail FAR *) args;
> exb.exec.fcb_1 = exb.exec.fcb_2 = (fcb FAR *) 0xfffffffful;
> ... init_DosExec(icmd->mode, &exb, filename) ...
> ...
>
> ...where AL = mode is either 0 or 0x80 for low / high install which is a
> non-standard use of
> the high bit of AL. A possible bug in FreeDOS could be:
>
> COUNT DosExec(COUNT mode, exec_blk FAR * ep, BYTE FAR * lp)
> ...
> if (mode == LOAD && rc == SUCCESS)
> fmemcpy(ep, &TempExeBlock, sizeof(exec_blk));
> ...
>
> This should probably use "if mode and 0x7f is load" instead?
> However, INSTALL does not use LOAD mode, it uses LOADNGO...
> And value LOAD_HIGH which is 0x80 is defined but never used.
>
> Other functions: DosExeLoader, DosComLoader, load_transfer...
>
> It might be possible that DosComLoader tries to give the COM all available
> memory and
> unless you specify otherwise when going TSR none is left for others, but
> thats just guessing.
It's a .COM, so all memory is allocated. As discussed above, it does get
resized (or else I couln't allocate any new segments in conventional memory).
> Is your TSR a COM or is it EXE?
COM
> Does it keep handles open?
Only while installing. If I exit as a TSR (INT 21.31), I close the handles
manually. If a normal exit (INT 21.4C), I let DOS handle it.
> Does it use environment variables or other PSP related data?
It does use enviroment variables, but only while installing. It does copy and
manipulate the original PSP data if it terminates the original process after
relocating, otherwise not.
> Does it make a difference whether to INSTALL or INSTALLHIGH?
No.
___
Bret
------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
