Hi Bret, > I'm not 100% sure, but this could be (at least indirectly) related > to the issue I discovered several years ago, where FreeCOM uses > memory "illegally" while installing (processing CONFIG.SYS and/or > AUTOEXEC.BAT). That is, FreeCOM uses a lot of memory that's at the > top of conventional memory (just below the 640k point), but doesn't > actually allocate (and thereby "protect") the memory with a Memory > Control Block (MCB). As a result, any program that actually tries > to use that memory will crash the system since it doesn't know that > FreeCOM is already using it. In my case, I was requesting an MCB at > the top of conventional memory, and the kernel issued it to me even > though it shouldn't have because the memory was already being used > (by the kernel). Again, I don't know if this related to the > particular problem Matej is having, but it seems like it could be.
IIRC this problem was (is?) a kernel problem, that happens at INSTALL=ramdisk.exe processing (please confirm), not related to FreeCOM. INSTALL= processing is done by Kernel, not FreeCOM. this bug is fixed by moving DoInstall from main.c, line 128 - DoInstall(); kernel(); } to main.c, line 493: } DoInstall(); init_call_p_0(&Config); /* go execute process 0 (the shell) */ } Tom > ---------- Original Message ---------- > From: Bart Oldeman <bartolde...@gmail.com> > To: "Technical discussion and questions for FreeDOS developers." > <freedos-devel@lists.sourceforge.net> > Subject: Re: [Freedos-devel] FreeCOM 0.84-pre3 prerelease > Date: Mon, 5 Feb 2018 11:06:06 +0100 > Hi Matej, > thanks for the feedback. I reproduced the issue with DIRCMD=/OGN/LFN. > It doesn't happen with the GCC compiled version either. I'll need to > debug this a bit. > OW has heap after stack unlike the other compilers, which have stack > after heap. Stack after heap allows a bit of flexibility as the two > grow to each other, so perhaps it's just that the heap is too small. > I'll let you know. > Bart > On 4 February 2018 at 17:38, Matej Horvat > <matej.hor...@guest.arnes.si> wrote: >> I found these bugs in the OW version so far: >> >> 1. When loading SRDXMS.SYS (with only SHELLHIGH=COMMANDW.COM and >> DEVICE=JEMMEX.EXE processed at that point), the driver loads, the kernel >> prints "Kernel: allocated 48 Diskbuffers = 25536 Bytes in HMA", then right >> after that I see "Not enough memory" (not sure what prints that), and >> FreeCOM prints "The shell is about to be terminated, though, this is >> forbidden", etc., and hangs. Loading the same driver with DEVLOAD from >> FDAUTO.BAT works fine. >> >> 2. Sometimes, after loading some TSRs from FDAUTO.BAT (e.g. Bret Johnson's >> CLOCK), FreeCOM hangs, though I can't reliably reproduce that and loading >> the same TSRs manually works fine. >> >> 3. With the DIRCMD environment variable set to "/OGN/LFN" (possibly with >> other options), FreeCOM prints "Out of memory" instead of the expected long >> file names - but "/LFN" by itself works fine. >> >> I think this is still an improvement compared to the previous version (if >> compiled with OW), but the Turbo C++ version does not have any of these >> problems. >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Freedos-devel mailing list >> Freedos-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/freedos-devel > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel > ____________________________________________________________ > The Unusual Link Between Alzheimer's and Coconut Oil (Watch) > Memory Repair Protocol > http://thirdpartyoffers.juno.com/TGL3142/5a7a161e77d43161e6b53st01vuc Mit freundlichen Grüßen/Kind regards Tom Ehlert +49-241-79886 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
