Hi Aitor, >>>> It still needs a lot of unnecessary UMB room free to load there, e.g. >>>> 64 kb or some fairly high amount. And you may even have to explicitly >>>> mention it. I forget exactly and always (I think) loaded it low. Well, >>>> I'd have to check .... >>> >>> If only I could assume that there's ALWAYS XMS ;))) >> >> As far as I remember, the main problem was that you did not want >> to require DOS 4.0 or newer and therefore first allocated MANY >> buffers, then reducing them. With DOS 4.0 or newer, can simply >> check at run-time whether the user-selected amount of buffers >> will fit into the available memory, even for device drivers :-) > > You remember wrong. > It's simply that if the reallocate call fails, DISPLAY won't load at > all, and that is not desirable.
At the moment, DISPLAY will fail to load into any normal-sized UMB which means people will avoid using DISPLAY at all, which is even less desirable than a failure to load it when you try to load it into a too small USB. In the latter case, you can still reduce the number of buffers or make a bit more space to load DISPLAY into an USB at the next boot. When DISPLAY always starts with huge initial heap size, there is no workaround possibly beyond not using it... That said, a possible fallback could be to allocate low memory ONLY if the reallocation call fails. Then you neither have to start with huge initial heap nor have to abort loading either. > Change codepage can be called anytime. I can't just assume the > disk/file will be there to reload. It could be a command line option to enable this - saving RAM at the expense of a limited risk of change codepage calls later. Actually if XMS is available, buffering there will avoid a risk. > If instead of talking you send me some code that works the way it is > expected, I may merge it into the sources. Such code would fail to load DISPLAY at all if the user wants too many buffers and tries to load DISPLAY into a too small UMB (unless the low memory fallback is implemented) so it is in a way a matter of taste how to fail under RAM shortage. My personal opinion is that most people will only need SMALL numbers of buffers, so you could have a fixed allocation for that. Then only explicitly selecting many buffers will have the risk of failed reallocation calls and can be documented. >> so I would keep EDIT free of that. You could swap buffers >> of EDIT to XMS when XMS is available (detect at run-time). > > I know. But it's a lot more complex ;) I know ;-) Eric ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
