If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/snowie2000/mactype shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Mixed signals — read the receipts

• Last commit 1w ago
• 12 active contributors
• GPL-3.0 licensed
• ⚠ Concentrated ownership — top contributor handles 69% of recent commits
• ⚠ GPL-3.0 is copyleft — check downstream compatibility
• ⚠ No CI workflows detected
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live snowie2000/mactype repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/snowie2000/mactype.

What it runs against: a local clone of snowie2000/mactype — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in snowie2000/mactype | Confirms the artifact applies here, not a fork | | 2 | License is still GPL-3.0 | Catches relicense before you depend on it | | 3 | Default branch directwrite exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 40 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of snowie2000/mactype. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/snowie2000/mactype.git
#   cd mactype
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of snowie2000/mactype and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "snowie2000/mactype(\\.git)?\\b" \\
  && ok "origin remote is snowie2000/mactype" \\
  || miss "origin remote is not snowie2000/mactype (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(GPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"GPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is GPL-3.0" \\
  || miss "license drift — was GPL-3.0 at generation time"

# 3. Default branch
git rev-parse --verify directwrite >/dev/null 2>&1 \\
  && ok "default branch directwrite exists" \\
  || miss "default branch directwrite no longer exists"

# 4. Critical files exist
test -f "dll.cpp" \\
  && ok "dll.cpp" \\
  || miss "missing critical file: dll.cpp"
test -f "directwrite.cpp" \\
  && ok "directwrite.cpp" \\
  || miss "missing critical file: directwrite.cpp"
test -f "fteng.cpp" \\
  && ok "fteng.cpp" \\
  || miss "missing critical file: fteng.cpp"
test -f "hook.cpp" \\
  && ok "hook.cpp" \\
  || miss "missing critical file: hook.cpp"
test -f "settings.cpp" \\
  && ok "settings.cpp" \\
  || miss "missing critical file: settings.cpp"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 40 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~10d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/snowie2000/mactype"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

MacType is a Windows system-wide font rendering engine that intercepts and replaces GDI and DirectWrite text rendering with FreeType-based rasterization, delivering macOS-like font smoothing and anti-aliasing across all applications. It provides customizable hinting, subpixel rendering, and color font support (1.5M+ lines of C++) to enhance text legibility on Windows. Monolithic DLL-based injection architecture: core rendering in ft.cpp/fteng.cpp (FreeType integration), GDI hooking via hook.cpp, DirectWrite interception in directwrite.cpp, with a tray application loader (macloader.vcxproj) and GDI+ flattening layer (gdiPlusFlat2.cpp). EasyHook (easyhook.h) provides API hooking, and configuration persisted via profiles with hash-based caching (hash_list.cpp).

Windows users (especially power users) who want superior font rendering quality similar to macOS, and developers maintaining Windows applications who need fine-grained control over typography rendering across heterogeneous systems.

Actively maintained and production-ready. The project shows recent updates (Win11 support, CET compatibility, EasyHook updates) and has a stable release pipeline with both official site and GitHub releases. No explicit test suite visible in file structure, but shipping to end-users with known issues documented transparently.

Single-maintainer project (snowie2000) with minimal visible CI/testing infrastructure in the Makefile-based build system. Risk of antivirus conflicts documented (file modification of running processes), Office 2013 incompatibility known, and WPS Office auto-unloads it. Dependency on outdated VC2005 build files suggests legacy codebase. Breaking changes possible (users warned to backup profiles before upgrades).

Recent work includes Win11 compatibility, CET (Compatibility Enforcement Technology) support, FreeType updates, multi-monitor refinements, Service Mode improvements, diacritics handling, and separate DirectWrite parameter tuning. Localization expanded (Korean added, Traditional Chinese improved). The directwrite branch appears to be active development.

Clone: git clone https://github.com/snowie2000/mactype.git && cd mactype. For building: see doc/HOWTOBUILD.md for Visual Studio setup. Pre-built releases available at https://github.com/snowie2000/mactype/releases/latest for immediate testing.

Daily commands: This is a system service/DLL, not a CLI app. Build with build.vc2005.bat (legacy) or open gdipp.sln in Visual Studio. Installation: run the official installer or use the tray loader (macloader). Configuration via MacType Tuner GUI or manual profile editing. Testing: apply a profile and inspect rendered text in any Windows application.

