China DOS Union

To All:

Implementing a startup menu under the pure DOS layer (excluding the boot layer before DOS startup and the application layer after DOS startup) usually uses the Config/Autoexec files for configuration. However, this configured menu is limited by the DOS kernel and cannot be extended more functionally.

Therefore, using a shell - layer application to extend the startup menu is a relatively short cut. But due to the closed nature of the DOS startup process, it is not very easy to insert our own extended menu in it; because the selection of the startup menu may mean the loading of different drivers, so the extension must be executed before the driver is loaded, which restricts the position of the extension program to the config.sys file, before any driver loading and DOS configuration statements. At the same time, the processing method of DOS for config.sys is relatively unique, similar to the compilation environment of a high - level language. They will pre - process config.sys first and then symbolize it, and Boot.sys/bootcon.sys and so on use the "gaps" in these processing processes to relatively typically realize the extension of the startup menu.

However, any extended program is not omnipotent and may not fully meet the user's usage needs. So it is necessary to allow users to customize the menu functions. But no one will study the DOS kernel just for the function of extending the startup menu. So it seems necessary to create a "slot" that can accommodate user - written menu "plugins".

I put this slot in autoexec.bat because various resources of the application layer such as batch processing, third - party scripts, and graphical interface menus can be conveniently used in it. The basic idea is as follows: After the first startup of DOS, directly single - boot into autoexec.bat. In it, create a custom menu interface and complete the interaction with the user. Then, according to the interaction result, generate a new config/autoexec file, which contains various device drivers, program calls, and environment configuration commands required by the user's selection as well as an entry to restore the original c/a files. Then, reboot DOS without restarting the computer to load the new config/autoexec file. After that, restore the original c/a files and wait for the user's next restart.

The implementation idea of this "secondary boot" has actually been implemented by many DOS boot enhancement programs. But they also made closed interfaces, and it is difficult for users to carry out secondary development; at the same time, most of them use restart instead of re - boot to load the new menu, so such a startup menu has a large "startup gap".
(To be continued...)

[ Last edited by willsort on 2006 - 1 - 8 at 16:54 ]

I'm discussing with netizens whether it's possible to return to the CD main menu directly from DOS without rebooting. After seeing the moderator's post, I feel that this hope may be realized soon, looking forward to the moderator's "Please listen to the next installment"!!!

It's a technical problem. Can we implement the option to choose to boot from a floppy disk, hard disk or CD - ROM at startup without using Grub or Jo.sys?

Good idea! If it succeeds, it will be much more convenient to extend DOS in other ways!

To All:

The technical core of realizing the expansion of the boot configuration menu through secondary booting lies in how to achieve the second booting process. The first thing I thought of was the existing boot loading interrupt INT19 provided by BIOS, which is the simplest and most direct method. A two-byte program can be implemented by writing in DEBUG. For friends who are not familiar with DEBUG, create the following script as a batch file and then click to run to get the reboot.com reboot program.

It should be noted that the operation of reboot.com must be in the real mode environment, and so far, I haven't heard of an independent software that can reboot the system in protected mode. Therefore, it doesn't work for Windows, and in DOS, it usually requires that EMM386.EXE and any TSR programs are not loaded.

I quickly completed the test. In the MSDOS6.22 hard disk environment of the virtual machine, its work performance is still relatively good. It successfully realized the non-restart boot method; only before rebooting, it will first detect the floppy drive. If there is a bootable floppy disk in it, it will immediately boot from the floppy disk; if not, a prompt to select the boot device will appear, and it will boot from the hard disk after waiting for a carriage return confirmation. As for the boot priority setting in BIOS, it is completely ignored.

But in the MSDOS7.10 hard disk environment of the virtual machine, a more serious problem occurred: after rebooting, there is still the problem of first searching for the floppy drive; not only that, if no bootable floppy disk is found, it will first prompt that the operating system is not found (it is guessed that BIOS does not recognize the DOS boot sector of MSDOS7.10), then prompt to select the boot device, and then after confirming three times by carriage return, the system hangs and has no response anymore.

And in the real mode command line of the Win98 hard disk environment of the virtual machine, although there is still a prompt that the operating system is not found, it will still reboot normally.

So I searched some information about INT19 , and finally determined that simply using INT19 cannot meet the current needs.

Batch script to generate reboot.com

@echo off

if exist %0.bat set _me=%0.bat

if exist %0 set _me=%0

if not "%_me%"=="" debug < %_me% > nul

set _me=

goto end



a

int19

ret



n reboot.com

r cx

3

w

q



:end

Reboot and Select proper Boot device

Reboot and Select proper Boot device
or Insert Boot Media in selected Boot device

