CASE 03 · Device specs report

I wanted one device report I could trust more than a pile of screenshots.

The script collects the hardware facts a buyer is likely to ask about and writes one local HTML report. When the operating system does not expose a value reliably, the report says Unknown.

7 minute case studyReal systemNames and identifiers removed
REAL 48 GB IMAC REPORT · IDENTIFIERS REMOVED
Real populated iMac system specification report with identifiers removed
This report was generated from a copied production script in the portfolio workspace. Serial, computer name, and management state are removed.
PowerShellBatchVBScriptBashCIM / WMIsystem_profilerLocal HTML
3

runtime paths

Modern Windows, Windows XP, and macOS

48 GB

memory in the real report shown here

Four populated SO-DIMM slots

0

runtime AI calls

AI assisted development; collection is deterministic

1

plausible duplication found on a real machine

SMART rows were double-counted

The facts were scattered across settings panels and command output.

A buyer may care about the exact model, processor, RAM, storage, graphics, display, battery health, connectivity, and management state. By hand, a technician has to find and copy those fields one at a time.

A technician launches one script and gets one HTML report. Windows and macOS query local operating-system and firmware interfaces, format the result, save it to the Desktop, and open it in a browser. There is no model call in the runtime.

I left out checks that looked useful but could not be trusted.

The current report includes storage health, RAM-slot use, laptop display size and refresh rate when available, Wi-Fi generation, Ethernet status, fingerprint and optical-drive checks, battery data, and available management-state checks.

I rejected or deferred drive power-on hours, maximum supported RAM, Bluetooth version, TPM, Secure Boot, Windows 11 readiness, and webcam detection. I either could not trust the result or did not think it would help a buyer.

Unsupported and ambiguous checks use Unknown, Not reported, or Not exposed. The script leaves an ambiguous result as Unknown instead of turning it into “No.” Windows activation is a status only; the report never collects a product key.

  • Old Mac support keeps the HTML compatible with Safari 5.1 on OS X Lion.
  • Windows XP uses a separate VBScript path because PowerShell is not built in.
  • Laptop-only checks do not appear as false negatives on desktops.
  • A technician still compares the report with the physical device.

The technician gets the same action even when the operating system is twenty years older.

On a current Windows machine, the batch file coordinates PowerShell, CIM, WMI, registry, firmware, and networking checks. Windows XP cannot use that path because PowerShell is not built in, so version detection hands the job to a separate VBScript collector. The macOS script uses the local command-line tools and system reports available on the machine.

Each path writes one HTML file to the Desktop and opens it in the installed browser. The HTML also had to work on old browsers. The Mac report avoids layout features that Safari 5.1 on OS X Lion cannot render. I did not assume the oldest machines could run a newer browser.

The three platform paths expose different facts. A Windows firmware-password check, a Mac Activation Lock result, and an XP hardware query have different sources and different failure states. The report keeps those differences visible instead of forcing every platform into one false yes-or-no schema.

  1. 01

    Modern Windows

    The batch entry point gathers buyer-facing hardware, connectivity, activation, and available management-state evidence through local Windows interfaces.

  2. 02

    Windows XP

    Version detection switches to the companion VBScript because the modern PowerShell path is unavailable.

  3. 03

    macOS, including Lion-era machines

    A shell script collects local system evidence and writes HTML that remains usable in the browser the machine can run.

The first iMac run counted the same drives twice in the SMART table.

The report looked reasonable. The storage table listed the two physical drives, and the SMART table listed four rows. I compared it with the Mac’s own system information and called out the duplicate.

The cause was virtual disks leaking into the health report. The correction filtered them out. This is the kind of error that worries me. A polished report can make a duplicated value look authoritative.

The fresh report above uses the corrected code. It shows the two physical storage devices once and marks the SMART result Not reported.

One launch replaces several manual lookups, but I have not timed a fair device sample.

The removed steps are clear: open several settings panels, copy the same fields, remember which sale-risk checks apply, and rebuild the information in a consistent format.

I do not have a defensible minutes-per-device number. Old Macs, current Macs, Windows laptops, and Windows XP machines do not run the same checks at the same speed.

WHAT I WOULD NOT CLAIM

Here is what remains unmeasured or unresolved.

Next: Photo UploadDrive was already the storage system. The app had to make the handoff reliable. →