Re: Memory management FAQ
"Arkady V.Belousov" <[email protected]>
| Newsgroups | gmane.os.freedos.devel |
|---|---|
| Message-ID | <[email protected]> |
X-Comment-To: Matthias Paul Hi! 26-Окт-2002 22:45 [email protected] (Matthias Paul) wrote to [email protected]: MP> Maybe worth a few notes, HIMEM.SYS and/or EMM386.EXE provide so called MP> XMSUMB memory. XMSUMB is UMB memory through the XMS interface MP> (INT 2Fh/AX=4310h sub-functions 10h..12h), while "normal" UMB is usually MP> considered UMB memory as it is available through the higher level DOS MP> memory API (INT 21h/AH=48h..4Ah and AH=58h) - maybe we should call it MP> "DOSUMB"? The latter might also come from the XMSUMB pool MP> originally, but not necessarily so. I think, that this difference important _only_ for TSR developers, so FAQ for novices shouldn't bothered about this. MP> Many of the DR-DOS tools (like NLSFUNC, KEYB, SHARE, etc.) MP> are "self-loadhigh-enabled" and will try to relocate MP> (into the HMA, or) into UMB memory using the XMSUMB API. CTMOUSE too. :) It will load itself high even if there is no DOS=HIGH statement. MP> Finally, most drivers need way more memory during initialization MP> and it might be difficult to provide a large-enough continous MP> chunk of free upper memory for both, the resident driver plus MP> its initialization code, so it may happen, that even with LH and MP> friends, the driver ends up being loaded in conventional memory, MP> although the resident portion alone would still nicely fit up in there. I for a long time think about paragraph in the CTMOUSE.TXT, which says something like "don't use LH and LOADHI and LOADHIGH commands to run CTMOUSE unless this is really required, else result may be worser than possible". MP> So, providing XMSUMB and "DOSUMB" at the same time and dynamically MP> handling this internally can be a nice feature. It is not supported MP> by all memory managers, unfortunately (at least not by MS-DOS/PC DOS MP> EMM386, but, for example, it is supported by DR-DOS EMM386). MS-EMM386 also not supports EMS and XMS in same memory, it reduces XMS for EMS. >>> MB - megabyte (1024*1024 byte, or 1000*1000 byte, depends ;-)) >> To be precise: traditionally size of memory computed by power 2 base [...] >> Moreover, when we (humans) count size of free memory, we also >> often use decimal multipliers. For example, when someone says >> "621 Kb of free memory" this usually mean ~607 Kb (=621000/1024/1024). MP> Usually, the English seem to write "Kb", "Mb", "Gb", "Tb" in either MP> notation (you're right about the traditional meaning, of course). MP> In German the notation is to write "KB", "MB", "GB", "TB", in particular, MP> when the numbers are meant to be based on the binary system. MP> I have observed, however, that some use "Kb", "Mb", "Gb", "Tb", when the MP> numbers are meant to be decimal. It's not used consistently, though. I personally prefer "Kb", not "KB" because its looks nicer. :) But I also often use plain "K", without "b" ("2K", "2 Kb"). Moreover, someone use "b" or "B" for "bits", but in this case I strongly suggest that "bits" should be used explicitly ("64 Mbit"). BTW, we already discuss that 1024 multiplier used for memory size, but what about speed? _Should_ "1 Kb/sec" be used for "1024 b/sec" or for "1000 b/sec" (where "b" may be "bytes" or "bits"). Who what think?