Hi Eric, > this thread seems to mix two topics:
Yep, things got mixed, I suppose it's my fault. Consequently I'll try to leavo out - not quote - the bits which, though they may be interesting, I think irrelevant herein (snip...) > As Tom already pointed out, the location of the > master env in FreeCOM is "near the end of the free DOS RAM", > but only AFTER you get the chance to load e.g. UMB drivers. And as I must stress once again, I am considering the /alternate/ case, when no UMBs will be provided for DOS use. I have been suggesting that in this case, FreeCOM ought to allocate the block that it reserves for storing the main (1st level) environment area. Similar to what other reference DOSes have done forever (well, starting since MS-DOS 2, I think DOS 1 did not have the concept of "environment variables" later "borrowed" from Unix... > Also, the FreeDOS kernel allows you to control whether the > BIOS XBDA data should be relocated. This was a lateral question, but still : how ? the kernel we use doesn't seem to obey a 'Switches=/E' directive in Config.sys, that is the MS-DOS way. > So FreeCOM might differ from MS DOS, but still behave in a good way. I beg to differ vigorously - it behaves in a bad (tm) way. >> ...this bizarre, unmotivated, design of FreeCOM definitely interferes >> negatively with some aspects of the project. It isn't ruining all, > Bizarre yes, unmotivated no. For example XMS swapping is one > very useful feature of the complex FreeCOM memory handling. Like 4DOS by the way. I fail to see what XMS swapping (nice to have) is to do with my critique, though... >> Back to FreeCOM : of course we, app programmers, could devise a utility >> for the purpose of moving that darned environment back to where it >> belongs, i.e., low contiguous DOS-managed memory. > It is still obscure to me why that "darned" environment is so > much in the way for your project where it is with FreeCOM...? Suffice it to say it is an impediment to that project, plus a non conformance that will break other DOS apps for no real reason (that I can perceive) >> Leaving apart the fact that doing so from a transient DOS program and >> without leaving holes is not absolutely a trivial programming task, we >> would be still faced with the problem that, how are we supposed to >> reliably /find/ and adjust the pointer(s) that... FreeCOM internally keeps > I may be mistaken, but should not just the PSP point to the environment? You are mistaken indeed. Command's, or FreeCOM's own PSP would point to /its/ initial environment (if there was any established by Config.sys command, as has been possible in /MS/DOS since DOS 6, I know not whether FreeDOS has a similar concept. Let's not digress again!). Thus, the environment pointer inside the command processor's (shell's) PSP is either NUL, else pointing to an initial environment of no significance nor use.(Digressing again, I have been known to free that useless initial environement). /The/ "master environment" is a brand new one built by Command while it initialises things, and sized according to Command's command line parameters (if this is the primary shell, in turn lifted from the SHELL line in config.sys). Command / FreeCOM has to ask a block from DOS using the usual allocation functions 48h etc, with appropriate choices of "strategy". To sum up, repairing FreeCOM may be as simple as it passing the proper allocation strategy, i.e., don't include UMBs + find lowest suitable block as part of its DOS calls reserving that block. to the shell from DOS System initialisation.) >> Clearly IMHO it is Freecom's responsibility (i.e., of whoever is tasked with >> debugging, maintaining and enhancing FreeCOM) to provide the solution, >> be it a command line option, a permanent fix, or even an API. >See above. Also, nobody is "tasked" with FreeCOM, as this is >not a commercial product. I meant tasked in the sense of being the official maintainers, not as in paid for doing it. > Unfortunately, very few people who > are FreeCOM experts are around here recently... On the other > hand, maintenance is so slow because there was so little left to improve. Understood. Maybe if whoever is familiar with FreeCOM sources would consider the elements I have tried to provide, they would not find it unsurmountable to repair (or diplomatically, revise) this aspect. Bye ! -- Czerno ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
