diff options
| author | WindowsAddict | 2025-03-29 07:27:10 +0000 |
|---|---|---|
| committer | GitHub | 2025-03-29 07:27:10 +0000 |
| commit | b2a115a352ed9c78b8cb83e319ada5c28b417741 (patch) | |
| tree | bc566393aa26887be36a94b5aec658ed8bafb7d3 /docs | |
| parent | 66226f02abe1110b2bdfe49c544fabc25eb76d59 (diff) | |
| parent | dcfa95441a601e883d2c982f9cb70424a0954ba8 (diff) | |
| download | massgrave.dev-b2a115a352ed9c78b8cb83e319ada5c28b417741.zip | |
Merge pull request #38 from ave9858/Y2K38
Fix incorrect info
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/kms38.md | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/docs/kms38.md b/docs/kms38.md index c81efc4..f09d51e 100644 --- a/docs/kms38.md +++ b/docs/kms38.md @@ -16,7 +16,7 @@ - In the Windows major upgrade process, the system uses `gatherosstate.exe` to carry over the remaining KMS activation period. It does this by creating a ticket that can be used offline.
- The trick is that we can fool the `gatherosstate.exe` about the remaining KMS activation period and manually put the desired period maximum up to January 19, 2038, 03:14:07 UTC.
- Why is it limited to the year 2038?
- It's related to the [Y2K38 problem](https://en.wikipedia.org/wiki/Year_2038_problem) as this date (19 January 2038 03:14:07 UTC) is the maximum date we can give to `gatherosstate.exe` without it looping back to the year 1970.
+ This is due to the [Y2K38 problem](https://en.wikipedia.org/wiki/Year_2038_problem). This date (19 January 2038, 03:14:07 UTC) is the maximum value that can fit into a signed 32 bit integer.
- How can we convince the gatherosstate.exe?
There are two methods for it.
**1-** Place a [custom slc.dll](https://github.com/asdcorp/Integrated_Patcher_3) file beside gatherosstate.exe:
|