China DOS Union

Or rather, I still feel very unfamiliar with it.

> I once used it under pure DOS to virtualize a Win2003 ISO image file as a CD-ROM drive and perform the installation.

Virtualizing an ISO as a CD-ROM drive under DOS and being able to perform installation does not mean that the ISO file has been completely emulated as a physical CDROM.
I am guessing: does it interpret the sector contents of the ISO file, and then use some MSCDEX-compatible program to turn the CDROM into some DOS drive letter, such as drive H:? This does not operate on the CDROM hardware IO ports. In real mode it is impossible to emulate IO ports. In real mode, IO ports can only access real devices.

If that is the case, then this kind of emulation cannot exist independently of DOS. GRUB's emulation does not depend on DOS, so this method cannot be used to implement it. Although GRUB runs under DOS, GRUB does not use any DOS interrupts or DOS data structures. GRUB only uses BIOS interrupts and BIOS data structures. Because GRUB has to boot other operating systems, GRUB is independent of any particular operating system. Therefore, one cannot emulate a CDROM from an ISO the way BCDL does.

> if it is modified a bit and converted into a real SYS driver, it should not be too difficult, right?

Simply converting a SYS into an EXE, or vice versa, should not be difficult (I do not understand the structure of SYS either). But whether SYS or EXE, they are both concepts used internally by DOS and cannot be borrowed by GRUB. I think it will not work for GRUB to learn from that path. Of course, if what is being discussed is not GRUB but how to boot a system from an ISO file, then it is entirely possible. But I think that implementing this from inside DOS still has a few other small difficulties to face (though not easy to solve) (let us not discuss that now).

> BCDL.BIN itself should not be directly operating on the physical addresses of the CD. Rather, before BCDL.BIN is actually loaded, it first calls a DOS CD-ROM driver program (such as VIDE - CDD.SYS, OAKCDROM.SYS, and the like), and that CD-ROM driver operates on and drives the physical CD. Then BCDL.BIN uses an MSCDEX INT-compatible method to actually load and boot from the CD. If SHSUCDHD.SYS (that is, the SYS version of SHSUCDHD.EXE) were used as that intermediate CD-ROM driver to virtualize an ISO image file, then what BCDL.BIN would see would be a real physical CD-ROM drive, because BCDL.BIN does not directly access the physical addresses of the CD-ROM drive, but only performs the next step according to the already loaded DOS CD-ROM driver.

Because I am not familiar with it, I still do not quite understand this paragraph. BCDL first loads a SYS CD-ROM driver. So can it be said this way: a SYS file runs in a DOS environment? SHSUCDHD.EXE obviously runs under DOS. If a SYS file does not run under DOS, and we want to convert SHSUCDHD.EXE into such a SYS format, then even if the conversion succeeds, I am afraid it still cannot be used. Even if it can be used, there is still another problem: you said BCDL uses an MSCDEX-compatible method to handle the CD, which is equivalent to saying it simulates the ISO as a drive letter under DOS. This can only be used for DOS-compatible operating systems, not for other systems such as LINUX. LINUX does not know drive letters.

Hehe, I am quite muddled, so what I am saying may be rather laughable. If you find I have some unclear concepts, you can continue to point them out and explain them.

GRUB of course does not use DOS interrupts, nor does it provide DOS interrupts. What GRUB for DOS does is only to provide an entry point under DOS, then restore some of the modifications made by DOS drivers/TSR programs, and then call the main body of the original GRUB 0.93 so that it runs in a real non-DOS environment.

But BCDL is exactly the opposite. BCDL's own runtime environment is the same as stage2 in GRUB 0.93; neither uses DOS interrupts, so it can be loaded directly by GRUB through chainloader. But unlike GRUB, according to my research, part of BCDL itself is a DOS interrupt provider (equivalent to a subset of IO.SYS+MSDOS.SYS), so after it runs it can directly call DOS programs. Specifically, BCDL boots from a CD-ROM/RW disc through the following process:

1: Start loading BCDL.BIN, providing DOS interrupts (that is, something like a subset of IO.SYS+MSDOS.SYS);
2: Automatically run the equivalent of the command “DEVICE=VIDE-CDD.SYS”;
3: Run VIDE-CDD.SYS, this pure DOS driver in SYS format;
4: Through the MSCDEX-compatible CD-ROM interface provided by the DOS-style SYS file above, BCDL.BIN actually loads the CD-ROM and boots from it.

