Figuring out size of Device Drivers and where they are loaded in High Memory












3















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?










share|improve this question


















  • 1





    Simply by trying - and monitoring it wiht any utility showing the memory block chain.

    – Raffzahn
    Feb 22 at 2:10











  • 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
    Feb 22 at 11:19











  • @TripeHound yes, OPTIMIZE.

    – Stephen Kitt
    Feb 22 at 11:36











  • MS-DOS 6.x has MEMMAKER to do this.

    – Alan B
    Feb 25 at 13:46











  • you can force to load drivers into high memory using LH and DEVICEHIGH after HIMEM.SYS is loaded. If 618K is not enough base memory you can customize your autoxec/config with menu not using some drivers when not needed ... some drivers like CDROM and SMARTDRV can be loaded at runtime using loadsys utility. Take a look at How do I create a boot menu to select between Windows and DOS? for example of menu setup I used in the old days

    – Spektre
    Mar 13 at 10:33


















3















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?










share|improve this question


















  • 1





    Simply by trying - and monitoring it wiht any utility showing the memory block chain.

    – Raffzahn
    Feb 22 at 2:10











  • 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
    Feb 22 at 11:19











  • @TripeHound yes, OPTIMIZE.

    – Stephen Kitt
    Feb 22 at 11:36











  • MS-DOS 6.x has MEMMAKER to do this.

    – Alan B
    Feb 25 at 13:46











  • you can force to load drivers into high memory using LH and DEVICEHIGH after HIMEM.SYS is loaded. If 618K is not enough base memory you can customize your autoxec/config with menu not using some drivers when not needed ... some drivers like CDROM and SMARTDRV can be loaded at runtime using loadsys utility. Take a look at How do I create a boot menu to select between Windows and DOS? for example of menu setup I used in the old days

    – Spektre
    Mar 13 at 10:33
















3












3








3








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?










share|improve this question














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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Feb 22 at 1:17









dvanariadvanaria

1184




1184








  • 1





    Simply by trying - and monitoring it wiht any utility showing the memory block chain.

    – Raffzahn
    Feb 22 at 2:10











  • 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
    Feb 22 at 11:19











  • @TripeHound yes, OPTIMIZE.

    – Stephen Kitt
    Feb 22 at 11:36











  • MS-DOS 6.x has MEMMAKER to do this.

    – Alan B
    Feb 25 at 13:46











  • you can force to load drivers into high memory using LH and DEVICEHIGH after HIMEM.SYS is loaded. If 618K is not enough base memory you can customize your autoxec/config with menu not using some drivers when not needed ... some drivers like CDROM and SMARTDRV can be loaded at runtime using loadsys utility. Take a look at How do I create a boot menu to select between Windows and DOS? for example of menu setup I used in the old days

    – Spektre
    Mar 13 at 10:33
















  • 1





    Simply by trying - and monitoring it wiht any utility showing the memory block chain.

    – Raffzahn
    Feb 22 at 2:10











  • 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
    Feb 22 at 11:19











  • @TripeHound yes, OPTIMIZE.

    – Stephen Kitt
    Feb 22 at 11:36











  • MS-DOS 6.x has MEMMAKER to do this.

    – Alan B
    Feb 25 at 13:46











  • you can force to load drivers into high memory using LH and DEVICEHIGH after HIMEM.SYS is loaded. If 618K is not enough base memory you can customize your autoxec/config with menu not using some drivers when not needed ... some drivers like CDROM and SMARTDRV can be loaded at runtime using loadsys utility. Take a look at How do I create a boot menu to select between Windows and DOS? for example of menu setup I used in the old days

    – Spektre
    Mar 13 at 10:33










1




1





Simply by trying - and monitoring it wiht any utility showing the memory block chain.

– Raffzahn
Feb 22 at 2:10





Simply by trying - and monitoring it wiht any utility showing the memory block chain.

– Raffzahn
Feb 22 at 2:10













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
Feb 22 at 11:19





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
Feb 22 at 11:19













@TripeHound yes, OPTIMIZE.

– Stephen Kitt
Feb 22 at 11:36