OS not found

OS not found
Install an OS on this hard drive

INT 19 - SYSTEM - BOOTSTRAP LOADER

INT 19 - SYSTEM - BOOTSTRAP LOADER
Desc: This interrupt reboots the system without clearing memory or restoring
interrupt vectors. Because interrupt vectors are preserved, this
interrupt usually causes a system hang if any TSRs have hooked
vectors from 00h through 1Ch, particularly INT 08.
Notes: Usually, the BIOS will try to read sector 1, head 0, track 0 from drive
A: to 0000h:7C00h. If this fails, and a hard disk is installed, the
BIOS will read sector 1, head 0, track 0 of the first hard disk.
This sector should contain a master bootstrap loader and a partition
table (see #00650). After loading the master boot sector at
0000h:7C00h, the master bootstrap loader is given control
(see #00653). It will scan the partition table for an active
partition, and will then load the operating system's bootstrap
loader (contained in the first sector of the active partition) and
give it control.
true IBM PCs and most clones issue an INT 18 if neither floppy nor hard
disk have a valid boot sector
to accomplish a warm boot equivalent to Ctrl-Alt-Del, store 1234h in
0040h:0072h and jump to FFFFh:0000h. For a cold boot equivalent to
a reset, store 0000h at 0040h:0072h before jumping.
VDISK.SYS hooks this interrupt to allow applications to find out how
much extended memory has been used by VDISKs (see #00649). DOS 3.3+
PRINT hooks INT 19 but does not set up a correct VDISK header block
at the beginning of its INT 19 handler segment, thus causing some
programs to overwrite extended memory which is already in use.
the default handler is at F000h:E6F2h for 100% compatible BIOSes
MS-DOS 3.2+ hangs on booting (even from floppy) if the hard disk
contains extended partitions which point at each other in a loop,
since it will never find the end of the linked list of extended
partitions
under Windows Real and Enhanced modes, calling INT 19 will hang the
system in the same was as under bare DOS; under Windows Standard
mode, INT 19 will successfully perform a cold reboot as it appears
to have been redirected to a MOV AL,0FEh/OUT 64h,AL sequence
BUG: when loading the remainder of the DOS system files fails, various
versions of IBMBIO.COM/IO.SYS incorrectly restore INT 1E before
calling INT 19, assuming that the boot sector had stored the
contents of INT 1E at DS:SI instead of on the stack as it actually
does

Excuse me, "Xiaotian", why is it necessary to "use secondary booting to achieve DOS boot menu extension", and where is this need? Can you give an example

Re: DOSforever:

The demand-related issues I mentioned in the main thread. Now, I explain the original intention of my main thread.

When I was making the Chinese boot menu for the Wengier Super Boot Disk, I found that various menu extension programs didn't fully meet my ideal requirements, and the design style was too rigid. So I wanted to improve it myself; but I'm only good at batch processing. Writing a menu interface with wbat and other tools is okay, but it's really difficult to track the DOS boot process and insert my own code. That's why I thought of designing a "slot" that can easily insert various extended menu plugins to meet my needs.

I believe there are many friends who want to design their own boot menu functions and customize unique style interfaces, who are proficient in one or several of C, Basic or other DOS programming languages and tools, but may not be very familiar with assembly language and the DOS boot process. It seems a bit extravagant to specifically learn these contents for the boot menu.

In addition, there are two ideas for achieving reboot:
1. The Win9x system has the "Exit to DOS" function. This may be the only example of achieving reboot in protected mode. However, in many cases, it completes a restart rather than a reboot, and the code tracking of the Win9x system is too difficult.

2. In real mode, load the boot sector code of the disk where reboot is located into memory, and then use a method similar to GRUB to directly call the BIOS boot code bypassing the INT19 interrupt; this method has multiple problems such as how to restore the interrupt vector table and how to determine the boot medium. I'm a layman in this aspect, a lot of things are still in the exploration stage. I'm currently studying dosstart.S of GRUB for DOS, but it's very difficult because I have no assembly foundation.

Here, I specially ask Brother Budian, the author of GRUB for DOS: According to my description above, can a specialized GRUB for DOS be designed? It can run in the DOS command line or batch processing environment, can complete booting again from the last boot device directly without menu selection. Considering the needs of the boot disk, the program volume should be as small as possible. If this idea is not very practical, then can the existing GRUB for DOS be used to complete the above functions?

At the same time, I ask Brother Ben Shi, the author of the text mode Chinese character display tool VTMagic: Are the font patterns of extended ASCII characters and basic ASCII characters stored at different addresses in ROM/RAM? Will the font pattern information in memory be restored when the text mode is initialized? Can it be implemented in a way that it won't be restored after reboot?

[ Last edited by willsort on 2006-1-11 at 16:58 ]

It may be related to the fact that I didn't make a boot disk using the "menu extension program". I did read your main post and your current reply, but I still can't see the necessity of using the "menu extension program" to extend the menu. Can't the multiple configuration menus of DOS itself not meet the requirements?

Re: DOSforever:

You can refer to the following topics in the localization room regarding DOS startup. In them, I have mentioned the limitations of the DOS system startup menu and menu extension programs and the reasons for implementing custom extensions.

A startup control tool much more powerful than BOOTCON.SYS plus CONFIG.CTL
http://www.cn-dos.net/forum/viewthread.php?tid=18464&fpage=1

Can Chinese characters be displayed without loading a Chinese character system?
http://www.cn-dos.net/forum/viewthread.php?tid=6916&fpage=1

Thanks to "Xiaotian" for going to the trouble of finding the post. Since there is too much and too long content, I didn't read every line carefully, but just took a general look. My understanding is that everyone just wants to implement multi - choice functions in the configuration menu. I looked at version 1.42 of BOOT.SYS, which provides the function of starting menu to select system configuration for MS - DOS, and compared it with the multi - configuration selection function built into MS - DOS:

√ * Supports single - layer menu, continuous menu, multi - layer nested menu (not clear what a continuous menu is)
√ * Up to 9 menu items per menu (each in one line), and a prompt area can be customized above (the same as provided by MS - DOS)
* Can have 25 continuous menus in total, each with different system configurations
√ * Sub - menus can be nested up to 25 layers (not tried how many layers MS - DOS allows at most)
√ * Menu selection can be done by entering the number key or moving with the arrow (the same as MS - DOS)
√ * Each menu can customize the countdown time and default option (the same as MS - DOS)
√ * Fully supports DOS = and other new commands starting from MS/PC - DOS 5.00 (needless to say)
* Supports switching from LCD notebook to external monitor (this should depend on the notebook itself having this function, not related to software)
* Supports editing the content of CONFIG.SYS lines on - site during startup (this seems to be a function that no DOS has)
* Resident occupies less than 200 bytes of DOS memory (does not occupy memory in DOS 6.0 and above! ) (needless to say, does not occupy any memory)

The ticked places are functions also supported by MS - DOS. Other functions, such as automatic selection of a certain item after timeout and menu color selection, are all supported. The only shortcoming of MS - DOS multi - configuration that I see is that it cannot display Chinese, but this is not important. It's not that my English is good, but generally computer English is very simple, and there is no need to localize it. Unless it is to provide it as a practical software for beginners. Another point is that it does not support checkboxes (probably the continuous menu refers to this), but the same function can be realized through multi - configuration, although it is more cumbersome. The following content of CONFIG.SYS is a boot disk I made many years ago based on MS - DOS 6.22. The "Chinese" displayed in it is actually Western tab characters. After this CONFIG.SYS is started, it can mainly realize the following selections:

1. Select what to use as the memory management program
2. Select what to use as the command interpreter
3. Select the way of memory use, namely XMS, EMS
4. If QEMM386 is selected as the memory manager, you can also select whether to use the ordinary UMB use method or the unique Stealth method
5. If the unique Stealth method is used, then select whether the Stealth method is MAP method or FRAME method

After entering each sub - menu, you can have a menu to return to the upper level menu. In fact, MS - DOS also provides a one - key return function, but to return, you will return directly to the root menu. Just make such a change to realize returning level by level.

Now it seems that this boot disk is very "old - fashioned" and does not support many new functions, such as USB, long file names, and NTFS support. I have always wanted to make a new boot disk, but I haven't found satisfactory "materials" yet, and I'm still comparing the advantages and disadvantages of various "materials". I send out the content of this CONFIG.SYS just to for everyone to comment on, playing a role in drawing out what is valuable. Also, discuss whether it is necessary to use other software to expand the DOS boot menu. (Except for special cases where the function of editing the content of CONFIG.SYS lines on - site during startup is needed)

SUBMENU=QUARTERDECK,Memory Managed by Quarterdeck QEMM386.SYS Version 8.0

SUBMENU=MICROSOFT,Memory Managed by Microsoft HIMEM.SYS V3.10 + EMM386.EXE V4.49

MENUDEFAULT=QUARTERDECK,5

MENUCOLOR=3,0



REM ============================================================================



  

  SUBMENU=QEMM-NDOS,NDOS.COM command interpreter Version 8.0

  SUBMENU=QEMM-COMMAND,COMMAND.COM command interpreter Version 6.22

  SUBMENU=MENU,Return to main MENU

  MENUDEFAULT=QEMM-NDOS,5

  MENUCOLOR=0,2



    

    SUBMENU=Q-X&E-N,XMS & EMS

    MENUITEM=Q-X-N,XMS Only (No EMS)

    SUBMENU=QUARTERDECK,Return to upper menu

    MENUDEFAULT=Q-X&E-N,5

    MENUCOLOR=15,2

    

    SUBMENU=Q-X&E-C,XMS & EMS

    MENUITEM=Q-X-C,XMS Only (No EMS)

    SUBMENU=QUARTERDECK,Return to upper menu

    MENUCOLOR=14,2



      

      MENUITEM=QnEMS&N,Normal EMS

      SUBMENU=ST&N,StealthROM

      SUBMENU=QEMM-NDOS,Return to upper menu



        

        MENUITEM=STM&N,StealthROM Mapping Method

        MENUITEM=STF&N,StealthROM Frame Method

        SUBMENU=Q-X&E-N,Return to upper menu



      

      MENUITEM=QnEMS&C,Normal EMS

      SUBMENU=ST&C,StealthROM

      SUBMENU=QEMM-COMMAND,Return to upper menu



        

        MENUITEM=STM&C,StealthROM Mapping Method

        MENUITEM=STF&C,StealthROM Frame Method

        SUBMENU=Q-X&E-C,Return to upper menu





INCLUDE=Q_XMS&EMS

INCLUDE=QEMM_COMMON

INCLUDE=NDOS





INCLUDE=STEALTH_M

INCLUDE=QEMM_COMMON

INCLUDE=NDOS





INCLUDE=STEALTH_F

INCLUDE=QEMM_COMMON

INCLUDE=NDOS





INCLUDE=Q_XMS

INCLUDE=QEMM_COMMON

INCLUDE=NDOS





INCLUDE=Q_XMS&EMS

INCLUDE=QEMM_COMMON

INCLUDE=COMMAND





INCLUDE=STEALTH_M

INCLUDE=QEMM_COMMON

INCLUDE=COMMAND





INCLUDE=STEALTH_F

INCLUDE=QEMM_COMMON

INCLUDE=COMMAND





INCLUDE=Q_XMS

INCLUDE=QEMM_COMMON

INCLUDE=COMMAND





REM ============================================================================





  

  SUBMENU=HIMEMM-NDOS,NDOS.COM command interpreter Version 8.0

  SUBMENU=HIMEMM-COMMAND,COMMAND.COM command interpreter Version 6.22

  SUBMENU=MENU,Return to main MENU

  MENUCOLOR=10,1



    

    MENUITEM=MS-X&E-N,XMS & EMS

    MENUITEM=MS-X-N,XMS Only (No EMS)

    SUBMENU=MICROSOFT,Return to upper menu

    MENUCOLOR=15,1

    

    MENUITEM=MS-X&E-C,XMS & EMS

    MENUITEM=MS-X-C,XMS Only (No EMS)

    SUBMENU=MICROSOFT,Return to upper menu

    MENUCOLOR=14,1





INCLUDE=HIMEMM-X&E

INCLUDE=NDOS





INCLUDE=HIMEMM-X

INCLUDE=NDOS





INCLUDE=HIMEMM-X&E

INCLUDE=COMMAND





INCLUDE=HIMEMM-X

INCLUDE=COMMAND







REM ============================================================================







REM   赏屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯突

REM   ? The following paragraph is configuration modules  ?

REM   韧屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯屯图







DEVICE=A:\QEMM\DOS-UP.SYS REPORT

DEVICEHIGH=A:\QEMM\QDPMI.SYS VMOFF



Rem 谀哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪目

Rem ?The following section is QEMM module ?

Rem 滥哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪馁

Rem The first line is utility parameters of QEMM386.SYS device driver

;DEVICE=A:\QEMM\QEMM386.SYS BK RAM NW3 ST:M|F BE:N BF:N SORT DBF=2 EMS:N SUS=N FILL:N XBDA:H USEXMS:N





DEVICE=A:\QEMM\DOSDATA.SYS REPORT

DEVICE=A:\QEMM\QEMM386.SYS RAM BF:N BTO:30





DEVICE=A:\QEMM\DOSDATA.SYS REPORT

DEVICE=A:\QEMM\QEMM386.SYS RAM ST:M BF:N BTO:30





DEVICE=A:\QEMM\DOSDATA.SYS REPORT

DEVICE=A:\QEMM\QEMM386.SYS RAM ST:F BF:N BTO:30





DEVICE=A:\QEMM\DOSDATA.SYS REPORT

DEVICE=A:\QEMM\QEMM386.SYS RAM BF:N BTO:30 EMS:N





Rem 谀哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪目

Rem ?The following section is HIEMM+EMM386 module ?

Rem 滥哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪馁





DEVICE=A:\DOS\HIMEM.SYS /V

DEVICE=A:\DOS\EMM386.EXE RAM M3 HIGHSCAN I=B000-B7FF /V



DEVICE=A:\DOS\HIMEM.SYS /V

DEVICE=A:\DOS\EMM386.EXE NOEMS HIGHSCAN I=B000-B7FF /V







DEVICEHIGH/L:1=A:\DOS\TRICDVD.SYS /DISC0000

DEVICEHIGH/L:1=A:\DOS\ANSI.SYS/X/R

DEVICEHIGH?=A:\DOS\RAMDRIVE.SYS 1536 /E

DEVICEHIGH?=A:\DOS\RAMDRIVE.SYS 1536 /A

DEVICEHIGH?=A:\DOS\RAMDRIVE.SYS 4096 /E

DEVICEHIGH?=A:\DOS\RAMDRIVE.SYS 4096 /A

DEVICEHIGH?=A:\DOS\RAMDRIVE.SYS 16384 /E

DEVICEHIGH?=A:\DOS\RAMDRIVE.SYS 16384 /A

DEVICEHIGH?=A:\DOS\RAMDRIVE.SYS 32767 /E

DEVICEHIGH?=A:\DOS\RAMDRIVE.SYS 32767 /A

BUFFERS=45,0

FILES=20

DOS=UMB

LASTDRIVE=Z

FCBS=1,1

DOS=HIGH

;STACKS?=0,0

STACKS=9,256

SWITCHES=/F

NUMLOCK=ON

DRIVPARM?=/D:0/S:18/T:82





SHELL = A:\COMMAND.COM/P/E:512/MSG





REM

REM The following section was added by Norton Utilities Install

REM

SHELL = A:\NDOS.COM @A:\NDOS.INI /P

Re DOSforever:

I saw your reply a long time ago, but due to personal reasons and not further gaining something on this topic, I didn't reply in time. Please understand.

The implementation of the startup configuration menu at the DOS layer should have multiple options. The most commonly used Config/Autoexec meets the general usage needs of most users. Bootcon / boot.sys, etc., meet the needs of a few users to preload drivers or configuration programs and some other needs in advance. However, as you found, this is not all the needs. I focus on putting forward four examples where the two cannot be realized here, including the ones you mentioned before.

1. Custom menu style
There are many menu styles, but the ones we can choose are only a few items such as background color/foreground color, menu title, menu item prompt, etc. Various styles such as menu background image, menu item layout, diversified dynamic prompt of the menu, drop-down list of the menu, etc., may be practical needs for many design developers.

2. Checkbox of menu items
The continuous menu of boot.sys is actually only an approximate check. In order to select multiple device drivers, it is necessary to answer whether multiple driver loads are selected, which is an inefficient and mechanical design. As for the way of c/a selecting loading by enumerating all possible device driver combinations, it is only applicable when there are few drivers. If there are three devices available for selection, then there will be 8 permutations and combinations in the enumerated menu options. If there are more devices, there will only be hierarchical selection, still not solving the fundamental problem. I also have the same objection to the way of loading selection of ramdrive in your config.

3. Dynamic editing of menu items
The dynamic editing of boot.sys can only realize the editing of single-line specified statement parameters, but cannot realize the editing of statement commands. As for the overall editing of menu item content similar to Grub and the editing of the menu items themselves (addition, reduction, change of order, menu prompt, default selection, etc.) that I need, it is even out of the question.

4. Free switching of Chinese and multi-languages
To realize the internationalization of the startup menu, it is not simply using one language such as Chinese or English, but realizing the compatible display and dynamic switching of menu languages through multi-language packs. This has been implemented in many places.

The above-mentioned things will be very difficult to implement in config.sys, so I have the idea of transferring it to autoexec and calling external programs through batch processing.

In addition, because I have been unable to contact Brother Budian, the implementation of reboot is temporarily stalled. I hope you and everyone can offer suggestions together to complete this topic.

Is the LZ done? Waiting...

willsort:
Your idea of using a secondary boot to implement DOS boot menu extension is great. It's exactly what I need. I hope it can be implemented as soon as possible and be easy for beginners like me to extend.
Under the pure DOS layer, I want to load an.img larger than 5M and let it boot again. Please help.
Thanks

I think, why is it so troublesome. Just modify the master boot sector of the floppy disk or hard disk, isn't it okay