From this it can be seen that BCDL.BIN loads the CD-ROM by calling a pure DOS CD-ROM driver in SYS format. This SYS-format file can be any uncompressed DOS driver. For example, if replaced with SCSICD.SYS, it can boot from a SCSI CD-ROM drive. It can even be replaced with other non-CD-ROM SYS files, such as RAMDRIVE.SYS, UMBPCI.SYS, DRFAT32.SYS, etc. Of course, although they can all be loaded by BCDL, because they are not DOS CD-ROM drivers, BCDL cannot use them to boot from CD.

Like other pure DOS CD-ROM drivers (such as the VIDE-CDD.SYS mentioned above), SHSUCDHD.EXE is precisely a true pure DOS CD-ROM driver compatible with the MSCDEX interface. It only needs to be modified into a DOS CD-ROM driver in SYS format (that is, a DOS CD-ROM driver that can be loaded with DEVICE=SHSUCDHD.SYS), and then when BCDL reaches step 4 it will be able to boot from the ISO file.

Now that the SHSUCDHD source code is already above, why not give it a try and modify SHSUCDHD.EXE into a DOS CD-ROM driver in SYS format? Note: SHSUCDHD can be compiled with MASM 6.0. MASM 6.0 can be downloaded here:
http://www.bbs.motion-bg.com/dl.php?file=388

Such an intense discussion. Although I can't understand much of it, I'll still mark it as digest, as a sign of my admiration!
Hope all you experts will participate more and lead us to stop being newbies soon.

The following is quoted from Wengier at 2003-10-3 21:41:09:
GRUB of course does not use DOS interrupts, nor does it provide DOS interrupts. What GRUB for DOS does is only to provide an entry point under DOS, then restore some of the modifications made by DOS drivers/TSR programs, and then call the main body of the original GRUB 0.93 so that it runs in a real non-DOS environment.

But BCDL is exactly the opposite. BCDL's own runtime environment is the same as stage2 in GRUB 0.93; neither uses DOS interrupts, so it can be loaded directly by GRUB through chainloader. But unlike GRUB, according to my research, part of BCDL itself is a DOS interrupt provider (equivalent to a subset of IO.SYS+MSDOS.SYS), so after it runs it can directly call DOS programs. Specifically, BCDL boots from a CD-ROM/RW disc through the following process:

1: Start loading BCDL.BIN, providing DOS interrupts (that is, something like a subset of IO.SYS+MSDOS.SYS);
2: Automatically run the equivalent of the command “DEVICE=VIDE-CDD.SYS”;
3: Run VIDE-CDD.SYS, this pure DOS driver in SYS format;
4: Through the MSCDEX-compatible CD-ROM interface provided by the DOS-style SYS file above, BCDL.BIN actually loads the CD-ROM and boots from it.

From this it can be seen that BCDL.BIN loads the CD-ROM by calling a pure DOS CD-ROM driver in SYS format. This SYS-format file can be any uncompressed DOS driver. For example, if replaced with SCSICD.SYS, it can boot from a SCSI CD-ROM drive. It can even be replaced with other non-CD-ROM SYS files, such as RAMDRIVE.SYS, UMBPCI.SYS, DRFAT32.SYS, etc. Of course, although they can all be loaded by BCDL, because they are not DOS CD-ROM drivers, BCDL cannot use them to boot from CD.

Like other pure DOS CD-ROM drivers (such as the VIDE-CDD.SYS mentioned above), SHSUCDHD.EXE is precisely a true pure DOS CD-ROM driver compatible with the MSCDEX interface. It only needs to be modified into a DOS CD-ROM driver in SYS format (that is, a DOS CD-ROM driver that can be loaded with DEVICE=SHSUCDHD.SYS), and then when BCDL reaches step 4 it will be able to boot from the ISO file.

Now that the SHSUCDHD source code is already above, why not give it a try and modify SHSUCDHD.EXE into a DOS CD-ROM driver in SYS format? Note: SHSUCDHD can be compiled with MASM 6.0. MASM 6.0 can be downloaded here:
http://www.bbs.motion-bg.com/dl.php?file=388

But..... the key point is that shsucdhd.exe needs himem.sys.....

The following is quoted from Roy:
But..... the key point is that shsucdhd.exe needs himem.sys.....

Actually, based on SHSUCDHD's ASM source code, it should be possible to modify it into a standalone pure DOS virtual CD-ROM driver in SYS format (one that does not need HIMEM.SYS and so on). As long as it remains compatible with the MSCDEX interface, BCDL should be able to load it and use it to boot. In that way, directly booting from an ISO file would succeed.

