> I see... following a very famous lead, you think that 640 kilo > bytes are more DOS memory than anybody will ever want :=)
No, that's not what I'm saying at all. One thing I am trying to say is that if you're going to use DOS memory, then you should use the memory allocation functions provided by DOS that already take things like the XBDA and master environment into account. Your advisee may may not /want/ anything (except what he wants to put there) at the top of conventional memory, but there's actually no legitimate reason other programs (including the BIOS and DOS) can't put anything there. If I were doing this, I wouldn't expect FreeDOS to change the way it does things -- I would change how my program works. This is not a FreeDOS "bug" that needs to be fixed, IMO. I agree it would probably nice to at least have an option, but I still wouldn't classify it as a "bug". > I hardly see how a regular program launched by FreeCOM could > relocate FreeCOM's master environment in a safe and generic enough > way, that is to say, without runtime "patching" FreeCOM at > specific, version dependent address(es). You're correct --it couldn't. I'm merely trying to offer up suggestions that may trigger some sort of alternative in your thought process (like maybe even doing something in CONFIG.SYS before FreeCOM ever even loads). E.g., install a "temporary" device driver that reserves the upper part of conventional memory so that FreeCOM can't load there. Maybe you can come up with a different/better idea. ------------------------------------------------------------------------------ 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
