aidalite/PLAN.md

AIDA64 Clone Development Plan

Project Overview

A small, lightweight AIDA64 clone built with .NET 10 and WPF, drawing design inspiration from CPU-Z. The goal is to provide essential system information and benchmarking capabilities in a compact, performant desktop application.

---

1. Architectural Outline

1.1 High-Level Architecture

The application follows a Model-View-ViewModel (MVVM) pattern with a modular, plugin-like structure for each hardware subsystem.

┌─────────────────────────────────────────────────┐
│                   WPF UI (Views)                │
├─────────────────────────────────────────────────┤
│              ViewModels (Presentation)           │
├─────────────────────────────────────────────────┤
│           Domain Models & DTOs                   │
├─────────────────────────────────────────────────┤
│         Hardware Abstraction Layer (HAL)         │
│  ┌──────────┬──────────┬──────────┬──────────┐  │
│  │ CPU      │ RAM      │ GPU      │ Disk     │  │
│  │ Prober   │ Prober   │ Prober   │ Prober   │  │
│  └──────────┴──────────┴──────────┴──────────┘  │
├─────────────────────────────────────────────────┤
│       Native Interop / WMI / Registry Layer     │
└─────────────────────────────────────────────────┘

1.2 Key Architectural Principles

• Module-based design: Each hardware subsystem (CPU, RAM, GPU, Disk, Motherboard, etc.) is an independent module that can be enabled/disabled.
• Lazy initialization: Hardware probes are lazy-loaded to keep startup fast.
• Async/await throughout: All hardware reads are non-blocking to keep the UI responsive.
• Dependency Injection: A central IServiceCollection wires up all probers and services.
• No external heavyweight dependencies: Prefer P/Invoke, WMI, and native Windows APIs over big NuGet packages; small source-only code-gen libraries (Microsoft.Windows.CsWin32, CpuId) are acceptable.

---

2. Solution Structure

AidaLite/
├── AidaLite.sln
├── src/
│   ├── AidaLite.Core/                    # Shared models, interfaces, utilities
│   │   ├── Models/
│   │   │   ├── CpuInfo.cs
│   │   │   ├── MemoryInfo.cs
│   │   │   ├── GpuInfo.cs
│   │   │   ├── DiskInfo.cs
│   │   │   ├── MotherboardInfo.cs
│   │   │   └── SystemInfo.cs
│   │   ├── Interfaces/
│   │   │   ├── IHardwareProber.cs
│   │   │   ├── ICpuProber.cs
│   │   │   ├── IMemoryProber.cs
│   │   │   ├── IGpuProber.cs
│   │   │   ├── IDiskProber.cs
│   │   │   └── IBenchmarkRunner.cs
│   │   └── Utilities/
│   │       ├── NativeInterop.cs
│   │       └── WmiHelper.cs
│   │
│   ├── AidaLite.Probes/                  # Hardware probing implementations
│   │   ├── CpuProber.cs
│   │   ├── MemoryProber.cs
│   │   ├── GpuProber.cs
│   │   ├── DiskProber.cs
│   │   ├── MotherboardProber.cs
│   │   └── BenchmarkRunner.cs
│   │
│   ├── AidaLite.Benchmarks/              # Benchmarking engines
│   │   ├── CpuBenchmark.cs
│   │   ├── MemoryBenchmark.cs
│   │   └── DiskBenchmark.cs
│   │
│   └── AidaLite.App/                     # WPF application shell
│       ├── App.xaml
│       ├── App.xaml.cs
│       ├── Views/
│       │   ├── MainWindow.xaml
│       │   ├── CpuTab.xaml
│       │   ├── MemoryTab.xaml
│       │   ├── GpuTab.xaml
│       │   ├── DiskTab.xaml
│       │   ├── BenchmarksTab.xaml
│       │   └── SensorTab.xaml
│       ├── ViewModels/
│       │   ├── MainViewModel.cs
│       │   ├── CpuViewModel.cs
│       │   ├── MemoryViewModel.cs
│       │   ├── GpuViewModel.cs
│       │   ├── DiskViewModel.cs
│       │   └── BenchmarkViewModel.cs
│       └── Resources/
│           └── Styles.xaml
├── tests/
│   └── AidaLite.Tests/
└── README.md

---

3. Core Components

3.1 Hardware Abstraction Layer (HAL)

Each prober implements a common IHardwareProber interface:

public interface IHardwareProber
{
    string Name { get; }
    Task ProbeAsync(CancellationToken ct = default);
}

Specialized interfaces extend this:

Prober	Key Data Points	Primary Source
CpuProber	Vendor, model, cores, threads, speed, cache, instruction sets	WMI Win32_Processor (primary); tiny source-only CPUID package for feature flags
MemoryProber	Total, free, speed, type (DDR4/5), slot count, latency	WMI Win32_PhysicalMemory, Performance Counters
GpuProber	Name, VRAM, driver version, resolution	DXGI (IDXGIFactory1, IDXGIAdapter1) via Microsoft.Windows.CsWin32 (no P/Invoke to d3d11.dll)
DiskProber	Model, size, type (SSD/HDD/NVMe), firmware, SMART status	WMI Win32_DiskDrive, Win32_LogicalDisk; MSFT_PhysicalDisk (Storage Spaces API) for reliable SSD/HDD/NVMe bus-type discrimination, Storage Spaces API
MotherboardProber	Manufacturer, model, BIOS version/date	WMI Win32_BaseBoard, Win32_BIOS