@TripeHound yes, OPTIMIZE.

– Stephen Kitt
Feb 22 at 11:36













MS-DOS 6.x has MEMMAKER to do this.

– Alan B
Feb 25 at 13:46





MS-DOS 6.x has MEMMAKER to do this.

– Alan B
Feb 25 at 13:46













you can force to load drivers into high memory using LH and DEVICEHIGH after HIMEM.SYS is loaded. If 618K is not enough base memory you can customize your autoxec/config with menu not using some drivers when not needed ... some drivers like CDROM and SMARTDRV can be loaded at runtime using loadsys utility. Take a look at How do I create a boot menu to select between Windows and DOS? for example of menu setup I used in the old days

– Spektre
Mar 13 at 10:33







you can force to load drivers into high memory using LH and DEVICEHIGH after HIMEM.SYS is loaded. If 618K is not enough base memory you can customize your autoxec/config with menu not using some drivers when not needed ... some drivers like CDROM and SMARTDRV can be loaded at runtime using loadsys utility. Take a look at How do I create a boot menu to select between Windows and DOS? for example of menu setup I used in the old days

– Spektre
Mar 13 at 10:33












2 Answers
2






active

oldest

votes


















11














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.



IIRC 618 K is quite a good result with MS-DOS, and does indeed suggest that all drivers and TSRs are loaded high. To improve on that, you’d have to move some DOS data structures high, using a tool such as DOSMAX (or QEMM’s DOS-Up). MGDx has a nice page on the subject.



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).






share|improve this answer


























  • Thanks for that great write up.

    – Raffzahn
    Feb 22 at 12:13



















2














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.






share|improve this answer























    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
    });


    }
    });














    draft saved

    draft discarded


















    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









    11














    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.



    IIRC 618 K is quite a good result with MS-DOS, and does indeed suggest that all drivers and TSRs are loaded high. To improve on that, you’d have to move some DOS data structures high, using a tool such as DOSMAX (or QEMM’s DOS-Up). MGDx has a nice page on the subject.



    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).






    share|improve this answer


























    • Thanks for that great write up.

      – Raffzahn
      Feb 22 at 12:13
















    11














    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.



    IIRC 618 K is quite a good result with MS-DOS, and does indeed suggest that all drivers and TSRs are loaded high. To improve on that, you’d have to move some DOS data structures high, using a tool such as DOSMAX (or QEMM’s DOS-Up). MGDx has a nice page on the subject.



    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).






    share|improve this answer


























    • Thanks for that great write up.

      – Raffzahn
      Feb 22 at 12:13














    11












    11








    11







    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.



    IIRC 618 K is quite a good result with MS-DOS, and does indeed suggest that all drivers and TSRs are loaded high. To improve on that, you’d have to move some DOS data structures high, using a tool such as DOSMAX (or QEMM’s DOS-Up). MGDx has a nice page on the subject.



    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).






    share|improve this answer















    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.



    IIRC 618 K is quite a good result with MS-DOS, and does indeed suggest that all drivers and TSRs are loaded high. To improve on that, you’d have to move some DOS data structures high, using a tool such as DOSMAX (or QEMM’s DOS-Up). MGDx has a nice page on the subject.



    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).







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Feb 22 at 13:59

























    answered Feb 22 at 9:30









    Stephen KittStephen Kitt

    38.4k8156168




    38.4k8156168













    • Thanks for that great write up.

      – Raffzahn
      Feb 22 at 12:13



















    • Thanks for that great write up.

      – Raffzahn
      Feb 22 at 12:13

















    Thanks for that great write up.

    – Raffzahn
    Feb 22 at 12:13





    Thanks for that great write up.

    – Raffzahn
    Feb 22 at 12:13











    2














    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.






    share|improve this answer




























      2














      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.






      share|improve this answer


























        2












        2








        2







        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.






        share|improve this answer













        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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Feb 22 at 8:15









        tofrotofro

        16.2k33391




        16.2k33391






























            draft saved

            draft discarded




















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            Index of /

            Tribalistas

            Listed building