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?
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.