On Fri, 5 Jul 2013 15:45:34 GMT "Bret Johnson" <bretj...@juno.com> Hi Bret ! (long time, no see...) >> ... a user who is able, one way or another, to have usable RAM >> mapped above the 640 k so-called limit into the "video memory' >> segments, up to 736 k (B7FFF), will be forced to use the added >> memory as "UMB"s instead of an extension of *contiguous* so-called >> conventional mem. > Is this what you're trying to do (get more than 640k without > using UMB's), and why you don't like the XBDA / master > environment being at the top of conventional memory?
I was giving this as one example of why FreeDOS having relegated the master environment copy to the top of conventional mem /can/ break things. I could have given quite different examples, nor exaples I could name old programs still available which were written as early as the times of MS DOS 2 (!) with the implied assumption that Command's env block follows immediately above its PSP's block. The exact reason which made me stumble on this non-conformity of FreeCOM's does not need to be discussed in detail, it is complex and would derail the discussion. Fact is, some project someone else is building has elected to use a FreeDOS boot disk for a basis, and this bizarre, unmotivated, design of FreeCOM definitely interferes negatively with some aspects of the project. It isn't ruining all, and we could well use another shell than FreeCOM - in fact, I think the project will be its own shell for a self-contained diskette or USB-stick of sorts. Now see! you've driven me into digressing from my initial purpose here again ;=) 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. 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 of necessity FreeCOM internally keeps to the environment ! 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. Hoping this could be at least some food for thought, and Taking the leave for now -- 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
