[FREELDR] Simplify some control branches in loops (#7417)

Collapse some tests; remove redundant `continue;`

Pointed out by Serge Gautherie.

[FREELDR] Change GEOMETRY "Sectors" to "SectorsPerTrack" and introduce a new "Sectors" field (#7379)

----
Thanks to the following testers!
- Dmitry Borisov (@disean) for testing on NEC PC-98 emulato

[FREELDR] Change GEOMETRY "Sectors" to "SectorsPerTrack" and introduce a new "Sectors" field (#7379)

----
Thanks to the following testers!
- Dmitry Borisov (@disean) for testing on NEC PC-98 emulator;
- Justin Miller (@DarkFire01) for testing on UEFI platform;
- Stanislav Motylkov (@binarymaster) for testing on Xbox emulator
(xemu), both livecd and bootcd.
----

"SectorsPerTrack" is for the legacy Cylinders/Heads/Sectors(PerTrack)
scheme.

- On BIOS-based PCs, INT 13h can return (for LBA-only drives) an invalid
geometry, like: C/H/S = (-1)/(-1)/(-1). This is also what happens in
our hwide.c driver (see IdentifyDevice() for ATAPI devices):
https://github.com/reactos/reactos/blob/db419efbf26c78e39fb57bcaf4f9e4d915d0c96e/boot/freeldr/freeldr/arch/drivers/hwide.c#L918-L928

as well as on VirtualBox for CD-ROMs:
https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/PC/BIOS/disk.c#L155

- Therefore, we cannot reliably calculate a valid total number of sectors
by multiplying the Cylinders*Heads*SectorsPerTrack values. In addition,
such a multiplication could overflow a 32-bit ULONG.
Thus, a separate ULONGLONG Sectors member is required to hold such a
value, that is retrieved differently. For example for ATAPI devices,
our hwide.c driver does return a valid TotalSectors value, even though
CHS values are invalid. Other platforms, like UEFI, just work using
logical block addressing (LBA) values (see EFI_BLOCK_IO_MEDIA).

- uefidisk.c : Per the spec, EFI_BLOCK_IO_MEDIA::LastBlock contains
"The last LBA on the device. [...] For ATA devices, this is reported
in IDENTIFY DEVICE data words 60-61 (i.e., Total number of user
addressable logical sectors) _minus one_.
For SCSI devices, this is reported in the READ CAPACITY parameter
data 'Returned Logical Block Address field' _minus one_."
In other words, LastBlock is a zero-based LBA index quantity. The
corresponding total number of valid "sectors"/blocks of the device
is therefore, (LastBlock + 1).

- Cleanup some old disabled code.

show more ...

[FREELDR] i386/pc/pcdisk.c: Fix LBA reads retry loop (#7367)

When the Int 13h AH=42h "Extended read" function fails, the disk address
packet's LBA block count is reset to the number of blocks that h

[FREELDR] i386/pc/pcdisk.c: Fix LBA reads retry loop (#7367)

When the Int 13h AH=42h "Extended read" function fails, the disk address
packet's LBA block count is reset to the number of blocks that have been
successfully transferred. This is more or less fine, unless one wants to
ensure the exact number of sectors gets read.

If the function fails so that zero sectors were read, the retry loop is
restarted, but with the packet's LBA block count member reset, as per
the documentation. (In this example, it is reset to zero.) Then, at the
next retry attempt, zero sectors are requested to be read, and this time
of course, the call succeeds... Wrongly, of course, this is not what's
expected.

Therefore, for each retry, the LBA block count member should be set
again to the correct number of sectors to read. There are maximum 3
retries, so the retry loop will stop anyway, but the LBA read will now
correctly fail and return FALSE, as expected.

This problem doesn't exist in the retry loop for the Int 13h, AH=02h
"Read Disk Sectors" CHS function, because here, the call is made only
using registers, and we use a pair of RegsIn/RegsOut. RegsOut receives
the modified register values, but the input RegsIn stays unchanged.

show more ...

[FREELDR] Fix the seg:off values when dumping the extended drive parameters (#7367)

(By the way, it's "EDD": "Enhanced Disk Drive", not "EED"...)

The 13th and 14th USHORTs (at offsets 0x1A-0x1D) in

[FREELDR] Fix the seg:off values when dumping the extended drive parameters (#7367)

(By the way, it's "EDD": "Enhanced Disk Drive", not "EED"...)

The 13th and 14th USHORTs (at offsets 0x1A-0x1D) in the retrieved buffer
from the INT 13h, AH=48h "Get Extended Drive Parameters" function,
correspond respectively to the offset and the segment of the "EDD
configuration parameters", see http://www.ctyme.com/intr/rb-0715.htm

Fixes code introduced in commit b3f11cfb38 (r17484).

----

16 years ago, these values were wrongly stored in the returned buffer
by VirtualBox, see https://www.virtualbox.org/ticket/2848 .
This has been fixed since VBox 2.1.0 in commit 15712 (22 Dec. 2008):
https://www.virtualbox.org/changeset/15712/vbox
This problem was also noticed earlier (07 Mar. 2008) and fixed in Xen:
https://lists.xenproject.org/archives/html/xen-devel/2008-03/msg00229.html

This bug originated from Bochs, from which the two projects above
adapted their rombios.c code. It was fixed on 08-09 Oct. 2007 by
Myles Watson, see https://sourceforge.net/p/bochs/mailman/message/13777090/
and included in Bochs 1.15x and 1.185+
https://sourceforge.net/p/bochs/mailman/message/12953093/
https://sourceforge.net/p/bochs/mailman/message/12953094/

show more ...

[FREELDR] Workaround regression CORE-16469

This prevents ReactOS asserting when 'My computer'
is opened, while it tries to send commands to floppy drive.

Many thanks to patches author Doug Lyons.

[FREELDR] Workaround regression CORE-16469

This prevents ReactOS asserting when 'My computer'
is opened, while it tries to send commands to floppy drive.

Many thanks to patches author Doug Lyons.

The regression was introduced by 0.4.13-dev-1081-g
eeff926ede1b2109bb0e129a960b74f3261cf2f1

patch was committed to 0.4.13rls and 0.4.14rls as well.

Today it was committed to master as well, as
the initially planned investigation for the root cause
did still not happen and we can not afford the time
to retest and workaround this over and over again.
Thank god that Oleg Dubinskiy was still around to retest
this again and confirmed it can still happen, because
unlike initially, personally I was not able to reproduce it
today anymore!

Since every release was work-arounded, we did never
expose the bug in any final release.

show more ...

[FREELDR] Restructure platform-specific code. No code changes.