Tree: d0f1a52650

dev

master

1.2

1.3

1.4

1.5

1.6

1.7

1.8

1.9

2.0

2.1

2.2

2.3

2.4

2.5

2.6

2.7

2.8

2.9

3.0

3.1

3.10

3.11

3.12

3.2

3.3

3.4

3.5

3.6

3.7

3.8

3.9

Branches Tags

${ item.name }

Create tag ${ searchTerm }

Create branch ${ searchTerm }

from 'd0f1a52650'

${ noResults }

Commit Graph

1 Commits (d0f1a52650d53a8d1cdf6f1b508f7590692b24f7)

Author	SHA1	Message	Date
RustyProgrammerCmd	7fbe6fdf21	Port MAS to Rust ... Re-architect the Microsoft Activation Scripts from ~46k lines of Windows batch into an idiomatic Rust crate (MAS/). Not a line-by-line translation: typed enums + Result flow replace goto/errorlevel/global-set, and a single `Spp` trait is the only seam between portable logic and Windows internals. - Portable core (compiles + 20 tests pass, zero deps): model (real SPP GUIDs / WMI class names / LicenseStatus codes), typed errors, CLI menu, Check_Activation_Status read path, Online KMS orchestration with host fallback, stub backend. - Windows backend (cfg(windows) + `winapi` feature): WMI/COM via the `windows` crate, all unsafe/VARIANT handling encapsulated behind `Spp`. Written from the documented SPP contract; not compiled on the Linux port host. - HWID/KMS38/Ohook/TSforge scaffolded against analyzed specs (in module docs) — unported paths return a typed Unsupported error rather than falsely reporting activation. Roadmap in MAS/README.md. The original .cmd scripts remain recoverable in history (f34d025, MAS 3.12). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2 weeks ago