179 replies to this topic

[tinybit]

>>> Unfortunately, I do not understand why you expect it to work on a buggy system without GRUB4DOS.

 

Sorry, it is my bad, I failed to explain it clearly. The special build of my eltorito.sys should work smoothly on allmost all systems without grub4dos. Or else I should not have released it. On boot-up, grub4dos itself also check CD-ROMs downward from 0xFF to 0x80. See this code in common.c of grub4dos. This means scanning downward will work just fine with a vast majority of systems(if not all). On a problematic machine(which causes hangup), grub4dos will also hangup at bootup stage. My special build of eltorito.sys will work OK on any machine that can boot up grub4dos successfully. If a problematic machine is found, both grub4dos and the special eltorito.sys need a fix. Yes, a fix(or a workaround) surely exists(and it can be done) for a problematic machine, theoretically. We cannot say "there will never be any fix for a particular buggy machine".

 

You are so kind to try to discuss it with me in Chinese. I think Chinese is too difficult for non-native people. And google translate could make mistakes. I think we'd better continue to use English.

[tinybit]

What is unsafe? A user has to choose to use this option, otherwise the behaviour is the same as old.

 

 

Since my special eltorito.sys is supposed to have solved ALL problems, so any patch to grub4dos is unneeded. Besides, the patch occupies some bytes of space reserved for the 12K int13/int15 handler, so it is likely to be cancelled when there is a good reason in the future. If another developer need many bytes of the 12K handler space to fix a bug or to just add new features, he could cancel your patch. So it is unsafe for users who rely on this patch. It is very likely the patch will be cancelled.

[tinybit]

No harm in having both fixes - is there?

 

 

As explained above, only one fix is possibly no harm, whereas the other fix is potentially harmful, because it occupied some bytes of the valuable handler space, seeing that the hadler space has an upper limit of 12KB.

[Sha0]

Since my special eltorito.sys is supposed to have solved ALL problems, so any patch to grub4dos is unneeded. Besides, the patch occupies some bytes of space reserved for the 12K int13/int15 handler, so it is likely to be cancelled when there is a good reason in the future. If another developer need many bytes of the 12K handler space to fix a bug or to just add new features, he could cancel your patch. So it is unsafe for users who rely on this patch. It is very likely the patch will be cancelled.

You were right about our correspondence.  Yesterday I was trying to use Google Translate to write a private message to you, but it was very difficult.

 

The special ElTorito.sys does not solve all problems.  Either my criticisms are not understandable, or you have not yet responded to the points.

 

1. Having two versions of eltorito.sys means that there are two in circulation.  This is a support problem, as it means asking the person with the problem which version of eltorito.sys they are using.
2. Having tinybit-eltorito.sys scan the same way as GRUB4DOS scans means it will fail with the same BIOSes as GRUB4DOS would fail on.  This is a problem, as the current Syslinux' eltorito.sys does not fail on those BIOSes.  I agree that such BIOSes can be reported and work-arounds for both GRUB4DOS and tinybit-eltorito.sys can be developed, but that doesn't change that Syslinux' eltorito.sys does not need those work-arounds.
3. Depending on scan order is not correct, since EDD-4 does not state that the value of the DL register is significant for the query.  There are programs other than eltorito.sys which do not rely on scan order.  tinybit-eltorito.sys does not help those programs, because they do not use it.  BIOSes which give the same DL output regardless of the DL input do not have a bug; they are doing what's expected.
4. tinybit-eltorito.sys does not help a user to choose which optical disc drive number they want to use; they are forced to use 0xFF.
   1. For example, if they choose 0xFE, then BIOS can behave badly if 0xFF is scanned first.
   2. For example, BIOS or an INT 0x13 hook can report that a different El Torito drive 0xFF is at 0xFF, but the user wants to use the one they put at 0xFE.

If I have made any mistakes, please let me know!

[tinybit]

OK, I only response to this(because of the time): "but that doesn't change that Syslinux' eltorito.sys does not need those work-arounds."

 

Then users may use a special build of grub4dos for this purpos.

 

It appears to me there are no reports on the failure of scanning at 0xFF. It just be treated as(or supposed) there are problems. Is there any report on the failure? I mean, a bug report for syslinux.