• dll.cpp — Main DLL entry point for MacType injection—initializes hooking, settings, and core rendering pipeline; all contributors must understand how this bootstraps the font rendering system.
• directwrite.cpp — DirectWrite API interception and font rendering for modern Windows—the primary rendering backend for Win10+ systems; essential for understanding how glyph rendering is intercepted and modified.
• fteng.cpp — FreeType engine wrapper and glyph processing core—handles font loading, hinting, antialiasing, and bitmap generation; load-bearing for all font transformations.
• hook.cpp — Windows API hooking mechanism using detours/EasyHook—intercepts GDI and DirectWrite calls system-wide; critical for understanding injection and IPC patterns.
• settings.cpp — Configuration loading and management from INI/JSON—handles per-application font profiles and rendering tweaks; required to understand feature customization.
• cache.cpp — Glyph bitmap caching layer for performance—reduces redundant FreeType processing; essential for understanding memory and latency optimization.
• gdidll.rc — Windows resource definitions and version info—metadata and version strings compiled into the injected DLL; consulted during build and deployment validation.

Add a New Font Override Rule

1. Define the override match condition (e.g., fontname, application, process). (override.h)
2. Implement the override logic (font substitution, parameter tweaks) in override.cpp matching the OverrideRule structure. (override.cpp)
3. Parse the override from INI/JSON configuration in settings.cpp. (settings.cpp)
4. Apply the override in fteng.cpp when LoadFont or ApplyHinting is called. (fteng.cpp)

Add a New Rendering Quality Option

1. Add the configuration parameter to the FontEngineSettings or RenderOptions struct in fteng.h. (fteng.h)
2. Load the parameter from INI in settings.cpp and store it in the settings object. (settings.cpp)
3. Implement the quality logic in fteng.cpp (e.g., in RenderGlyph or ApplyPostProcessing). (fteng.cpp)
4. For DirectWrite, mirror the logic in directwrite.cpp if using the modern rendering path. (directwrite.cpp)

Hook a New Windows API for Font Interception

1. Declare the hook target and handler in hooklist.h or hook.h. (hooklist.h)
2. Implement the detour handler in hook.cpp, ensuring it calls the underlying FreeType engine (fteng.cpp) for glyph rendering. (hook.cpp)
3. Register the hook in the hook initialization routine in dll.cpp. (dll.cpp)
4. Test that the hooked API is correctly intercepted and that rendered glyphs pass through cache.cpp for performance. (cache.cpp)

Add Support for a New Font Feature (e.g., Variable Fonts)

1. Update the FreeType wrapper (ft.cpp/ft.h) to expose the new FT_* API calls needed. (ft.cpp)
2. Extend FontEngineSettings in fteng.h with parameters for the feature (e.g., weight, width axes). (fteng.h)
3. Implement the feature logic in fteng.cpp during glyph loading or rendering. (fteng.cpp)
4. Parse configuration in settings.cpp and handle per-app overrides in override.cpp. (settings.cpp)

• FreeType library (ft.cpp/fteng.cpp) — Provides advanced font rendering, hinting, antialiasing, and cross-platform font support—enables MacType to improve upon Windows' native rendering quality.
• Detours/EasyHook (hook.cpp) — Intercepts Windows GDI and DirectWrite API calls at runtime without recompiling applications—allows system-wide font rendering injection.
• DirectWrite (directwrite.cpp) — Modern font rendering API for Win10+; must be intercepted to maintain font rendering consistency across legacy and modern applications.
• Glyph bitmap caching (cache.cpp) — Reduces repeated FreeType rendering calls; improves UI responsiveness by avoiding 5–50ms glyph rasterization on every keystroke.
• INI/JSON configuration (settings.cpp) — Enables per-application font profiles and user customization without code changes; allows complex override rules.

• System-wide DLL injection vs. per-application hooking

  • Why: Injection is more comprehensive and universal—works transparently across all applications.
  • Consequence: Requires admin/service installation; potential compatibility issues with sandboxed or virtualized apps; requires WOW64 compatibility layer for 32-bit apps on 64-bit OS.

• Cache glyphs in memory vs. render on-demand

  • Why: Caching dramatically improves latency and CPU usage during frequent text rendering.
  • Consequence: Increases memory footprint; requires cache invalidation logic when font or size changes; risks stale glyphs if settings change.

• Support both legacy GDI and modern DirectWrite

  • Why: Maintains compatibility with older Windows and applications, while supporting Win10+ modern rendering.
  • Consequence: Doubles the rendering pipeline code; potential visual inconsistencies between rendering paths; increased testing burden.

• FreeType-based rendering over native Windows fonts

  • Why: FreeType provides superior hinting and antialiasing for better visual quality (MacOS-like rendering).
  • Consequence: Adds significant dependency and complexity; potential licensing/distribution concerns; increased CPU on first-render due to FreeType overhead.

• Does not support real-time font editing or live preview—static font files only.
• Does not handle authentication or security policies—assumes admin installation.
• Does not provide Linux or macOS support—Windows-only (GDI, DirectWrite, WOW64 specific).