3.2 Native Interop Strategy

Capability	Technique	Notes
CPUID	P/Invoke cpuid via inline assembly or System.Runtime.Intrinsics	For vendor, family, features
CPU Speed	QueryPerformanceCounter	Accurate clock reading
GPU Info	DXGI (IDXGIFactory1, IDXGIAdapter1)	P/Invoke into d3d11.dll
SMART Data (optional)	IOCTL to CreateFile on disk handle	Requires admin privileges
Sensor Data (optional)	WMI MSAcpi_ThermalZoneTemperature	Limited coverage; note in UI

3.3 Benchmarking Engine

Inspired by CPU-Z's benchmark tab:

• CPU Benchmark: Single-threaded and multi-threaded integer + floating-point loops using System.Numerics intrinsics.
• Memory Benchmark: Read/write bandwidth test using large buffer copies.
• Disk Benchmark: Sequential read/write with increasing block sizes (4KB → 4MB).
• Scoring: Normalize results to a baseline score (e.g., 1 core @ 1 GHz = 1.0 point).
• Execution: Run on a background Task, report progress via IProgress<double>.

---

4. UI Design (Inspired by CPU-Z)

4.1 Layout

A single MainWindow with a TabControl at the top:

┌──────────────────────────────────────────────────────────┐
│  AidaLite                                              [─][□][×] │
├──────────────────────────────────────────────────────────┤
│ [ CPU ] [ Memory ] [ GPU ] [ Disk ] [ Benchmarks ] [ Sensors ] │
├──────────────────────────────────────────────────────────┤
│                                                          │
│  Tab content area                                        │
│  - Read-only text fields (key-value pairs)               │
│  - Optional small charts for sensors / benchmarks        │
│                                                          │
└──────────────────────────────────────────────────────────┘

4.2 Design Principles

• Compact and dense: Small fonts (11–12px), tight padding, monospace font for values.
• Read-only: No editing; pure information display.
• Auto-refresh: Poll sensors/benchmarks every N seconds (configurable, default 2s) only when the tab is active.
• Light theme by default, with optional dark theme via resource dictionary swap.

---

5. Technical Stack

Concern	Choice	Justification
Language	C# (latest, .NET 10)	Modern language features
UI Framework	WPF	Native Windows desktop, XAML, mature
MVVM Library	CommunityToolkit.Mvvm	Lightweight, no heavy DI framework
DI Container	Built-in Microsoft.Extensions.DependencyInjection	Native to .NET 10
WMI Access	System.Management	Standard WMI queries
Native Interop	D3dCompiler P/Invoke, System.Runtime.InteropServices	CPUID, DXGI
Performance	System.Diagnostics.Stopwatch, Performance Counters	Benchmarking
Logging	Microsoft.Extensions.Logging (optional, off by default)	Debugging
Build	MSBuild / dotnet build	Standard .NET tooling

---

6. Development Milestones

Phase 1 – Foundation (Week 1)

• Create solution, projects, folder structure
• Set up WPF shell with TabControl and empty tabs
• Implement IHardwareProber interface and DI registration (Introduce IWmiHelper test seam for WMI abstractions)
• Create base MainWindow layout matching CPU-Z style

Phase 2 – Core Probes (Week 2–3)

• Implement CpuProber (CPUID + WMI)
• Implement MemoryProber (WMI + Performance Counters)
• Implement GpuProber (DXGI)
• Implement DiskProber (WMI)
• Implement MotherboardProber (WMI)
• Wire each prober to its tab ViewModel

Phase 3 – Benchmarks (Week 4)

• Implement CpuBenchmark (single/multi-thread)
• Implement MemoryBenchmark (bandwidth)
• Implement DiskBenchmark (sequential I/O)
• Add benchmark UI with progress and result display

Phase 4 – Polish & Sensors (Week 5)

• Add sensor polling (CPU temp if available, disk health)
• Add auto-refresh logic per tab
• Dark/light theme toggle
• Optional: export report to JSON/HTML

Phase 5 – Testing & Release (Week 6)

• Unit tests for probers (mock WMI where possible)
• Integration testing on 2–3 different machines
• Packaging as self-contained single-file executable
• Write README.md with features and known limitations

---

7. Known Limitations & Assumptions

• Windows-only (WPF is Windows-centric).
• Sensor data is limited: Not all hardware exposes temperature/power via WMI. Clearly mark "N/A" when unavailable.
• SMART data requires admin privileges: Optional; degrade gracefully if not elevated.
• GPU benchmarking is basic: Full 3D benchmarking would require a D3D11 render loop; defer to a future phase.
• No Linux/macOS support in v1.

---

8. Future Enhancements (Post-v1)

• Full 3D GPU benchmark using D3D11/OpenGL interop
• Network benchmark (bandwidth test to localhost or remote)
• Hardware monitoring with real-time graphs (using SkiaSharp for lightweight charting)
• Plugin system for community-contributed probes
• Linux support via Avalonia (same Core/Probes projects, swap WPF for Avalonia UI)
• Tray icon with quick CPU/RAM status