It tells me that SHSUCDX can't open CD driver optical
That was an example of what they use. You need to use the same CD drive identifer you're currently feeding to MSCDEX. (/D:MSCD001 rather than /D:OPTICAL)
The /D:mscd001 on your oakcdrom.sys line in config.sys creates the name and then the /D:mscd001 on your MSCDEX or SHSUCDX connects to it.
It tells me that SHSUCDX can't open CD driver optical
That was an example of what they use. You need to use the same CD drive identifer you're currently feeding to MSCDEX. (/D:MSCD001 rather than /D:OPTICAL)
The /D:mscd001 on your oakcdrom.sys line in config.sys creates the name and then the /D:mscd001 on your MSCDEX or SHSUCDX connects to it.
in config i have:
devicehigh=C:\cdrom\oakcdrom.sys /D:mscd001
In autoexec
LH C:\CDROM\SHCDX\SHSUCDX.COM /D:mscd001
If your COMMAND.COM is taking more than 816 bytes of conventional memory, setting 4DOS 8.00 (the "Free 4DOS" link at https://www.4dos.info/v4dos.htm#751 ) as the shell= can give you tab completion, command history, and a bunch of other nice stuff while also freeing up some conventional memory, thanks to its "XMS Swapping" feature.
This is why I like forum platforms that allow you to have the post reply included in the email notification--so you know if it's spam before you even head to the forum.
I've been playing around with Windows 98 on an HP T5710 thin client and would appreciate some feedback on the DOS side of things. I've been able to free up 602K of conventional memory using a basic setup similar to some of the examples here. One thing that been bugging me is that I'm seeing COMMAND loaded twice when I run "mem /c ":
Type of Memory Total Used Free
---------------- ----------- ----------- -----------
Conventional 634,880 18,224 616,656
Upper 109,088 90,640 18,448
Reserved 0 0 0
Extended (XMS)* 250,435,040 759,264 249,675,776
---------------- ----------- ----------- -----------
Total memory 251,179,008 868,128 250,310,880
Total under 1 MB 743,968 108,864 635,104
Total Expanded (EMS) 33,931,264 (32M)
Free Expanded (EMS)* 33,554,432 (32M)
* EMM386 is using XMS memory to simulate EMS memory as needed.
Free EMS memory may change as free XMS memory changes.
Largest executable program size 616,640 (602K)
Largest free upper memory block 13,008 (13K)
MS-DOS is resident in the high memory area.
Here is the more detailed "MEM /d" output:
MEM /d
Conventional Memory Detail:
Segment Total Name Type
------- ---------------- ----------- --------
00000 1,024 (1K) Interrupt Vector
00040 256 (0K) ROM Communication Area
00050 512 (1K) DOS Communication Area
00070 1,424 (1K) IO System Data
CON System Device Driver
AUX System Device Driver
PRN System Device Driver
CLOCK$ System Device Driver
A: - C: System Device Driver
COM1 System Device Driver
LPT1 System Device Driver
LPT2 System Device Driver
LPT3 System Device Driver
CONFIG$ System Device Driver
COM2 System Device Driver
COM3 System Device Driver
COM4 System Device Driver
000C9 5,120 (5K) MSDOS System Data
00209 9,568 (9K) IO System Data
1,152 (1K) XMSXXXX0 Installed Device=HIMEM
4,304 (4K) EMMXXXX0 Installed Device=EMM386
2,960 (3K) DblBuff$ Installed Device=DBLBUFF
544 (1K) Sector buffer
512 (1K) BUFFERS=40
0045F 80 (0K) MSDOS System Program
00464 224 (0K) MEM Environment
00472 90,464 (88K) MEM Program
01A88 526,192 (514K) MSDOS -- Free --
Upper Memory Detail:
Segment Region Total Name Type
------- ------ ---------------- ----------- --------
0B15C 1 8,624 (8K) COMMAND Program
0B377 1 80 (0K) COMMAND Data
0B37C 1 1,440 (1K) COMMAND Environment
0B3D6 1 224 (0K) MSDOS -- Free --
0B3E4 1 3,552 (3K) CTMOUSE Program
0B4C2 1 240 (0K) VIAFMTSR Environment
0B4D1 1 13,008 (13K) MSDOS -- Free --
Type of Memory Total Used Free
---------------- ----------- ----------- -----------
Conventional 634,880 18,224 616,656
Upper 109,088 90,640 18,448
Reserved 0 0 0
Extended (XMS)* 250,435,040 759,264 249,675,776
---------------- ----------- ----------- -----------
Total memory 251,179,008 868,128 250,310,880
Total under 1 MB 743,968 108,864 635,104
Handle EMS Name Size
------- -------- ------
0 05C000
Total Expanded (EMS) 33,931,264 (32M)
Free Expanded (EMS)* 33,554,432 (32M)
* EMM386 is using XMS memory to simulate EMS memory as needed.
Free EMS memory may change as free XMS memory changes.
Memory accessible using Int 15h 0 (0K)
Largest executable program size 616,640 (602K)
Largest free upper memory block 13,008 (13K)
MS-DOS is resident in the high memory area.
XMS version 3.00; driver version 3.95
EMS version 4.00
I assume that COMMAND.COM is being loaded twice? While it's not eating conventional memory, I'd still like to know why this is happening and if it could cause any problems (I'm trying to learn how this stuff works, not just how to use it). I'm booting into DOS using a PIF file created by making a shortcut to COMMAND.COM in my Windows directory. Here is the CONFIG.SYS part of it:
I assume that COMMAND.COM is being loaded twice? While it's not eating conventional memory, I'd still like to know why this is happening and if it could cause any problems (I'm trying to learn how this stuff works, not just how to use it). I'm booting into DOS using a PIF file created by making a shortcut to COMMAND.COM in my Windows directory.
Huh. You're right. I avoided having to reboot into MS-DOS Mode if at all possible as a kid and, as an adult, I use the boot menu that came with my copy of PartitionMagic 3 and dual-boot Windows 98SE and DOS 6.22+Windows 3.11 for Workgroups, so I never noticed.
Anyway, it looks like it's because, when you ask to launch COMMAND.COM as the application, it takes you at your word and doesn't do anything fancy to collapse away the COMMAND.COM you get as part of DOS, leaving you with a nested COMMAND.COM session.
If you're familiar with Linux command-line stuff, it'd be sort of like a launcher GUI using bash -c "$1" to process a user-specified command-line . If the user specifies bash as the command, then that becomes bash -c "bash", resulting in a nested bash.
You can test this by creating a test.bat file containing something like this and then creating an MS-DOS Mode PIF for that instead:
1mem /c /p 2pause
That'll get you a mem /c /p readout without first invoking a nested COMMAND.COM
One option to resolve the issue is to attrib -r c:\msdos.sys, then edit msdos.sys and then change the BootGUI=1 line to BootGUI=0 so it won't boot into the GUI until you type win, leaving you running at that initial COMMAND.COM. (As of Windows 95, msdos.sys changed from machine code to a config file.)
Alternatively, you could do the fun thing and use edit, echo, Alt+219 (keypad numbers only), CHOICE.EXE, and ERRORLEVEL to create your own one-touch batch-file menu for your MS-DOS Mode shortcut to invoke instead of COMMAND.COM.
(In fact, using batch files to control the top-level COMMAND.COM is how fancy GUI menus for DOS avoid stealing memory from the things they launch. You run a batch file, the batch file launches the GUI menu EXE, and the GUI menu EXE rewrites another batch file with your choice before exiting, which the top-level batch file will invoke after it exits so it can ask COMMAND.COM to run something after it's exited and freed the memory. Then, the batch file it wrote loops back around to the main one when it completes.)
ssokolowwrote on 2022-11-15, 06:40:If you're familiar with Linux command-line stuff, it'd be sort of like a launcher GUI using bash -c "$1" to process a user-spec […] Show full quote
If you're familiar with Linux command-line stuff, it'd be sort of like a launcher GUI using bash -c "$1" to process a user-specified command-line . If the user specifies bash as the command, then that becomes bash -c "bash", resulting in a nested bash.
You can test this by creating a test.bat file containing something like this and then creating an MS-DOS Mode PIF for that instead:
1mem /c /p 2pause
That'll get you a mem /c /p readout without first invoking a nested COMMAND.COM
I tried that. When I run the pif from Windows, it bluescreens on me. However, after powering off and on again, it runs the script. You're right, it doesn't load it a second time!
One option to resolve the issue is to attrib -r c:\msdos.sys, then edit msdos.sys and then change the BootGUI=1 line to BootGUI=0 so it won't boot into the GUI until you type win, leaving you running at that initial COMMAND.COM. (As of Windows 95, msdos.sys changed from machine code to a config file.)
This works, but I lose the autoexec.bat and config.sys settings from the PIF file. I assume that I would need to create a new autoexec.bat and config.sys in the c:\ root?
Alternatively, you could do the fun thing and use edit, echo, Alt+219 (keypad numbers only), CHOICE.EXE, and ERRORLEVEL to create your own one-touch batch-file menu for your MS-DOS Mode shortcut to invoke instead of COMMAND.COM.
Thanks, could you please clarify how to do this? Do you mean that I should edit my PIF file from Windows 98?
I just created an autoexec.bat and config.sys in the root of c, so that assumption was correct. I only end up with a single command.com loaded in memory too!
Thanks, could you please clarify how to do this? Do you mean that I should edit my PIF file from Windows 98?
I meant customizing/creating autoexec.bat and config.sys like you did, then creating a file like this with a name like menu.bat, then starting it from autoexec.bat:
1@echo off 2 3:TOP 4cls 5echo. 6echo ████████████████████ 7echo █ Main Menu █ 8echo ████████████████████ 9echo █ 1. Thing One █ 10echo █ 2. Thing Two █ 11echo █ 3. Thing Three █ 12echo ████████████████████ 13echo █ W. Start Windows █ 14echo █ X. Exit Menu █ 15echo ████████████████████ 16choice /C:123WX /N 17cls 18 19IF ERRORLEVEL 5 GOTO END 20IF ERRORLEVEL 4 GOTO WIN 21IF ERRORLEVEL 3 GOTO THING3 22IF ERRORLEVEL 2 GOTO THING2 23IF ERRORLEVEL 1 GOTO THING1 24GOTO TOP 25 26:THING1 27echo Replace me with the command for Thing One 28pause 29GOTO TOP 30 31:THING2 32echo Replace me with the command for Thing Two 33pause 34GOTO TOP 35 36:THING3 37echo Replace me with the command for Thing Three 38pause 39GOTO TOP 40 41:WIN 42win 43GOTO TOP 44 45:END
...or, if you want to get fancy and use characters where I don't have the Alt+ code burned into my memory, something like this:
1@echo off 2 3:TOP 4cls 5echo. 6echo ╔══════════════════╗ 7echo ║ Main Menu ║ 8echo ╠══════════════════╣ 9echo ║ 1. Thing One ║ 10echo ║ 2. Thing Two ║ 11echo ║ 3. Thing Three ║ 12echo ╟──────────────────╢ 13echo ║ W. Start Windows ║ 14echo ║ X. Exit Menu ║ 15echo ╚══════════════════╝ 16choice /C:123WX /N 17cls 18 19IF ERRORLEVEL 5 GOTO END 20IF ERRORLEVEL 4 GOTO WIN 21IF ERRORLEVEL 3 GOTO THING3 22IF ERRORLEVEL 2 GOTO THING2 23IF ERRORLEVEL 1 GOTO THING1 24GOTO TOP 25 26:THING1 27echo Replace me with the command for Thing One 28pause 29GOTO TOP 30 31:THING2 32echo Replace me with the command for Thing Two 33pause 34GOTO TOP 35 36:THING3 37echo Replace me with the command for Thing Three 38pause 39GOTO TOP 40 41:WIN 42win 43GOTO TOP 44 45:END
(I got lazy, so I just wrote that on my Linux PC in gVim by copy-pasting characters from the Wikipedia "Code page 437" article, used set fenc=cp437 to save in the correct encoding, and then tested in DOSBox.)
Thanks again for the advice! I'll try this later when I get home from work. I have a couple of questions.
1. Is there a reason why you are calling menu.bat from autoexec.bat rather than creating the menus in autoexec.bat and config.sys? A lot of people here are using the menu system described by the Phil's Computer Lab guy. They don't call any external files. For me, I wanted to start with something simpler. If I encounter any problems, I can always add menu items later.
2. Under the menu sections (THING1, THING2, THING3), does the regular autoexec stuff go in there? Like would I put the Sound Blaster settings in there?
3. Do you know if setting up an autoexec.bat and config.sys this way affect Windows at all? Previously, I just had the PIF file for DOS mode. If I switch to using the bootgui=0, along with an autoexec.bat and config.sys, would the computer get setup with the DOS stuff before I use win to start Windows or does it get unloaded?
Thanks again for your help and patience. I appreciate it.
1. Is there a reason why you are calling menu.bat from autoexec.bat rather than creating the menus in autoexec.bat and config.sys?
So that if you press X to exit the menu to the prompt, you can type menu to get back into it without restarting your computer or re-running your autoexec.bat stuff.
2. Under the menu sections (THING1, THING2, THING3), does the regular autoexec stuff go in there?
No, that'd be the DOS applications you'd normally launch from Windows icons, so you can conveniently exit one application and start another.
If you want multiple config.sys and autoexec.bat configurations in this paradigm, you use the MENU...config.sys statements introduced with MS-DOS 6.x and then have your autoexec.bat switch behaviour based on the value of %CONFIG% as explained here or here.
(My approach to DOS, even back in the days when I was a kid, was to not accept "you need multiple CONFIG.SYS configurations for different purposes" as an answer until I'd exhausted every other option, because restarting the computer was annoyingly slow and I wanted to avoid restarts whenever possible. These days, thankfully, there's plenty of freeware like 4DOS, ANSIPLUS, UIDE, SHSUCDX, CuteMouse, etc. that can leave tons of conventional memory free and provide richer functionality than I ever had as a kid.)
3. Do you know if setting up an autoexec.bat and config.sys this way affect Windows at all? Previously, I just had the PIF file for DOS mode. If I switch to using the bootgui=0, along with an autoexec.bat and config.sys, would the computer get setup with the DOS stuff before I use win to start Windows or does it get unloaded?
It'll stay there, aside from a few bits like himem.sys which Windows knows how to take over from, because Windows 9x uses MS-DOS as the 16-bit driver compatibility layer. Depending on what you plan to put in your config.sys, it may be best to have separate DOS and Windows options in that config.sysMENU... setup I linked to.
If you have cards with OPTROM installed then use UMBINFO.COM to determine where their ROMs are located and exclude it from arguments for EMM386.EXE.
This is actually very important and I didn't remember that I would specify exclusions and inclusions to completely manually tell emm386 and himem exactly what regions to use and avoid.
I usually use MSD to look at >1Mb memory, to see if it is occupied.
More than option roms can be in the option rom region these days, and silly things can happen if they get mapped out. If there is data there, I try to exclude it until I know what that data is for.
In some cases, the option rom is useless to DOS, such as pxe bioses. Forcing an INCLUDE will basically unmap it, and free it for umb use.