Legacy VC2005 build support (Makefile.vc2005) may fail on modern MSVC; use gdipp.vcxproj instead. Antivirus/antimalware may block DLL injection; workaround: Service Mode or HookChildProcesses=0 in profile. Profile format breaking changes between versions require manual backup/migration. DirectWrite and GDI cannot coexist in same profile (one must be disabled). Running alongside MacType-patch requires DirectWrite=0 to avoid rendering conflicts. Requires admin/service privileges for system-wide hooking.

• API Hooking / Function Trampolining — MacType's core mechanism—it intercepts Windows system calls (GDI TextOut, DirectWrite Render) at runtime to inject custom rendering. Understanding IAT hooks, detours, and EasyHook is essential to modifying hooklist.h and hook.cpp.
• FreeType Hinting (TrueType/Type1 Glyph Instructions) — MacType's rendering quality depends on proper hinting engine implementation in fteng.cpp; without hinting, fonts appear fuzzy. Understanding bytecode execution and grid-fitting is critical for quality tuning.
• Subpixel Rendering (ClearType / RGB Antialiasing) — MacType delivers superior text via subpixel RGB layout knowledge (file: colorinvert.h hints at color-aware rendering). This technique uses monitor pixel structure to increase effective resolution.
• DLL Injection & Process Hooking — MacType injects itself into every running process (macloader tray app, dll.cpp initialization). Understanding loader lock, TLS callbacks, and module initialization order is critical for debugging crashes in target apps.
• Glyph Caching & Hash Tables — hash_list.cpp and cache.cpp implement glyph caching with CRC32 checksums to avoid redundant rasterization. Understanding memory pooling and cache invalidation prevents memory leaks and performance regression.
• DirectWrite vs. GDI Rendering Pipelines — MacType must intercept two different Windows text APIs (directwrite.cpp vs. hook.cpp for GDI). Each has different coordinate systems, color spaces, and layout models; incompleteness in either breaks major apps.
• Color Font Support (COLR/CBDT/SVG Tables) — Recent MacType feature (noted in README) requires parsing modern TrueType table formats beyond basic glyph outlines. FreeType integration in ft.cpp must handle emoji and multi-color glyphs.

• tytug/better-font-rendering — Alternative font rendering enhancement for Windows, provides comparison point for feature parity and design decisions.
• microsoft/DirectWrite — Official DirectWrite SDK and samples; MacType targets its APIs, understanding Microsoft's rendering model informs compatibility fixes.
• freetype/freetype — Upstream FreeType library that MacType vendors and hooks; critical for font rasterization logic and hinting updates.
• EasyHook/EasyHook — API hooking library that MacType depends on for runtime function interception; ecosystem companion for understanding injection mechanics.
• x1tan/gdiplus-2.0 — GDI+ flat API wrappers relevant to MacType's gdiPlusFlat2.cpp implementation for modern graphics integration.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for ft.cpp and directwrite.cpp font rendering pipeline

The core font rendering logic in ft.cpp (FreeType integration) and directwrite.cpp lacks automated tests. These are critical paths for the main feature. Adding tests would catch regressions in font rendering quality, especially important given recent updates to FreeType and DirectWrite support mentioned in README. This would significantly improve maintainability for future contributors.

• [ ] Create a test/ directory with a CMake or Visual Studio test project
• [ ] Write unit tests for ft.cpp functions (glyph loading, caching, rendering)
• [ ] Write unit tests for directwrite.cpp DirectWrite API wrapper functions
• [ ] Test cache.cpp cache hit/miss scenarios with real font data
• [ ] Add GitHub Actions workflow to run tests on Windows (Visual Studio) on each PR

Document the hook injection system and create a troubleshooting guide for hook.cpp failures

The hook.cpp file is central to MacType's operation but lacks documentation. Given the complexity of Windows API hooking, detours integration, and EasyHook usage, new contributors struggle to understand the injection flow. The file structure shows hook.cpp, hookCounter.cpp, hooklist.h but no corresponding documentation. A detailed guide would reduce support burden and enable faster onboarding.

• [ ] Create doc/HOOK_ARCHITECTURE.md explaining hook.cpp, hookCounter.cpp, and hooklist.h interaction
• [ ] Document the detours.h and easyhook.h integration flow with code examples
• [ ] Add flowchart/diagram showing DLL injection sequence and hook registration
• [ ] Create doc/TROUBLESHOOTING_HOOKS.md with common hook failure scenarios and solutions
• [ ] Link new docs from main README.md

Add GitHub Actions CI workflow for multi-configuration builds (VC2005, VS2019+, Win32/x64)

The repo has multiple build configurations (Makefile, Makefile.vc2005, build.vc2005.bat, gdipp.vcxproj) but no CI pipeline. This means build breakage goes undetected. Given MacType's complexity with platform-specific hooks and DirectWrite/GDI+ rendering, automated builds on multiple configurations would catch compatibility issues early and validate the recent Win11/CET compatibility updates.

