On Wed, May 22, 2019 at 04:49:35PM +0300, Sam Eiderman wrote: > > On 20 May 2019, at 5:28, Kevin O'Connor <ke...@koconnor.net> wrote: > > On Fri, May 17, 2019 at 11:57:23PM +0300, Sam Eiderman wrote: > >> From: Liran Alon <liran.a...@oracle.com> > >> > >> Windows kernel extracts various BIOS information at boot-time. > >> The method it uses to extract SystemBiosDate is very hueristic. > >> It is done by nt!CmpGetBiosDate(). > >> > >> nt!CmpGetBiosDate() works by scanning all BIOS memory from 0xF0000 to > >> 0xFFFF5 (FSEG) in search for a string which is formatted like a date. > >> It then chooses the string which represents the most recent date, and > >> writes it to: > >> > >> HKLM/HARDWARE/DESCRIPTION/System SystemBiosDate > >> > >> This date should usually be BiosDate located at FSEG(0xFFF5). > > > > FWIW, if you want to ensure a stable date is found, it's probably > > simpler to force a valid date string to be present in the f-segment. > > Something like: char win_bios_date[] VARFSEG = " 04/01/2014 "; > > > > As with my previous emails, I'd recommend using a hard-coded date (not > > a build date) - as this tends to improve reproducibility. > > The thing is, if the date reported by smbios tables is 05/02/2015 (which is > bigger than 04/01/2014) so: > If smbios tables are in fseg - Windows will select the most recent date - > 05/02/2015 > If not - Windows will select the most recent date (the only one it found) - > 04/01/2014 > > So 'char win_bios_date[] VARFSEG = " 04/01/2014 “‘ will not help.
Why would the smbios tables have a newer date? If you mean that qemu is providing smbios table 0 and its date is newer, then seabios could do something like: memcpy(win_bios_date, s->bios_release_date_str, sizeof(win_bios_date)); Also, what problem occurs if sometimes 04/01/2014 is found and sometimes 05/02/2015 is found? -Kevin _______________________________________________ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