Thanks to all the brothers above. I seem to understand it a bit now. I am preparing to look further into the ASM source code.

I always need to have a clear understanding in my own mind. Let me make another guess. This BCDL loads a SYS program based on DOS. In this MSCDEX-compatible environment, BCDL can read sector data from the CD. As long as it can read sector data, it can boot from the CD.

Although this makes booting from CD possible, the foundation for booting the CD is not purely BIOS, but DOS, or what might be called DOS-like. This DOS-like thing can be regarded as an extension of BIOS (from a positive point of view), and can also be regarded as pollution of BIOS (from the opposite point of view). All these drivers do nothing more than implement the "standard" called MSCDEX, and what that standard actually accomplishes is simply the ability to read the sector contents of a CD. In this way, by promoting the MSCDEX standard, MS forcibly polluted BIOS: you BIOS manufacturers must not provide users with a function for reading CD sectors; only my Microsoft MSCDEX is the standard. If you want low-level operations on CDs, you cannot do without Microsoft.

And the BIOS manufacturers are too foolish as well. Their BIOSes actually already have CD read functions (think about it: if BIOS can boot a CD, that means BIOS can read CD sectors). It is just that the read functions differ between vendors and no standard was formed. They passively run behind Microsoft, completely failing to realize that they themselves are the masters of BIOS! Whatever Microsoft defines becomes the standard. BIOS manufacturers should spontaneously formulate a BIOS int standard for CDs, just like the BIOS standard for disks. This absolutely cannot wait for Microsoft to define it. Microsoft was no good from the very beginning!

How important standards are! Microsoft knows this very well! Without a standard, no matter how powerful your function is, it amounts to nothing; you can only remain in a passive position of getting beaten, and in the end you get swallowed by Microsoft without even realizing it. Not only should CDROM have an int standard, USB and so on should also have int standards. We absolutely must not let Microsoft continue polluting things (in fact Microsoft is still continuing to pollute them).

Back to the main topic.

BIOS originally already has CD read functions, yet after making a huge detour, in the end one still has to rely on some DOS standard called MSCDEX to read sectors. It is simply ridiculous. What MSCDEX accomplishes is nothing more than reading CD sectors. This function is not at all stronger than BIOS (it is only that there is no unified standard).

I used to collect interrupts for reading CDROM sectors under DOS. I knew MSCDEX used int 2f to provide CDROM read functions. It was not until one day when I suddenly discovered that BIOS itself already had a way to read CDROMs that it all dawned on me, and at the same time I felt I had been fooled by Microsoft.

Look at how many CD drivers there are under DOS. Too many, all kinds. Why are there so many? There is only one explanation: different CDs need different drivers. Some CDs still cannot be driven. This shows that even with MSCDEX, CDROM problems still cannot be solved perfectly. How boring MSCDEX becomes then. A problem that was originally simple becomes incomparably complicated the moment it steps in, leaving all technical people exhausted.

For many years it was already possible to boot CDs from BIOS, but unfortunately the one missing word was "unified." BIOS still could not provide an int interface for CDs.

＝＝＝＝＝＝＝＝＝＝

As I said just now, the DOS-like environment pollutes BIOS. Specifically, the DOS-like environment uses interrupts such as int 2f, while real BIOS does not use such interrupts. Here there is a hidden danger. If the operating system booted from the CDROM does not overwrite the int 2f interrupt vector table, it may not matter. But if some program running from the CDROM modifies int 2f, that is disastrous and the system will crash. Although the possibility of problems is not very great, such problems really can occur. As long as there is any possibility of hidden problems, it is not a desirable good method.

＝＝＝＝＝＝＝＝＝＝＝

Taking all of the above together, I will not do this work according to the MSCDEX line of thinking. I hope to look at the relevant source code; perhaps it will help in implementing ISO booting with grub.

I have not completely denied the method of modifying EXE into SYS. If I truly have time, and if I truly find that modifying it is not difficult, I will try it. If I find there are some rather tedious problems, I may have to give up. After all, I still have not learned the structure of SYS files or the related programming conventions. If someone else completes it, I of course support it, since it may be a shortcut. To implement it first, and then later implement it properly with GRUB itself, is of course not contradictory.

Thank you all, and welcome to continue the discussion and express your wise opinions.

The following is quoted from Wengier at 2003-10-3 23:17:39:

The following is quoted from Roy:
But..... the key point is that shsucdhd.exe needs himem.sys.....

