v0.6.0

The networking and provenance release. A built PE now configures its own hardware and reaches
the network at boot — and, with network-ui, shows that connection on the desktop, not just
the command line. Every build leaves a receipt recording exactly what it was made from, which
pebuild verify checks against the tool that produced it. Windows Server 2003 joins the
supported sources, and new inspection (pebuild image) and debugging (serialdebug) tools round
out the toolbox.

Added

• A PE configures its hardware and networking at boot. The hardware plugin runs the PnP
  driver-install pass a PE otherwise never gets — letting setupapi choose each driver, installed
  read-only so nothing is written to boot media — then installs the network components through
  INetCfg, so an image binds its NIC and takes a DHCP address. Its companion network-tools
  stages the command-line utilities (ipconfig, ping, route, arp, tracert, nslookup,
  hostname). Verified on 32-bit XP; see Known limitations for build 3790.
• The network is visible on the desktop. The network-ui plugin adds the Network
  Connections folder to Control Panel and a notification-area icon showing link state and
  activity, with the adapter Status and Properties dialogs behind it — until now a configured
  network had no sign of itself outside the command line. It ships no code: it stages the shell
  components that draw the UI, including the ones they load by name that no import scan can see,
  and registers them. The icon is user-toggled, as it is on stock XP.
• Windows Server 2003 sources build the Explorer desktop, on both architectures — which took
  reading the NT product type from the source (to tell it from XP x64, which shares its build
  number), a product-aware splash banner, and staging Common-Controls from the cabinet 2003 media
  pack it in.
• Published plugin conventions (docs/plugins/conventions.md) —
  the documentation, C-lint, version-resource and architecture-scoping standards a plugin follows.
• A one-shot startup-task contract. The startup plugin declares a registry list of tasks to
  run once at boot and ships perun to walk it — from the shell's splash on a desktop build, or
  startnet.cmd on a console build — recording each task's verdict so a failed task never costs the
  boot. hardware is its first consumer.
• pebuild verify — what an image was built from. Every build now writes a receipt
  (PEBUILD.TXT) into the image: the manifest, the Windows source, the resolved plugin set with its
  option values, a content hash of pebuild's embedded base and built-in plugins, and a taint
  verdict for anything out-of-tree. verify reads it back and reports what has changed since, so a
  stale ISO is no longer indistinguishable from a fresh one.
• pebuild image ls|extract — read files out of a built PE (a mastered .iso, an output
  directory, or a reference image from another tool), completing the inspection surface beside
  source and hive dump.
• A serialdebug plugin boots the image with the kernel debugger enabled on COM1;
  pebuild run --serial attaches the host to it.
• pebuild plugins info lists a plugin's [Options] — the knobs a manifest may set, with each
  default and allowed set.
• Taskbar locking is a plugin option on explorer-shell.
• Every binary the build emits carries a Windows version resource (product, author, version,
  copyright), so a shipped PE identifies itself in Windows Properties → Details and Task Manager.

Changed

• The Shutdown Event Tracker is turned off — a PE has no use for the "why did you shut down?"
  prompt.

Fixed

• The output ISO is published atomically — mastered to a scratch file and renamed into place,
  so a failed or interrupted build never leaves a truncated image where a good one should be.
• UTF-16 .inf files are decoded inside the parser rather than misread.
• The hardware plugin's console output no longer garbles. Its runtime messages used em dashes
  that rendered as mojibake in the console's OEM code page on every locale; they're ASCII now.
• peshut links freestanding on both architectures.
• The "My Documents" desktop icon is hidden — in a PE it opens nothing, so it no longer sits
  there dead.
• The base no longer seeds portmon.exe/tzchange.exe, which are XP-only.

Known limitations

• Networking does not work on build 3790 (Windows XP x64 / Server 2003, both architectures): the
  component install succeeds but the win32 co-services that would use it do not start. It tracks the
  codebase, not the architecture — 32-bit Server 2003 fails identically. The same limitation stops
  network-ui's Status and Properties dialogs there: the connection never finishes coming up, and
  the property sheet enumerates components through INetCfg. The folder and the tray icon work. See
  docs/supported.md.
• Carried forward from 0.5.0: no sound; on amd64 the wallpaper, Folder Options and a drive's
  Properties dialog do not work. Full detail in docs/supported.md.

v0.5.0

The 64-bit release. An amd64 Windows source now builds the full themed desktop — Explorer
with the Luna visual style, working Control Panel applets, a RAM drive, and a Start menu that
powers the machine off — the same image an x86 build gets. Bart's PE Builder and the tradition
that grew around it built 32-bit images only; a live Windows environment of this kind has not
existed in 64-bit.

Reaching it took three things the build could not do before — compiling a plugin's payload for
the target architecture, decoding the MSZIP cabinets amd64 media pack their side-by-side
assemblies with, and addressing a cabinet member by its exact internal path — and four fixes
without which no shell binary would start at all. The x86-only limitation listed in 0.4.0 is
lifted. pebuild run, which boots a built image in QEMU from one command, lands alongside.

Added

• The desktop plugins build for amd64. explorer-shell, poweroff, ramdrive and
  pesuite now compile for the target architecture rather than a fixed 32-bit toolchain, so
  an amd64 build gets the same desktop an x86 build does. A build-capable plugin scopes its
  build with [Build.<arch>], each naming that architecture's compiler in Requires and
  passing the architecture to its Command; the shared [Build] keeps what does not vary.
