Figuring out size of Device Drivers and where they are loaded in High MemoryWhat are these tiny TSRs...
Coworker asking me to not bring cakes due to self control issue. What should I do?
What are some good alternatives to Whisper for blockchain messaging?
How bad is a Computer Science course that doesn't teach Design Patterns?
Why can SHM equations be described in sine(s) and cosine(s)?
Figuring out size of Device Drivers and where they are loaded in High Memory
Why write a book when there's a movie in my head?
What does an unprocessed RAW file look like?
Are all power cords made equal?
How do I avoid the "chosen hero" feeling?
Do the speed limit reductions due to pollution also apply to electric cars in France?
Is Screenshot Time-tracking Common?
Do these large-scale, human power-plant-tending robots from the Matrix movies have a name, in-universe or out?
Minimum Viable Product for RTS game?
Why and/or operations in python statement are behaving unexpectedly?
Can I legally make a website about boycotting a certain company?
Short story about a man betting a group he could tell a story, and one of them would disappear and the others would not notice
Identical projects by students at two different colleges: still plagiarism?
How many copper coins fit inside a cubic foot?
Is it possible to detect 100% of SQLi with a simple regex?
Buying a "Used" Router
Dot product with a constant
A cancellation property for permutations?
Checking if an integer permutation is cyclic in Java
Why are "square law" devices important?
Figuring out size of Device Drivers and where they are loaded in High Memory
What are these tiny TSRs doing?What are my options for multitasking in MS-DOS 5.0 on an 80186 with EMS?
I'm setting up a 486 PC (aiming for around 1994 or so) and I have the following device drivers set up in DOS 6.22:
HIMEM.SYS
EMM386.EXE
ANSI.SYS
SBIDE.SYS
CTMOUSE.EXE
SMARTDRV.EXE
DOSKEY.COM
MSCDEX.EXE
I'm loading all these devices (including part of DOS itself) into High Memory and the MEM command is showing that the largest executable program size is 618 K, which I think means that DOS was successful in allocating all the drivers into upper memory, but I'm not sure.
If I understand loading things into high memory correctly, there are only a certain number of "blocks" available to do this, correct? And the order in which the drivers are loaded high (in AUTOEXEC.BAT and CONFIG.SYS) matters, because once a block is taken, the extra space is wasted within that block.
How do I know what the optimal order of loading these drivers should be?
ms-dos
New contributor
add a comment |
I'm setting up a 486 PC (aiming for around 1994 or so) and I have the following device drivers set up in DOS 6.22:
HIMEM.SYS
EMM386.EXE
ANSI.SYS
SBIDE.SYS
CTMOUSE.EXE
SMARTDRV.EXE
DOSKEY.COM
MSCDEX.EXE
I'm loading all these devices (including part of DOS itself) into High Memory and the MEM command is showing that the largest executable program size is 618 K, which I think means that DOS was successful in allocating all the drivers into upper memory, but I'm not sure.
If I understand loading things into high memory correctly, there are only a certain number of "blocks" available to do this, correct? And the order in which the drivers are loaded high (in AUTOEXEC.BAT and CONFIG.SYS) matters, because once a block is taken, the extra space is wasted within that block.
How do I know what the optimal order of loading these drivers should be?
ms-dos
New contributor
1
Simply by trying - and monitoring it wiht any utility showing the memory block chain.
– Raffzahn
10 hours ago
I have a vague recollection that QuarterDeck's QEMM (I think) came with a utility that would do some kind of repetitive reboot, trying drivers in either different orders and/or places (high/low), but could be mistaken (even more vaguely remembered with an ability to fix certain orders, where one driver depended on an earlier one).
– TripeHound
1 hour ago
@TripeHound yes,OPTIMIZE
.
– Stephen Kitt
46 mins ago
add a comment |
I'm setting up a 486 PC (aiming for around 1994 or so) and I have the following device drivers set up in DOS 6.22:
HIMEM.SYS
EMM386.EXE
ANSI.SYS
SBIDE.SYS
CTMOUSE.EXE
SMARTDRV.EXE
DOSKEY.COM
MSCDEX.EXE
I'm loading all these devices (including part of DOS itself) into High Memory and the MEM command is showing that the largest executable program size is 618 K, which I think means that DOS was successful in allocating all the drivers into upper memory, but I'm not sure.
If I understand loading things into high memory correctly, there are only a certain number of "blocks" available to do this, correct? And the order in which the drivers are loaded high (in AUTOEXEC.BAT and CONFIG.SYS) matters, because once a block is taken, the extra space is wasted within that block.
How do I know what the optimal order of loading these drivers should be?
ms-dos
New contributor
I'm setting up a 486 PC (aiming for around 1994 or so) and I have the following device drivers set up in DOS 6.22:
HIMEM.SYS
EMM386.EXE
ANSI.SYS
SBIDE.SYS
CTMOUSE.EXE
SMARTDRV.EXE
DOSKEY.COM
MSCDEX.EXE
I'm loading all these devices (including part of DOS itself) into High Memory and the MEM command is showing that the largest executable program size is 618 K, which I think means that DOS was successful in allocating all the drivers into upper memory, but I'm not sure.
If I understand loading things into high memory correctly, there are only a certain number of "blocks" available to do this, correct? And the order in which the drivers are loaded high (in AUTOEXEC.BAT and CONFIG.SYS) matters, because once a block is taken, the extra space is wasted within that block.
How do I know what the optimal order of loading these drivers should be?
ms-dos
ms-dos
New contributor
New contributor
New contributor
asked 11 hours ago
dvanariadvanaria
1063
1063
New contributor
New contributor
1
Simply by trying - and monitoring it wiht any utility showing the memory block chain.
– Raffzahn
10 hours ago
I have a vague recollection that QuarterDeck's QEMM (I think) came with a utility that would do some kind of repetitive reboot, trying drivers in either different orders and/or places (high/low), but could be mistaken (even more vaguely remembered with an ability to fix certain orders, where one driver depended on an earlier one).
– TripeHound
1 hour ago
@TripeHound yes,OPTIMIZE
.
– Stephen Kitt
46 mins ago
add a comment |
1
Simply by trying - and monitoring it wiht any utility showing the memory block chain.
– Raffzahn
10 hours ago
I have a vague recollection that QuarterDeck's QEMM (I think) came with a utility that would do some kind of repetitive reboot, trying drivers in either different orders and/or places (high/low), but could be mistaken (even more vaguely remembered with an ability to fix certain orders, where one driver depended on an earlier one).
– TripeHound
1 hour ago
@TripeHound yes,OPTIMIZE
.
– Stephen Kitt
46 mins ago
1
1
Simply by trying - and monitoring it wiht any utility showing the memory block chain.
– Raffzahn
10 hours ago
Simply by trying - and monitoring it wiht any utility showing the memory block chain.
– Raffzahn
10 hours ago
I have a vague recollection that QuarterDeck's QEMM (I think) came with a utility that would do some kind of repetitive reboot, trying drivers in either different orders and/or places (high/low), but could be mistaken (even more vaguely remembered with an ability to fix certain orders, where one driver depended on an earlier one).
– TripeHound
1 hour ago
I have a vague recollection that QuarterDeck's QEMM (I think) came with a utility that would do some kind of repetitive reboot, trying drivers in either different orders and/or places (high/low), but could be mistaken (even more vaguely remembered with an ability to fix certain orders, where one driver depended on an earlier one).
– TripeHound
1 hour ago
@TripeHound yes,
OPTIMIZE
.– Stephen Kitt
46 mins ago
@TripeHound yes,
OPTIMIZE
.– Stephen Kitt
46 mins ago
add a comment |
2 Answers
2
active
oldest
votes
You can see the details of everything loaded in memory using
MEM /D /P
including device drivers etc. If you have Microsoft’s Manifest tool, you can use that to get a better idea of memory use too; many other tools exist to explore your system’s configuration.
To optimise the memory footprint, you typically need to vary the load order, with the aim of loading larger programs first — larger not necessarily in terms of resident size, but in terms of load size, since the loaded device driver or TSR needs to fit entirely in an upper memory block before it goes resident. In most cases, for .SYS
or .COM
files (strictly speaking, for non-MZ files), the memory required to load them is the size of the file; for MZ files (.EXE
usually), it’s often the size of the file but not necessarily.
There are other considerations. Some device drivers and TSRs can move themselves to upper memory, and should be allowed to do so (i.e. loaded with DEVICE
instead of DEVICEHIGH
, and without LOADHIGH
for TSRs). If your upper memory is split into multiple blocks, you can tell DEVICEHIGH
and LOADHIGH
which block to use with the /L
parameter (/L:1,10240
will load into region 1 if it has at least 10240 bytes available, IIRC). In some situations, you might want to load a TSR earlier than AUTOEXEC.BAT
, using INSTALLHIGH
in CONFIG.SYS
— this allows a large TSR to be loaded before certain device drivers.
As Raffzahn says, it’s often a case of trial-and-error — at least with DOS 6 you can skip your boot files if things get too messed up for the system to boot. Since you’re running DOS 6.22, you can use MEMMAKER
to do a lot of this for you — it will try various combinations and place device drivers and TSRs into the appropriate blocks if necessary.
Another angle to investigate is to look for device drivers or TSRs providing equivalent functionality, but using less memory. You’re already using a small mouse driver; you might like SHSUCD
instead of MSCDEX
, and NNANSI
instead of ANSI.SYS
. Using 4DOS instead of COMMAND.COM
will provide better control over upper memory use, and allow you to drop DOSKEY
(along with all the nice command-line features of 4DOS).
Thanks for that great write up.
– Raffzahn
9 mins ago
add a comment |
MEM /C /P
Should show you what has been loaded into UMBs and what not.
If not all of your programs you think that should run in upper memory actually do, you can try permutating the load order in AUTOEXEC.BAT and CONFIG.SYS to find an order that may fit better.
Back in the days, I used to have a program UMBINFO.EXE
that showed more information about occupied UMBs (and possibly wasted space), but I can't find it anywhere.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "648"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
dvanaria is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f9241%2ffiguring-out-size-of-device-drivers-and-where-they-are-loaded-in-high-memory%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
You can see the details of everything loaded in memory using
MEM /D /P
including device drivers etc. If you have Microsoft’s Manifest tool, you can use that to get a better idea of memory use too; many other tools exist to explore your system’s configuration.
To optimise the memory footprint, you typically need to vary the load order, with the aim of loading larger programs first — larger not necessarily in terms of resident size, but in terms of load size, since the loaded device driver or TSR needs to fit entirely in an upper memory block before it goes resident. In most cases, for .SYS
or .COM
files (strictly speaking, for non-MZ files), the memory required to load them is the size of the file; for MZ files (.EXE
usually), it’s often the size of the file but not necessarily.
There are other considerations. Some device drivers and TSRs can move themselves to upper memory, and should be allowed to do so (i.e. loaded with DEVICE
instead of DEVICEHIGH
, and without LOADHIGH
for TSRs). If your upper memory is split into multiple blocks, you can tell DEVICEHIGH
and LOADHIGH
which block to use with the /L
parameter (/L:1,10240
will load into region 1 if it has at least 10240 bytes available, IIRC). In some situations, you might want to load a TSR earlier than AUTOEXEC.BAT
, using INSTALLHIGH
in CONFIG.SYS
— this allows a large TSR to be loaded before certain device drivers.
As Raffzahn says, it’s often a case of trial-and-error — at least with DOS 6 you can skip your boot files if things get too messed up for the system to boot. Since you’re running DOS 6.22, you can use MEMMAKER
to do a lot of this for you — it will try various combinations and place device drivers and TSRs into the appropriate blocks if necessary.
Another angle to investigate is to look for device drivers or TSRs providing equivalent functionality, but using less memory. You’re already using a small mouse driver; you might like SHSUCD
instead of MSCDEX
, and NNANSI
instead of ANSI.SYS
. Using 4DOS instead of COMMAND.COM
will provide better control over upper memory use, and allow you to drop DOSKEY
(along with all the nice command-line features of 4DOS).
Thanks for that great write up.
– Raffzahn
9 mins ago
add a comment |
You can see the details of everything loaded in memory using
MEM /D /P
including device drivers etc. If you have Microsoft’s Manifest tool, you can use that to get a better idea of memory use too; many other tools exist to explore your system’s configuration.
To optimise the memory footprint, you typically need to vary the load order, with the aim of loading larger programs first — larger not necessarily in terms of resident size, but in terms of load size, since the loaded device driver or TSR needs to fit entirely in an upper memory block before it goes resident. In most cases, for .SYS
or .COM
files (strictly speaking, for non-MZ files), the memory required to load them is the size of the file; for MZ files (.EXE
usually), it’s often the size of the file but not necessarily.
There are other considerations. Some device drivers and TSRs can move themselves to upper memory, and should be allowed to do so (i.e. loaded with DEVICE
instead of DEVICEHIGH
, and without LOADHIGH
for TSRs). If your upper memory is split into multiple blocks, you can tell DEVICEHIGH
and LOADHIGH
which block to use with the /L
parameter (/L:1,10240
will load into region 1 if it has at least 10240 bytes available, IIRC). In some situations, you might want to load a TSR earlier than AUTOEXEC.BAT
, using INSTALLHIGH
in CONFIG.SYS
— this allows a large TSR to be loaded before certain device drivers.
As Raffzahn says, it’s often a case of trial-and-error — at least with DOS 6 you can skip your boot files if things get too messed up for the system to boot. Since you’re running DOS 6.22, you can use MEMMAKER
to do a lot of this for you — it will try various combinations and place device drivers and TSRs into the appropriate blocks if necessary.
Another angle to investigate is to look for device drivers or TSRs providing equivalent functionality, but using less memory. You’re already using a small mouse driver; you might like SHSUCD
instead of MSCDEX
, and NNANSI
instead of ANSI.SYS
. Using 4DOS instead of COMMAND.COM
will provide better control over upper memory use, and allow you to drop DOSKEY
(along with all the nice command-line features of 4DOS).
Thanks for that great write up.
– Raffzahn
9 mins ago
add a comment |
You can see the details of everything loaded in memory using
MEM /D /P
including device drivers etc. If you have Microsoft’s Manifest tool, you can use that to get a better idea of memory use too; many other tools exist to explore your system’s configuration.
To optimise the memory footprint, you typically need to vary the load order, with the aim of loading larger programs first — larger not necessarily in terms of resident size, but in terms of load size, since the loaded device driver or TSR needs to fit entirely in an upper memory block before it goes resident. In most cases, for .SYS
or .COM
files (strictly speaking, for non-MZ files), the memory required to load them is the size of the file; for MZ files (.EXE
usually), it’s often the size of the file but not necessarily.
There are other considerations. Some device drivers and TSRs can move themselves to upper memory, and should be allowed to do so (i.e. loaded with DEVICE
instead of DEVICEHIGH
, and without LOADHIGH
for TSRs). If your upper memory is split into multiple blocks, you can tell DEVICEHIGH
and LOADHIGH
which block to use with the /L
parameter (/L:1,10240
will load into region 1 if it has at least 10240 bytes available, IIRC). In some situations, you might want to load a TSR earlier than AUTOEXEC.BAT
, using INSTALLHIGH
in CONFIG.SYS
— this allows a large TSR to be loaded before certain device drivers.
As Raffzahn says, it’s often a case of trial-and-error — at least with DOS 6 you can skip your boot files if things get too messed up for the system to boot. Since you’re running DOS 6.22, you can use MEMMAKER
to do a lot of this for you — it will try various combinations and place device drivers and TSRs into the appropriate blocks if necessary.
Another angle to investigate is to look for device drivers or TSRs providing equivalent functionality, but using less memory. You’re already using a small mouse driver; you might like SHSUCD
instead of MSCDEX
, and NNANSI
instead of ANSI.SYS
. Using 4DOS instead of COMMAND.COM
will provide better control over upper memory use, and allow you to drop DOSKEY
(along with all the nice command-line features of 4DOS).
You can see the details of everything loaded in memory using
MEM /D /P
including device drivers etc. If you have Microsoft’s Manifest tool, you can use that to get a better idea of memory use too; many other tools exist to explore your system’s configuration.
To optimise the memory footprint, you typically need to vary the load order, with the aim of loading larger programs first — larger not necessarily in terms of resident size, but in terms of load size, since the loaded device driver or TSR needs to fit entirely in an upper memory block before it goes resident. In most cases, for .SYS
or .COM
files (strictly speaking, for non-MZ files), the memory required to load them is the size of the file; for MZ files (.EXE
usually), it’s often the size of the file but not necessarily.
There are other considerations. Some device drivers and TSRs can move themselves to upper memory, and should be allowed to do so (i.e. loaded with DEVICE
instead of DEVICEHIGH
, and without LOADHIGH
for TSRs). If your upper memory is split into multiple blocks, you can tell DEVICEHIGH
and LOADHIGH
which block to use with the /L
parameter (/L:1,10240
will load into region 1 if it has at least 10240 bytes available, IIRC). In some situations, you might want to load a TSR earlier than AUTOEXEC.BAT
, using INSTALLHIGH
in CONFIG.SYS
— this allows a large TSR to be loaded before certain device drivers.
As Raffzahn says, it’s often a case of trial-and-error — at least with DOS 6 you can skip your boot files if things get too messed up for the system to boot. Since you’re running DOS 6.22, you can use MEMMAKER
to do a lot of this for you — it will try various combinations and place device drivers and TSRs into the appropriate blocks if necessary.
Another angle to investigate is to look for device drivers or TSRs providing equivalent functionality, but using less memory. You’re already using a small mouse driver; you might like SHSUCD
instead of MSCDEX
, and NNANSI
instead of ANSI.SYS
. Using 4DOS instead of COMMAND.COM
will provide better control over upper memory use, and allow you to drop DOSKEY
(along with all the nice command-line features of 4DOS).
answered 2 hours ago
Stephen KittStephen Kitt
38.1k8154166
38.1k8154166
Thanks for that great write up.
– Raffzahn
9 mins ago
add a comment |
Thanks for that great write up.
– Raffzahn
9 mins ago
Thanks for that great write up.
– Raffzahn
9 mins ago
Thanks for that great write up.
– Raffzahn
9 mins ago
add a comment |
MEM /C /P
Should show you what has been loaded into UMBs and what not.
If not all of your programs you think that should run in upper memory actually do, you can try permutating the load order in AUTOEXEC.BAT and CONFIG.SYS to find an order that may fit better.
Back in the days, I used to have a program UMBINFO.EXE
that showed more information about occupied UMBs (and possibly wasted space), but I can't find it anywhere.
add a comment |
MEM /C /P
Should show you what has been loaded into UMBs and what not.
If not all of your programs you think that should run in upper memory actually do, you can try permutating the load order in AUTOEXEC.BAT and CONFIG.SYS to find an order that may fit better.
Back in the days, I used to have a program UMBINFO.EXE
that showed more information about occupied UMBs (and possibly wasted space), but I can't find it anywhere.
add a comment |
MEM /C /P
Should show you what has been loaded into UMBs and what not.
If not all of your programs you think that should run in upper memory actually do, you can try permutating the load order in AUTOEXEC.BAT and CONFIG.SYS to find an order that may fit better.
Back in the days, I used to have a program UMBINFO.EXE
that showed more information about occupied UMBs (and possibly wasted space), but I can't find it anywhere.
MEM /C /P
Should show you what has been loaded into UMBs and what not.
If not all of your programs you think that should run in upper memory actually do, you can try permutating the load order in AUTOEXEC.BAT and CONFIG.SYS to find an order that may fit better.
Back in the days, I used to have a program UMBINFO.EXE
that showed more information about occupied UMBs (and possibly wasted space), but I can't find it anywhere.
answered 4 hours ago
tofrotofro
15.4k33188
15.4k33188
add a comment |
add a comment |
dvanaria is a new contributor. Be nice, and check out our Code of Conduct.
dvanaria is a new contributor. Be nice, and check out our Code of Conduct.
dvanaria is a new contributor. Be nice, and check out our Code of Conduct.
dvanaria is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Retrocomputing Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f9241%2ffiguring-out-size-of-device-drivers-and-where-they-are-loaded-in-high-memory%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Simply by trying - and monitoring it wiht any utility showing the memory block chain.
– Raffzahn
10 hours ago
I have a vague recollection that QuarterDeck's QEMM (I think) came with a utility that would do some kind of repetitive reboot, trying drivers in either different orders and/or places (high/low), but could be mistaken (even more vaguely remembered with an ability to fix certain orders, where one driver depended on an earlier one).
– TripeHound
1 hour ago
@TripeHound yes,
OPTIMIZE
.– Stephen Kitt
46 mins ago