Bart Oldeman said: BO>It is also very tough to reload the code portions of the executable on BO>demand at the right place if you write your command.com in C instead of in BO>assembly language.
BO>It is not even the C perse that makes it tough, but rather the BO>interactions with its run-time library. This is why we can pull such BO>tricks in the kernel for instance, because it doesn't use any RTL BO>functionality, apart, perhaps, for some 32 bit arithmetic. BO>as far as I understand MS command.com relocates its code part to just BO>under 640k, and keeps all data together in a fixed sized area at the BO>start. You mean that, because FreeCOM uses runtime memory allocation, it is possible to have variables in the transient area of COMMAND.COM or to have the several parts of the transient COMMAND.COM memory image not in the same order as they are in the file, so the transient memory image cannot be recovered from the file ? BO>Freecom and C library functions use malloc() and related dynamic memory BO>allocation functions that allocate data higher up. Is this why the XMS block allocated by xmsswap is some 10 KB larger than the FreeCOM file size ,and more than 25 KB larger than the transient part of COMMAND.COM ? Regards JAS ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
