>>> I'm surprised you have to question this! >>after ~12 years without anybody complaining, I'm surprised about you >> complaining.
> How many users do you have ? I have no idea - and don't care. > Of these, how many understands this level of detail, /and/ in addition, will > care ? answering this question would imply that /you/ understand the problem. you don't. > Methinks you were p.ssed off by my remarks, but there is nothing > personal to them. Who is , or are, the 'appointed maintainer(s)' for > FreeCOM ? Are you one of them ? 'appointment' would imply structure, leadership, organisation, ... none of this is currently happening. I just wrote the code to put the environment where it is (in 2001), that's all. and it's placed where it is for a *very* good reason. just think a bit about it >> the FreeDOS kernel relocates the XBDA. > Really ? Will it ? The kernel I'm using will /not/ do it, certainly not by > default. this is either a bug, or your XBDA behaves somewhat different. an unrelated story. >> *then* config.sys processing happens; possibly some driver maps a000- >> b7ff as conventional memory >> *then* comes command.com, and maps it's environment as high as >> possible. if b7ff is available, it will load it's environment there. >>if ef00 is available, it's loaded there. > Why these latter limits would be thus hard-coded is beyond me. b7ff is shorter then 'the highest location in conventional memory' >>it was easier to do it the way it is, and so far nobody >>complained. > HA ! Sincerity itself, at last! Now this I /can/ understand, and even > sympathise with :=) Not in line with what Dennis wrote, though... there are always people with more time and energy to write then knowledge to write about :( >> that's a pretty good design decision. > Only for so long as no one disputes it :=)... FreeCOM can't claim > MS-Command.com compatibility until time it has an option, and > I would suggest, the /default/, to allocate the master env block from > the bottom, instead of the top of conventional mem. > Besides, I hardly see how it was "easier", your word, for FreeCOM to do > it in the current way. I'd rather suspect whoever made the decision, *I* > back when, was confused, *no* > similar to how DM Cunney remained somehow > apparently confused to this day. ;) > Casually peeking at Freecom source, branch MAIN, init.c v 1.31, > Freecom's rev 1.31 (Excerpt, from Sourceforge CVS, w/ line numbers) > [code] > 437 env_resizeCtrl |= ENV_USEUMB | ENV_ALLOWMOVE | ENV_LASTFIT; > 438 if(forceLow) > 439 env_resizeCtrl &= ~ENV_USEUMB; > 440 if(newEnvSize > 16 && newEnvSize < 32767) > 441 env_setsize(0, newEnvSize); > [/code] > et caetera, etc... > I'm not an expert in C, not even close to a novice... good find. > With this duly noted, it appears it won't be hard for you Freecom > code contributors / revewers (is this not you, Tom E.?) to edit the above > module and possibly a handful of dependencies so that FreeCOM eventually > will request the environment block using "Firstfit" instead of "Lastfit" > strategy, at least when allocating from low memory. I don't care as much > if it uses "lastfit" when the request is effectively UMBs only, although > I'm not sure what is to be gained by using 'lastfit' even in upper memory. > Hoping someone will take the challenge, left as an exercise to the reader. suffice it to say: you wouldn't like the adverse effects. Tom ------------------------------------------------------------------------------ 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
