如图所示，UMBPCI开启的内存分为两块：
CC00-DFFF
E400-EFFF
现在想让CC00段的程序全部移动至E400段，使空闲块最大，请问如何处理？
在COMMAND加载后，再enable CC00段是否可行？
中国DOS联盟
联盟域名：www.cn-dos.net 论坛域名：www.cn-dos.net/forum
DOS，代表着自由开放与发展，我们努力起来，学习FreeDOS和Linux的自由开放与GNU精神，共同创造和发展美好的自由与GNU GPL世界吧！
问个内存的问题
标题：问个内存的问题
如图所示，UMBPCI开启的内存分为两块：
CC00-DFFF
E400-EFFF
现在想让CC00段的程序全部移动至E400段，使空闲块最大，请问如何处理？
在COMMAND加载后，再enable CC00段是否可行？
lh可以加参数，让程序到某个区块的……
像SYSTEM, FILES, STACKS这些，不能用LH指定吧？
COMMAND也可以指定加载位置吗？
COMMAND也可以指定加载位置吗？
此Rinrin是彼Rinrin吗？
你的问题我也不懂。
你的问题我也不懂。
command.com 虽然不能指定，但是它会自动放到最合理的地方吧
原来你移这些啊，那我就没办法了……
Originally posted by Rinrin at 2009-4-7 09:22:
像SYSTEM, FILES, STACKS这些，不能用LH指定吧？
COMMAND也可以指定加载位置吗？
这些系统数据可能无法指定加载到什么位置。
如果用 QEMM386 的话，可以用 LOADHI.SYS 加载 COMMAND.COM 到指定的 UMB 区域。
使用/L的区域参数似乎会稍微浪费一点空间
使用之前：
使用/L:2之后：
损失64字节
而且，这些TSR程序，似乎一般会留出几百个字节的空间，不知是做什么用的？
楼上说的QEMM，我先试试
[ Last edited by Rinrin on 2009-4-19 at 06:02 ]
使用之前：
Upper memory detail:
Segment Region Size Name Type
------- ------ ---------------- ----------- --------
0B01F 1 32,256 (32K) MS-DOS -- Free --
0C700 2 58,080 (57K) SYSTEM System Data
848 (1K) SETVERXX Installed Driver SETVER
1,776 (2K) U-CD-DVD Installed Driver UIDE
6,512 (6K) PROTMAN$ Installed Driver PROTMAN
2,656 (3K) PKTDRV$ Installed Driver DIS_PKT
27,696 (27K) PCNTND$ Installed Driver PCNTND
2,080 (2K) FILES=40
256 (0K) FCBS=4
10,720 (10K) BUFFERS=20
2,288 (2K) LASTDRIVE=Z
3,072 (3K) STACKS=9,256
0D52E 2 176 (0K) MS-DOS -- Free --
0D539 2 400 (0K) KILLER Program
0D552 2 3,968 (4K) DOSKEY Program
0D64A 2 5,856 (6K) SHARE Program
0D7B8 2 3,872 (4K) NLSFUNC Program
0D8AA 2 208 (0K) MS-DOS -- Free --
0D8B7 2 3,104 (3K) CTMOUSE Program
0D979 2 224 (0K) MS-DOS -- Free --
0D987 2 13,632 (13K) DOSLFN Program
0DCDB 2 368 (0K) DOSIDLE Program
0DCF2 2 12,496 (12K) MS-DOS -- Free --
0E400 3 5,728 (6K) COMMAND Program
0E566 3 1,696 (2K) COMMAND Environment
0E5D0 3 4,864 (5K) MS-DOS -- Free --
使用/L:2之后：
Upper memory detail:
Segment Region Size Name Type
------- ------ ---------------- ----------- --------
0B01F 1 32,256 (32K) MS-DOS -- Free --
0C700 2 880 (1K) SYSTEM System Data
848 (1K) SETVERXX Installed Driver SETVER
0C737 2 1,808 (2K) SYSTEM System Data
1,776 (2K) U-CD-DVD Installed Driver UIDE
0C7A8 2 6,544 (6K) SYSTEM System Data
6,512 (6K) PROTMAN$ Installed Driver PROTMAN
0C941 2 2,688 (3K) SYSTEM System Data
2,656 (3K) PKTDRV$ Installed Driver DIS_PKT
0C9E9 2 46,224 (45K) SYSTEM System Data
27,696 (27K) PCNTND$ Installed Driver PCNTND
2,080 (2K) FILES=40
256 (0K) FCBS=4
10,720 (10K) BUFFERS=20
2,288 (2K) LASTDRIVE=Z
3,072 (3K) STACKS=9,256
0D532 2 176 (0K) MS-DOS -- Free --
0D53D 2 400 (0K) KILLER Program
0D556 2 3,968 (4K) DOSKEY Program
0D64E 2 5,856 (6K) SHARE Program
0D7BC 2 3,872 (4K) NLSFUNC Program
0D8AE 2 208 (0K) MS-DOS -- Free --
0D8BB 2 3,104 (3K) CTMOUSE Program
0D97D 2 224 (0K) MS-DOS -- Free --
0D98B 2 13,632 (13K) DOSLFN Program
0DCDF 2 368 (0K) DOSIDLE Program
0DCF6 2 12,432 (12K) MS-DOS -- Free --
0E400 3 5,728 (6K) COMMAND Program
0E566 3 1,696 (2K) COMMAND Environment
0E5D0 3 4,864 (5K) MS-DOS -- Free --
损失64字节
而且，这些TSR程序，似乎一般会留出几百个字节的空间，不知是做什么用的？
楼上说的QEMM，我先试试
[ Last edited by Rinrin on 2009-4-19 at 06:02 ]
哈哈！好啊！损失64个字节也计较啊！哈哈哈哈！有我当年B(yte)B(yte)计较的精神。冲你这精神我就把我多年的经验拿出来共享下，大家讨论下吧。
许多 TSR 驻留内存后都会留出几十到几百甚至十几、几十K不等的间隔，那是因为一般 TSR 在加载时所占用的内存要比驻留后要大，因为加载时它还需要一定的环境空间，加载后就不需要了，至于为什么有的有，有的没有，具体我就不知道了，不知是不是和程序的编写有关。
还有一件怪事，有时候我没有改动任何内存配置，也没有改动硬件，但有时候启动后的原来有间隔的会没有，原来没间隔的又会有？下次启动又会正常？而且我还特意 reset 而不是 reboot 。有时候你多启动几次又会和平常一样了。这就是我说的，计算机中常有许多说不清道不明的事情。不过，遇上这样的事情概率很少，总之，计算机中的事情就是“不稳定”的。
从你这情况来看，加不加 /L:2 参数具体指明哪个区域没什么关系，因为 lh 不加参数时总是把 TSR 加载到最大的 UMB ，你这情况最大的 UMB 就是 2 ，所以加不加结果一样。
许多 TSR 驻留内存后都会留出几十到几百甚至十几、几十K不等的间隔，那是因为一般 TSR 在加载时所占用的内存要比驻留后要大，因为加载时它还需要一定的环境空间，加载后就不需要了，至于为什么有的有，有的没有，具体我就不知道了，不知是不是和程序的编写有关。
还有一件怪事，有时候我没有改动任何内存配置，也没有改动硬件，但有时候启动后的原来有间隔的会没有，原来没间隔的又会有？下次启动又会正常？而且我还特意 reset 而不是 reboot 。有时候你多启动几次又会和平常一样了。这就是我说的，计算机中常有许多说不清道不明的事情。不过，遇上这样的事情概率很少，总之，计算机中的事情就是“不稳定”的。
从你这情况来看，加不加 /L:2 参数具体指明哪个区域没什么关系，因为 lh 不加参数时总是把 TSR 加载到最大的 UMB ，你这情况最大的 UMB 就是 2 ，所以加不加结果一样。
而且，这些TSR程序，似乎一般会留出几百个字节的空间，不知是做什么用的？
程序驻留是以段为单位的16字节，特别是以前的dos版本，在读取文件时以扇区为单位的最小512字节。
还有dos的exe程序在编写时都要指定对齐方式，和连接方式，有：字节，双字，段(16）字节，512,4k,16k,64k,等，合理的分段对齐，可以提高程序的效率。
所看到的，驻留程序后面有几十，或几百个字节，不是因为该程序，而是后的程序造成的。
偶也是大概了解一点，再多的就不知道了。
to Climbing:是我
楼上的解答有点道理，但这个似乎不属于这种情况
我用debug看了这些空闲块，貌似存放的是环境变量
而且doslfn是个com程序，不是exe程序，不应该存在对齐的问题
[ Last edited by Rinrin on 2009-4-23 at 09:10 ]
楼上的解答有点道理，但这个似乎不属于这种情况
我用debug看了这些空闲块，貌似存放的是环境变量
而且doslfn是个com程序，不是exe程序，不应该存在对齐的问题
[ Last edited by Rinrin on 2009-4-23 at 09:10 ]
dos好像是会给com程序配一个环境段的，而驻留程序本身一般不会自行移动自身代码（病毒除外），dos系统对已经驻留的程序，也是不会去移动它的。由于空闲的空间太小，是无法再分配给其它的程序的。通常dos驻留程序都会有中断向量指向，要想把这个小空间合并成一个较大的空间，要考虑的问题太多了。
来源：https://www.cn-dos.net/forum/viewthread.php?tid=46808 · 打印时间 2026-08-15 21:34