Oh my. Use of non-ISO8601 format in any form of computer code need to be sanctioned.

On Wed, May 22, 2019 at 9:50 AM Sam Eiderman <shmuel.eiderman@oracle.com> wrote:

On 20 May 2019, at 5:28, Kevin O'Connor <kevin@koconnor.net> wrote:

On Fri, May 17, 2019 at 11:57:23PM +0300, Sam Eiderman wrote:
From: Liran Alon <liran.alon@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:


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.



SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-leave@seabios.org

Tech III * AppControl * Endpoint Protection * Server Maintenance
Buncombe County Schools Technology Department Network Group
ComicSans Awareness Campaign