How do their APIs compare?

Neither of these repositories exposes a formal, documented public API in the sense of a REST/RPC service or SDK contract — they're both Windows desktop GUI applications, so "API" here really means internal library/utility surfaces used across the codebase. Let me lay out what's actually visible in the retrieved data and note the limits of that view.

mzying2001/cefflashbrowser

What's visible are internal helper/utility classes exercised by its test suite:

• UrlHelper.IsUrl(string) — a static utility that classifies strings as URLs, handling schemes like http://, ftp://, bare domains with query strings, and rejecting unknown schemes (e.g. abc:abc). Seen exercised in [CefFlashBrowser.Tests/UrlHelperTests.cs:L28-L33], [L40-L45], [L112-L117], [L124-L130].
• FileLogger — a disposable logging class with a Log(LogLevel, string, [Exception]) method, writing pipe-delimited (|) formatted lines (e.g. ERROR | message), auto-creating log directories, and appending across instances rather than truncating. See [CefFlashBrowser.Tests/FileLoggerTests.cs:L52-L66], [L103-L117], [L141-L154], [L155-L175].

This is a small, testable internal API surface — utility classes with clear single responsibilities (URL classification, file-based logging), not a networked or plugin API. No controller/route/RPC layer appears in the retrieved data.

shadowsocks/shadowsocks-windows

The visible surface is very different in kind:

• Generated protobuf model code for Geosite/domain data: DomainObject, Geosite, GeositeList classes with generated Equals overrides comparing Type, Value, GroupName, and internal attribute_/domains_/entries_ fields plus unknown-fields equality — standard protobuf-generated boilerplate, not hand-written API design. [shadowsocks-csharp/Model/Geosite/Geosite.cs:L132-L145, L542-L554, L679-L690]
• An embedded JavaScript filtering engine (abp.js, Adblock Plus–style rule matching) with methods like isActiveOnDomain, isActiveOnlyOnDomain, hasFilter, getKeywordForFilter, and internal _checkEntryMatch — this is a domain/rule matching API used for proxy auto-config / PAC-style filtering logic. [shadowsocks-csharp/Data/abp.js:L174-L213, L214-L253, L254-L263, L567-L606]
• Localization accessors: a generated Strings resource class exposing typed string properties (Timeout, ToggleProxyMode, ToggleSystemProxy, Type, updateAllButton_Content) that wrap ResourceManager.GetString. [shadowsocks-csharp/Localization/Strings.Designer.cs:L345-L384]

Comparison

Aspect	cefflashbrowser	shadowsocks-windows
Nature	Small, hand-written internal utilities (URL parsing, logging)	Larger mix of generated protobuf models, embedded JS rule engine, generated localization accessors
Testing visibility	Has a dedicated test project (CefFlashBrowser.Tests) directly exercising these APIs	No test code visible in this retrieval for the shown modules
Design style	Straightforward static/instance helper classes	Heavier reliance on code generation (protobuf .Equals, resource designer) and a ported JS filtering algorithm
Domain purpose	Flash content handling support (URL validation, diagnostics logging)	Proxy/network rule matching (domain filtering) and Geosite data modeling

Given RepoPilot's architecture signal for cefflashbrowser — grade C (50/100) with 0 files parsed and 0 internal imports detected — the import graph currently gives no structural picture of how these utility classes connect to the rest of the app; that's a gap in the computed signal, not evidence of a flat architecture. I don't have an equivalent RepoPilot signal shown for shadowsocks-windows in this data, so I can't compare their import-graph structure directly — only what's visible in these specific files.

If you want, I can search for more of either repo