moving this to [freedos-devel]

Bret,


> This actually sounds similar to a problem I was having with
> FreeDOS, which I needed to work around in my programs.  In my case,
> the problem is actually with how FreeDOS allocates memory.  I don't
> know for sure if this is the same thing or not, but it could be related.

> In my particular case, the problem occurs when I try to install a
> TSR in CONFIG.SYS using the INSTALL= option.  FreeDOS installs its
> code, including the code it needs to return to when it's done
> "installing" my TSR, at the top of conventional memory.  In and of
> itself this is not a problem.  But, the memory that the FreeDOS
> kernel uses is simply used without actually being allocated (there
> is no MCB to prevent other programs from trying to use the same memory).

as an experiment, I used

  install=\FREEDOS\MEM.EXE /F

and this shows (beyond other blocks)

segment   size                  type
    ...      ...                   ...
    99e0    24032                 free

which is (or at least should be) the freedos kernel install code.

can you reproduce this, or are you using a different kernel?


> My programs intentionally use the upper end of conventional memory
> themselves (part of the process they use to minimize memory use).

nothing wrong with that, but already in use by the freedos init code
(and i my opinion protected by an MCB).
if this would work, it would leave (for freedos kernel) a 24K
unused hole at 99e0:0


> The result is that my programs clobber the memory that the kernel
> was using, and everything crashes when my program exits.  The root
> cause is a bug in the FreeDOS kernel (not always allocating memory
> with an MCB like it should), not with my programs.  My programs are
> able to detect the problem and "work around" it.  AFAIK, this only
> occurs in FreeDOS and not any others (at least not MS-DOS or PC-DOS).

> Again, I don't know if this is actually related or not, but it sounds like it 
> could be.

as Jeremy already pointed out, it's similar, but unrelated.

the conflict with SHELL arises because COMMAND.COM is using the upper
end of memory for it's environment, where it is trahed by SHELL.EXE.

Tom


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Reply via email to