• [ ] Create .github/workflows/build.yml for Windows builds
• [ ] Add build matrix for Visual Studio 2019 and 2022, both Win32 and x64 configurations
• [ ] Configure workflow to build gdipp.sln and macloader.vcxproj
• [ ] Add artifact uploads for built DLL/EXE files
• [ ] Document build requirements in doc/HOWTOBUILD.md (currently sparse)

• Add unit tests for cache.cpp and hash_list.cpp—core data structures lack automated test coverage. Start by writing tests/CacheTest.cpp to verify profile parsing and glyph caching under load.
• Document the profile schema (all available configuration keys) in a structured JSON schema file (doc/profile-schema.json) and reference it in README—currently only examples and scattered documentation exist.
• Implement missing localization strings for Korean and Traditional Chinese UI in the Tuner application—several options are untranslated due to incomplete language files (identify via comparing gdidll.rc strings against locale resource files).

• High · Use of Detours Library Without Verification — detours.h, hook.cpp, hookCounter.cpp, dynCodeHelper.cpp. The codebase includes detours.h and uses hooking mechanisms (hook.cpp, hookCounter.cpp) which are used for runtime function interception. This is a powerful technique that can be exploited if not properly secured. The detours library and hooking implementation lack visible integrity checks or signature verification, potentially allowing malicious code injection or bypassing of security mechanisms. Fix: Implement code signing and integrity verification for hooked functions. Use Address Space Layout Randomization (ASLR) and Control Flow Guard (CFG) where applicable. Validate all hook targets and maintain a whitelist of approved hook locations. Consider adding runtime integrity checks.
• High · Memory Safety Issues in C/C++ Codebase — optimize/memcpy_amd.c, wow64ext.h, dynCodeHelper.cpp, hook.cpp. The codebase is written in C/C++ with direct memory manipulation (evidenced by memcpy_amd.c, wow64ext.h, dynamic code helper). Without visible bounds checking, safe string handling, or memory sanitization, this increases vulnerability to buffer overflows, use-after-free, and heap corruption attacks. Fix: Implement strict bounds checking on all buffer operations. Use safe string functions (e.g., strncpy_s instead of strcpy). Enable compiler security flags (/GS, /DYNAMICBASE). Consider using Address Sanitizer during testing. Audit all pointer arithmetic and memory allocation patterns.
• High · WOW64 Extension and Undocumented API Usage — wow64ext.h, wow64layer.h, undocAPI.h. The codebase uses wow64ext.h and undocAPI.h which interface with undocumented Windows APIs and WOW64 layer internals. Undocumented APIs are not guaranteed to be stable, may contain security flaws, and could bypass security boundaries. This is particularly risky for system-level font rendering code. Fix: Minimize reliance on undocumented APIs. Where possible, use documented Windows APIs. Maintain detailed documentation of which undocumented APIs are used and why. Implement compatibility layers that can adapt to API changes. Test extensively across Windows versions.
• Medium · Insufficient Input Validation in Settings/Configuration — settings.cpp, settings.h, json.hpp. The settings.cpp and settings.h files handle configuration without visible input validation. Configuration injection or malformed settings could lead to unexpected behavior, crashes, or potential code execution. JSON parsing via json.hpp may be vulnerable if input is not properly validated. Fix: Implement strict input validation for all configuration parameters. Define schemas for all accepted settings. Sanitize and validate all JSON input before processing. Implement bounds checking on numeric values. Use allowlists rather than denylists for configuration validation.
• Medium · DirectWrite and GDI Plus Integration Risks — directwrite.cpp, directwrite.h, gdiPlusFlat2.cpp, gdiPlusFlat2.h, GdiPlusTypes2.h. The codebase heavily manipulates DirectWrite and GDI+ rendering pipelines (directwrite.cpp, gdiPlusFlat2.cpp, GdiPlusTypes2.h). These are complex system components. Incorrect manipulation of rendering paths, font handling, or device contexts could lead to information disclosure, denial of service, or potential privilege escalation. Fix: Thoroughly validate all parameters passed to DirectWrite and GDI+ APIs. Implement error handling and bounds checking for all rendering operations. Audit font file handling for malformed font exploits. Test with fuzzing on font files and rendering parameters.
• Medium · Weak Caching Mechanism — cache.cpp, cache.h, crc32.h. The cache.cpp and cache.h implement caching without visible cryptographic integrity checks or invalidation mechanisms. Cache poisoning attacks could serve malicious cached data, potentially affecting font rendering or system behavior across applications. Fix: Implement cryptographic hashing (SHA-256 or better) instead of CRC32 for cache integrity verification. Add cache expiration mechanisms with timestamps. Implement access controls on cache files. Validate cached data before use. Consider encrypting sensitive cache contents.
• Medium · Unvalidated FreeType Integration — undefined. FreeType library is integrated (ft.cpp, ft. Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.