Actually, based on SHSUCDHD's ASM source code, it should be possible to modify it into a standalone pure DOS virtual CD-ROM driver in SYS format (one that does not need HIMEM.SYS and so on). As long as it remains compatible with the MSCDEX interface, BCDL should be able to load it and use it to boot. In that way, directly booting from an ISO file would succeed.

That is another layer of obstacle. HIMEM is also from Microsoft. Although the standard itself is not Microsoft's, Microsoft's himem is the de facto industry standard.

The fact that SHSUCDHD enables extended memory shows the problem is relatively complex. I have already lost confidence. Stripping it out is possible, but it will take effort. What is lacking at present is time.

The following is Roy's statement:

“But..... the key point is that shsucdhd.exe needs himem.sys.....”

The following is 不点's statement:

“The fact that SHSUCDHD enables extended memory shows the problem is relatively complex. I have already lost confidence. Stripping it out is possible, but it will take effort. What is lacking at present is time.”

I just tried it myself, and found that SHSUCDHD.EXE does not need HIMEM.SYS or any other XMS extended memory driver. It can in fact be used independently as it is. So what Roy said above, that “shsucdhd.exe needs himem.sys,” is incorrect. Therefore there is no need at all to strip it down or rewrite it.

The following is quoted from Wengier at 2003-10-4 20:46:15:

I just tried it myself, and found that SHSUCDHD.EXE does not need HIMEM.SYS or any other XMS extended memory driver. It can in fact be used independently as it is. So what Roy said above, that “shsucdhd.exe needs himem.sys,” is incorrect. Therefore there is no need at all to strip it down or rewrite it.

そう、そう。。。(Yes, yes...)
I really did get some things wrong.....
Now... here,
I solemnly say:
ごめんなさい！(Sorry!)

Roy has been learning Japanese lately? Or did you learn it from watching Japanese anime since childhood?

The following is quoted from cn_archer at 2003-10-4 22:55:14:
Roy has been learning Japanese lately? Or did you learn it from watching Japanese anime since childhood?

Ha...... both, actually.....

The following is quoted from 不点 at 2003-10-4 17:02:50:
As I said just now, the DOS-like environment pollutes BIOS. Specifically, the DOS-like environment uses interrupts such as int2f, while real BIOS does not use such interrupts. Here there is a hidden danger. If the operating system booted from the CDROM does not overwrite the int2f interrupt vector table, it may not matter. But if some program running from the CDROM modifies int2f, that is disastrous and the system will crash. Although the possibility of problems is not very great, such problems really can occur. As long as there is any possibility of hidden problems, it is not a desirable good method.

From my observation, this worry seems unnecessary, for the following two reasons:

1: The reason BCDL uses the DOS MSCDEX-compatible standard is only that it takes a shortcut by using a DOS CD-ROM driver, which both avoids writing a CD-ROM driver itself and lets it adapt to more CD-ROM drives (because that DOS CD-ROM driver can be replaced). But this does not mean that BCDL itself is performing MSCDEX operations. Rather, it merely uses the shortcut of first driving the CD-ROM through various DOS CD-ROM drivers compatible with MSCDEX, and then uses its own code (a BIOS-like virtualization method, not the MSCDEX method) to complete the actual CD-ROM boot, and it does not provide or use any new interrupts.

2: When BCDL performs step 4 (that is, the final step), before actually booting from the CD-ROM, it restores and resets all DOS interrupts (including that DOS CD-ROM driver loaded earlier), so it can be said that it has no effect at all on the running of programs on the successfully booted CD. These are some observations I made after long-term testing and use.

Taken together, and adding the fact that SHSUCDHD.EXE itself can be used independently (without HIMEM.SYS and so on), then if it is converted into SYS, it should be able to be loaded directly by BCDL, right..

Learned something! Support! Please continue... our Union really needs discussions like this...

From my observation, this worry seems unnecessary, for the following two reasons:

1: The reason BCDL uses the DOS MSCDEX-compatible standard is only that it takes a shortcut by using a DOS CD-ROM driver, which both avoids writing a CD-ROM driver itself and lets it adapt to more CD-ROM drives (because that DOS CD-ROM driver can be replaced). But this does not mean that BCDL itself is performing MSCDEX operations. Rather, it merely uses the shortcut of first driving the CD-ROM through various DOS CD-ROM drivers compatible with MSCDEX, and then uses its own code (a BIOS-like virtualization method, not the MSCDEX method) to complete the actual CD-ROM boot, and it does not provide or use any new interrupts.

