BIOS recreation?

  • Release Candidate 6
    We are at a “proposed final” true release candidate with nothing known remaining to be changed or fixed. For the full story, please see this page in the "Pre-Release Announcements & Feedback" forum.
  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in:

    This forum does not automatically send notices of new content. So if, for example, you would like to be notified by mail when Steve posts an update to his blog (or of any other specific activity anywhere else), you need to tell the system what to “Watch” for you. Please checkout the “Tips & Tricks” page for details about that... and other tips!



Active member
Sep 29, 2020
as I stumbled some years ago on a custom BIOS that enabled SLIC for a Dell Laptop which enabled installation of win7, and that works great, even to this day :D
I suspected the answer to my question for those versed would be an easy one.
*how hard would it be to write a new, custom BIOS for a system that *IS* 64bit OS capable,
but whose BIOS currently does not know (and the OEM CS indicate no inclination to support) how to read more than 2TB on HDDs/SSDs that are greater than 2TB.
*how hard is it to learn to write BIOS firmware?
*what would be the needed experience/pre-req's to be able to write said BIOS?
Thanks for the positive input.
Hardly qualified to answer that question but I was curious. Since others would be asking what is SLIC...
I think ceyarrecks was referring to this, from Wikipedia :-

Some BIOSes contain a software licensing description table (SLIC), a digital signature placed inside the BIOS by the original equipment manufacturer (OEM), for example Dell. The SLIC is inserted into the ACPI data table and contains no active code.

Computer manufacturers that distribute OEM versions of Microsoft Windows and Microsoft application software can use the SLIC to authenticate licensing to the OEM Windows Installation disk and system recovery disc containing Windows software. Systems with a SLIC can be pre-activated with an OEM product key, and they verify an XML formatted OEM certificate against the SLIC in the BIOS as a means of self-activating (see System Locked Pre-installation, SLP). If a user performs a fresh install of Windows, they will need to have possession of both the OEM key (either SLP or COA) and the digital certificate for their SLIC in order to bypass activation.[22] This can be achieved if the user performs a restore using a pre-customised image provided by the OEM. Power users can copy the necessary certificate files from the OEM image, decode the SLP product key, then perform SLP activation manually. Cracks for non-genuine Windows distributions usually edit the SLIC or emulate it in order to bypass Windows activation
  • Like
Reactions: Ceyarrecks

Cey is referring to the SLIC table ("System Licensed Internal Code") in the BIOS that enables OEM Windows installs to activate via SLP ("System Locked Pre-installation"). With an OEM Windows product key that matches the SLIC table in the OEM BIOS, Windows would self-activate without going through Microsoft.

SLIC/SLP (ver. 1.0) was introduced with Windows XP, though if you could reflash a ver. 2.0 or 2.1 SLIC table in your BIOS you could install self-activated OEM versions of Vista or Win 7, respectively. (SLIC tables were backward compatible, so a 2.1 SLIC would self-activate all three OSes.)


I don't think your BIOS is the problem, so you're barking up the wrong tree. A BIOS starts up in 16-bit Real Mode, and is never going to recognize more than 2TB drives. That's a function of Real Mode and the size of the sector registers in the MBR. Rewriting the BIOS can't change that.

When Windows boots, the startup files* kick the CPU out of Real Mode and into Protected Mode, where the operating system can then have access to 32-bit or 64-bit functions. Once in Protected Mode, the BIOS is out of the loop, and the OS can access disk drives of more than 2TB even if the BIOS could not.

Note that to install a 64-bit OS requires a 64-bit CPU. If your laptop is really old, it's CPU may only support 16/32-bit OSes. (If you had to modify the SLIC table, there's a very good chance your CPU is not 64-bit capable.) Note Steve's freeware "Securable" utility will quickly reveal if your CPU is 64-bit capable. If it's not, you're never going to get a 64-bit OS installed on that laptop, no matter what you do to the BIOS.

If your CPU is 64-bit capable, then you can install a 64-bit OS, and the BIOS doesn't matter. Remember, once it kicks into Protected Mode the OS controls disk access, not the BIOS, so a 64-bit OS can recognize GPT-style disks, including disks larger than 2TB, even though the BIOS doesn't.

However, the catch is the GPT disk has to be a secondary disk. You have to boot from a MBR disk but can use GPT for secondary disks. You can't boot from a GPT disk because the first part of the boot process relies on Real Mode and MBR, and that doesn't know what to do with a GPT disk so it would never get to the Windows startup partition to begin with.

To boot from a GPT disk requires UEFI firmware or a UEFI-capable BIOS. But that's a lot more involved than just reflashing your laptop's old BIOS, so isn't an option.

* (For clarity, I'm going to avoid calling them "boot files" because Microsoft perversely reversed the definitions so that, according to MS, the computer boots from the "System" partition and loads the operating system from the "Boot" partition)
  • Like
Reactions: Ceyarrecks
Note Steve's freeware "Securable" utility will quickly reveal if your CPU is 64-bit capable.
aye, been sitting on SecurAble forever, Thank You! for the reminder. here is the results (and am currently running win7pro64bit on this laptop) and the other, much older Dell D420 previously only expected winXP, yet refused to load Dell OEM DVD with win732bit OS until SLIC change was made. /shrug o_O

ASUS Laptop Securable Results.jpg
To boot from a GPT disk requires UEFI firmware or a UEFI-capable BIOS. But that's a lot more involved than just reflashing your laptop's old BIOS, so isn't an option.
right, and this system has space and controller for only a single drive. :(
and by "more involved" suggests something far beyond just bytes in a different configuration on the same foundation of silicon, maybe requires a different foundation entirely, huh?
oh well. maybe wearleveling will chew on that unpartitioned/inaccessible part of the drive first...

Thank you all for your input! :coffee::coffee::coffee::coffee:
From a developer perspective, the BIOS is nothing more than an API. (An Application Programmer Interface.) In essence, the BIOS is just a set of expectations, one of which is based around 16bit segmented memory accesses. So a direct answer is that it is IMPOSSIBLE to make 64 bit BIOS because the expectation is that it is 16 bit. You COULD make a new thing that would do the same kind of work (I/O being the majority of it) but based on 64 bits. The trick would be that it would only work in programs that chose to adopt your new BIOS-like thing. I don't think it would be easy or worthwhile to make a new backward compatible BIOS thing, because it's already been done... it's called the CSM (Compatibility Support Module) that is part of UEFI.
  • Like
Reactions: Dave