- generated server header/source files get _s postfix
- only generate code for the required module
Note: due to an bug in VS2005 build tool lib tool does only get part of generated object filename i.e. pnp_c.obj becomes pnp.obj. As a result the lib tool cannot link. However we need to generate unique obj files so that client / server project always compiles the requires source files
svn path=/trunk/; revision=25091
- Please look what I did inside FreeLdr. I called this function perfectly without needing to modify how it works. It's what the AdditionalBias parameter is there for...
svn path=/trunk/; revision=25071
Using it removes code duplication from FreeLdr / winldr.
To get rid of this hack, either freeldr should be fully switched to virtual paged mode (which is not good) or code must be duplicated inside freeldr.
svn path=/trunk/; revision=25070
== LBA Functionality BIOS Bug ==
When the BIOS is asked whether it supports INT 13 extensions, it will answer yes if the device is a hard disk, but it will pretend that even the function to ask about this functionality is unsupported if asked about a CD drive. This is similar to what is documented in the code already: Some BIOSes return "doesn't support INT 13 extensions" for CDs.
Code has been added to use INT 13 extensions (and therefore LBA read as opposed to CHS) even if the BIOS claims this is unsupported, if the device is a CD-ROM. The check for the drive type is done by comparing with 0x90: If the device number is 0x90 or above, it's a CD drive. (On Insyde's BIOS, it's 0x90, on most others, it's 0x9F).
(Ironically, Insyde's BIOS cannot even do CHS on CDs, so if the bootloader correctly asks for LBA support, it will get a "no" and will fail when trying to do CHS: When querying the max. CHS values, the BIOS returns 0 sectors per track, which will make conversions from LBA to CHS impossible.)
== LBA Read BIOS Bug ==
When trying to read from CD using the LBA function INT 13/42, the BIOS function will return as it is supposed to, with CF and AH cleared, but with an unchanged buffer. This is because freeldr passes a "disk address packets" that structure contains an extra 64 bit value at the end and is therefore 24 bytes long instead of 16. This is perfectly fine, and a BIOS should ignore any extra data in the structure, but Insyde's BIOS, which doesn't support the extra field (and thus the EDD-3.0 standard) just ignores the complete task and returns in this case.
The extra field has been removed from the structure in freeldr, as it is not used anyway. The structure is now 16 bytes long.
svn path=/trunk/; revision=25063
== A20 Gate and the Keyboard Controller ==
In order to turn on the A20 gate, the keyboard controller has to be emptied. This is done in freeldr by reading bytes until the keyboard controller signals it's empty. Intel Macs don't have PS/2 keyboard controller and the status register always reads back 0xFF, so the "there is data" bit will never be cleared. (The same problem has been in GRUB as well as in Darwin's BIOS loader.)
Added code that doesn't bother to clear the keyboard buffer if the status port reads back 0xFF.
== Serial Port BIOS Bug ==
Insyde's BIOS reports that there is a COM1 serial port at 0x3F8 (as stored in 0040:0000 in memory), but there is none in Intel Macs, so freeldr spins infinitely while trying to empty the serial port's buffer.
Added code that makes sure the loop only gets executed up to 200 times
svn path=/trunk/; revision=25062
Change name everywhere back to Ariadne because real person could not be contacted. Non-working email address removed.
If this person doesn't contact me before finish of the audit, the copyright will be transferred to ReactOS Foundation.
svn path=/trunk/; revision=25049