2: When BCDL performs step 4 (that is, the final step), before actually booting from the CD-ROM, it restores and resets all DOS interrupts (including that DOS CD-ROM driver loaded earlier), so it can be said that it has no effect at all on the running of programs on the successfully booted CD. These are some observations I made after long-term testing and use.

Taken together, and adding the fact that SHSUCDHD.EXE itself can be used independently (without HIMEM.SYS and so on), then if it is converted into SYS, it should be able to be loaded directly by BCDL, right..

The key question is: just how big is the difference between a real CD-ROM driver and the ISO CD emulation program SHSUCDHD.EXE? If the difference is not great, I estimate the author of SHSUCDHD.EXE could also conveniently write it as a SYS file. So I suspect there may be some obstacle here that is hard to overcome.

According to what you just said in point 1, BCDL's support for real CD-ROM drives may mainly be at the hardware level, that is, it may be based on the IO device interface specification for ATAPI CDROM. If so, then one can basically conclude that BCDL cannot boot ISO files. Because that hardware specification is not applicable to software; it is not an int specification .

On the surface, the difference between this SYS and EXE does not seem great; that is only in terms of file format, and perhaps the essential difference in implementation method has not been explored. I do believe SYS can exist apart from DOS, because SBM also uses this method to implement booting from a real CD-ROM drive.

Simply booting from ISO is also possible. SHSUCDHD.EXE has already done it. However, what I have always worried about is forcibly piecing together two things that are completely unrelated. To be honest, reading someone else's program is not necessarily easier than writing a program yourself. Before, I looked at SBM's program and originally wanted to use it to write the CD emulation program for GRUB for DOS, but I gave it up. The reason was that it used the ATAPI specification, which I cannot adopt, or rather, which I oppose. This is a hardware specification; CDROM and BIOS manufacturers can use such a specification, but we should not. To transform SBM so that it can boot from an ISO file is practically impossible unless a large amount of code is added, and that is no different from programming it again from scratch.

The same reasoning applies to BCDL. If it depends heavily on hardware specifications such as ATAPI, then it will be hard to use it to boot ISO files. What it drives is hardware; in the end it has to call hardware instructions to boot from the CD. When it calls the program inside a hypothetical SHSUCDHD.SYS, the response from those programs is soft, and the hardware response expected by the caller (hardware interrupt) will never appear, making it completely useless.

Perhaps SHSUCDHD.EXE is self-contained. It can handle ISO emulation, using another specification: the bootable CDROM specification. This specification is indeed relatively soft, because it does not involve hardware. Any method of booting ISO files has to use this specification. In the future, when I use GRUB for DOS to implement ISO booting, of course I will also have to use this specification. Assuming SHSUCDHD.EXE really does use this specification, then it will be hard to merge it with programs like BCDL and SBM. One is hard, one is soft; they are going in completely opposite directions.

I took a rough look at the SHSUCDHD.EXE program, and it is full of HACKs on DOS everywhere. He is probably trying to restore interrupt vectors modified by DOS, or something else. In any case, it is hard to read. I do not have time to study it carefully. In the future, when I program this in GRUB, I will not use it; I will directly use the "bootable CDROM specification" mentioned above.

What I want to implement in GRUB is precisely this sort of unification: to handle both existing boot methods in a unified way, and create an "ultimate" perfect solution.

The bottleneck here is the hardware specification used by BCDL and SBM, and that is the fundamental reason why hard and soft cannot be unified. Forcibly sticking the two together is not impossible, but the effort required would not be small, and may be enormous, not worth the cost. Reprogramming from scratch may actually be easier.

Instead of using the hardware specification, one could write a BIOS patch program and add the CD sector read function into int 13h. That would settle everything once and for all; there would be no problems at all. In the case of ISO files, we could even write to the ISO file! This would be useful for creating a new ISO file from an empty img file. The prospect I am describing is a beautiful one, isn't it? Of course, implementing it would also take quite a lot of time.

Thanks to everyone for providing background materials, and welcome to continue expressing your wise opinions.

Since there is no BCDL source code and no detailed documentation explaining its working principles, it is indeed impossible to say whether what BCDL expects is "soft" or "hard."

However, if GRUB writes a patch for BIOS, although it may achieve some very beautiful functions, since BIOS CD read functions originally have no standard, can this GRUB patch really be made universal? Also, what if the BIOS itself does not support CD booting in the first place (for example, one of my computers is like that)?