• MSZIP cabinet decoding. amd64 media pack the side-by-side assemblies with MSZIP, where
  x86 SP3 media use LZX throughout, so those cabinets could not be read at all.
• Cabinet members are addressable by their full internal path. A source may pack a whole
  tree into one cabinet — amd64 media keep the side-by-side assemblies in ASMS01.CAB — and
  several assemblies each contain a comctl32.dll, distinguished only by their directory. A
  [SourcePaths] entry naming an exact path now reaches into a cabinet when the path is not
  a loose file.
• A wallpaper plugin puts the XP default wallpaper on the desktop, which otherwise comes
  up on a flat colour. It ships no code and needs no toolchain, and enabling it pulls in the
  desktop it decorates. The wallpaper is a JPEG and the classic desktop path paints bitmaps
  only, so the plugin stages the Active Desktop surface that can paint one — which is why it is
  a separate plugin, off by default: it adds about 4 MB to the image, and a build that does not
  enable it pays nothing. The image is scaled to whatever resolution the manifest selects.
• Plugins can register COM servers of their own. A plugin that stages one declares it under
  HKLM\SOFTWARE\pe-builder\SelfRegister, one value per DLL, and the shell registers each after
  its own validated start-up sequence — which stays fixed and unreorderable. Entries register in
  sorted name order: they are self-contained servers whose order should not matter, so pinning it
  keeps any latent dependency between them failing reproducibly rather than intermittently.
• pebuild run boots a built image in QEMU. The argument is either an .iso or the
  manifest that wrote one — told apart by content, so a name that disagrees with what a file
  actually is does not decide it — and with no argument, pebuild.hcl in the current
  directory. It reads the image's own architecture to pick the emulator and machine, so one
  command covers both: a 64-bit image gets qemu-system-x86_64 (and, where the host cannot
  accelerate it, a CPU model that advertises long mode), which a 32-bit emulator could never
  boot. Hardware acceleration is used when /dev/kvm is available and quietly falls back to
  emulation when it is not. --ram sizes guest memory and --usb-tablet adds a tablet for
  seamless mouse. It deliberately does not build: a manifest naming no built image says so,
  and points at building it.
• Prebuilt binaries. This is the first release to ship prebuilt pebuild and pewalk
  binaries. Linux and Windows are tested; macOS cross-compiles but is not runtime-verified, so
  it is experimental. Building from source is documented per platform in
  docs/install.md.

Fixed

• Shell binaries start on amd64. Every shell binary an amd64 source ships requires the v6
  Common-Controls side-by-side assembly, and the loader fails a process outright when it
  cannot be resolved — so explorer, notepad, taskmgr and the rest did not start at all.
  It is not the cosmetic difference it is on x86, where the assembly only decides whether
  property sheets draw themed controls. The assembly, its manifest, the publisher policy and
  their catalogs are now staged from the cabinet that holds them.
• The publisher policy is staged where a PE looks for it. A PE runs with
  Setup\SetupType=1, and in setup mode the loader reads publisher policies from
  WinSxS\setuppolicies rather than WinSxS\Policies. With only the latter staged the
  policy is never consulted: the assembly resolves when asked for by its own version, and
  every request needing the version redirect fails with 14001, however correct the files
  are. This affects amd64 only — x86 media carry an assembly of the version its binaries ask
  for, so the bind is direct and no policy is involved.
• Control Panel applets open on amd64. rundll32.exe, which hosts every applet, carries
  no manifest of its own on either architecture, and an assembly reference names an
  architecture — so the x86 manifest shipped for it resolved to nothing on amd64 and every
  applet failed to start. It now gets an architecture-matched one.
• "Turn Off Computer" powers the machine off on amd64. The ExitWindowsEx hook was built
  and staged for x86 only. Two things stopped it working: a 5-byte relative jump cannot span
  a 64-bit address space, so the patch silently corrupted the function in every process that
  loaded it; and the hook is injected before the host process's C runtime is initialized,
  which aborted the process outright once the toolchain linked one in. The x86 binary is
  unchanged.

Changed

• A plugin that cannot be built for the target architecture is refused by the build, not
  by the parser, and the error names the plugin and the missing section. It stays visible to
  pebuild plugins list and plugins info, since a plugin that is never built is still a
  plugin worth describing.
• A plugin build's output is checked against the target architecture. make decides by
  timestamp and no Makefile makes its outputs depend on the architecture, so building a
  plugin for one architecture and then another in the same directory leaves the first one's
  binary in place — which would then simply not run, with nothing in the build output
  explaining why. Each produced file's machine type is now verified.
• The build refuses to write outside its output tree. Destinations are assembled from
  plugin-supplied pieces, and nothing rejected a path climbing out of the tree with ...

Known limitations

Full detail for each is in docs/supported.md.

• Folder Options and Taskbar properties do nothing on amd64 — both work on x86.
• A drive's Properties dialog does not work on amd64 — it works on x86.
• The wallpaper plugin does not render on amd64 — the desktop shows a flat colour; it
  works on x86.
• Task Manager's User Name column shows unreadable characters for all but System Idle
  Process (cosmetic).
• There is no sound, on either architecture — unchanged from 0.4.0.
• 32-bit Windows Server 2003 sources remain untested. The proven sources are Windows XP
  SP3 (32-bit) and Windows XP Professional x64 Edition.